Separation of Duties With a Three-Person IT Team: CIR 11.2.2(a) Has No Opt-Out — Recital 5 Names Two Compensations

A three-person IT team can’t separate every duty, and the regulation that sets NIS2’s technical rules for digital providers doesn’t let it drop the principle either. Point 11.2.2(a) of the Annex to Implementing Regulation (EU) 2024/2690 requires access rights to be assigned and revoked “based on the principles of need-to-know, least privilege and separation of duties”. It carries no “where appropriate” qualifier, so the documented opt-out in Article 2(2) doesn’t reach it. What the regulation leaves open is how you apply the principle. Its Recital 5, which is non-binding, names the two substitutes the Commission had in mind for entities too small to split conflicting duties: “targeted oversight by the entity’s management or increased monitoring and logging”.

Three people are enough to run a two-person rule on every risky action. The real gap in most small teams is narrower: one administrator who can grant access, use it and delete the record that they did. This guide maps the two separation clauses in the Annex, the conflicts a three-person team actually has, and the privileged-account and logging controls that can stand in where headcount runs out.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Does This Apply to You?

In plain terms: every essential and important entity needs access control policies under the Directive. The word-for-word separation rules bind eleven types of digital provider. For everyone else they are the most detailed EU benchmark available, but national law sets the actual rules.

Who you are	What binds your separation of duties	Practical effect
DNS provider, TLD registry, cloud, data centre, CDN, managed service provider (MSP), managed security service provider, online marketplace, search engine, social network or trust service provider	Implementing Regulation 2024/2690, Article 1 and Annex points 1.2.5, 2.3.2 and 11.2.2 (directly applicable)	An auditor can test each point letter by letter. This is the typical home of a three-person IT team: a small MSP or hosting provider.
Any other essential or important entity	Article 21(2)(i) NIS2 (“access control policies”), as transposed into national law	The Directive doesn’t name separation of duties. Your national authority sets the detail, and the Annex is a strong reference.
Organisation using ISO/IEC 27001 as its framework	Annex A control 5.3, Segregation of duties	The same conflict analysis serves both regimes, so build it once.

The Implementing Regulation has no headcount threshold. When we counted the official English text, the Annex used the word “size” exactly twice (points 1.2.4 and 2.3.2) and the word “small” not once. Size enters only through proportionality, covered below. National transposition laws may add rules of their own, so confirm with your competent authority.

Two Separation Clauses, Two Different Rules

In plain terms: the Annex asks for separation in two places. One governs who holds which responsibilities and has an escape route. The other governs access rights and has none.

Annex point	What it says	Qualifier	Can a small entity document its way out?
1.2.5 (roles)	“Conflicting duties and conflicting areas of responsibility shall be segregated, where applicable.”	“where applicable”	Partly. Article 2(2) lets you judge it not applicable, but you “shall in a comprehensible manner document [your] reasoning”.
11.2.2(a) (access rights)	“assign and revoke access rights based on the principles of need-to-know, least privilege and separation of duties”	None	No. You must apply the principle. Size shapes how.
2.3.2 (independent reviews)	Reviewers “shall not be in the line of authority” of the area reviewed; if size “does not allow such separation”, put in place “alternative measures to guarantee the impartiality of the reviews”	Built-in size fallback	No opt-out, but a written substitute: impartiality instead of a separate reporting line.

Legal text: Implementing Regulation 2024/2690, Article 2(2) and Annex. Right-hand column: our interpretation.

Two details change how you should read Recital 5. First, its worked example concerns micro-sized entities “defining roles, responsibilities and authorities”, which is the territory of point 1.2.5, not the access-rights rule. Its general sentence is wider: any entity that can’t implement a requirement “due to their size” should be able to take compensating measures. Second, the word “compensating” appears twice in the regulation, both times in Recital 5, and never in the binding Annex. Recitals explain intent; they don’t create exceptions. So compensations are best read as the way you apply 11.2.2(a) proportionately, not as permission to skip it.

ENISA’s Technical Implementation Guidance points to the two splits it treats as the floor. Under 1.2.5: “As a minimum, consider that the reviewer (auditor) must be different from the personnel or the line of authority of the area under review.” Under 11.2.2: “consider segregation of duties, including segregating the roles of approval and implementation of the access rights”. Its listed evidence for the access-rights point is a “segregation of duties matrix”. That is the document to build first.

The Proportionality Argument, Stated Correctly

In plain terms: your size changes how you meet the separation duty, not whether you meet it.

Article 21(1) of the NIS2 Directive requires measures that are “appropriate and proportionate”. When proportionality is assessed, “due account shall be taken of the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents and their severity”. Article 2(2) of the Implementing Regulation repeats those factors and adds the phrase that matters: entities take them into account “when complying with” the Annex. Size is a factor in how you comply. It isn’t a ground for not complying.

ENISA’s guidance shows what that looks like in practice. Its only size concession on identities is a frequency change: reviews “as a minimum quarterly”, but annually for micro-sized entities. The control stays. The interval moves.

Applied to separation of duties, the argument a small team can make runs like this: “We have three IT staff. Full separation of every conflicting duty would need more people than our risk justifies. We separate the duties three people can separate, and for the rest we apply the two substitutes the Commission named in Recital 5.” Write that down and sign it. For point 1.2.5 the note is your Article 2(2) record. For 11.2.2(a) it is evidence of how you applied the principle. Either way, an unwritten judgement is no defence. The proportionality guide for medium enterprises covers how auditors read the other Article 21(1) factors.

The Conflict Map for a Three-Person Team

In plain terms: list each pair of duties that one person shouldn’t hold together, then decide whether you can split it or need a substitute.

Take a typical small MSP: an IT lead, a systems administrator and a service-desk technician, with a managing director outside IT. Five conflicts come up in almost every team of this shape.

Conflicting pair	Anchor	Split across three people?	If not, compensate with
Requesting access vs approving it	11.2.2(a), (c): access “authorised by the relevant persons”	Yes. Nobody approves their own request. The asset owner or managing director approves.	Not needed
Using admin rights vs approving their activation	11.3.2(a)–(c)	Yes. Either of the other two approves elevation.	Sealed break-glass account with an alert on use
Making a change vs approving it	6.4.2: changes “tested and assessed … before being implemented”	Yes for planned changes	Emergency changes: the record and explanation 6.4.3 requires, then a review the next working day
Administering access vs controlling the logs of it	11.2.2(f), 3.2.5	Rarely. All three usually hold tenant-wide rights.	Log copies none of the three can delete (see below)
Doing the work vs reviewing it	2.3.2	No. All three report to the IT lead.	Managing director review plus a periodic external review

Recommended internal practice based on the Annex points cited; the “split” and “compensate” columns are not legal text.

The table makes a point most guidance misses. Three people can cover the first three conflicts with ordinary approval workflows. Those are two-person rules, and you have three. What three people can’t do is put the logs, and the review of the logs, outside the reach of the people being logged. NIST SP 800-53 Rev. 5 names that exact split in its separation-of-duties control, AC-5: “security personnel who administer access control functions do not also administer audit functions”. NIST isn’t binding under NIS2, but it pinpoints where a small team’s compensations have to work hardest.

Compensation 1: Admin Accounts That Can’t Act Alone

In plain terms: give each admin a personal admin account, remove standing “full control” rights, and make elevation need a second person.

Point 11.3.2 already does most of the work, and none of it is qualified. Admin accounts need “strong identification, authentication such as multi-factor authentication, and authorisation procedures” (a). They must be “specific accounts to be used for system administration operations exclusively” (b). And privileges must be “individualise[d] and restrict[ed] … to the highest extent possible” (c). In a three-person team, (c) is the clause that bites. If the IT lead holds permanent tenant-wide rights “because someone has to”, that’s the first thing to fix.

A workable pattern:

1. Personal, separate admin accounts. No shared “admin” login. Every privileged action traces to one named person.
2. Scoped roles. User administration, mail, endpoint management and security settings as separate roles, each held only by whoever needs it.
3. Elevation on request. ENISA’s guidance on 11.3.2: “Grant temporary privileged access only for the time necessary to implement approved changes or activities”. In Microsoft Entra Privileged Identity Management, Microsoft’s documentation states that “approvers aren’t able to approve their own role activation requests”. With three admins, each request goes to one of the other two.
4. One break-glass account. Long password stored offline, used only when the approval route fails, with an alert to all three admins and the managing director whenever it signs in.

Where a single identity is unavoidable, ENISA’s footnote 92 sets the bar. In environments such as Microsoft 365, privileged users “may use a single identity provided that some additional compensating measures are in place”, such as MFA, just-in-time access, session logging and context-aware controls. Our privileged access management guide covers all four of the 11.3 rules. The Entra ID guide maps the Microsoft settings.

Compensation 2: Logs the Administrator Can’t Edit

In plain terms: record every grant and every admin action, and keep a copy somewhere none of the three admins can delete it.

Recital 5’s “increased monitoring and logging” maps onto three binding points:

• 11.2.2(f): “apply logging to the management of access rights”. This is unqualified, so every grant, change and revocation is logged.
• 3.2.3: “where appropriate”, logs include “creation, modification or deletion of users … and extension of the permissions” (b), “all privileged access to systems and applications, and activities performed by administrative accounts” (e), and “activation, stopping and pausing of the various logs” (k). For a team that relies on logging to compensate, it’s hard to argue these aren’t appropriate.
• 3.2.5: logs are kept “for a predefined period” and protected “from unauthorised access or changes”.

Protection is the weak spot. If the same three accounts can change the retention settings, the logs don’t separate anything. NIST’s control AU-9(4) limits management of audit logging to a subset of privileged users. A small team can get the same effect by forwarding logs to a storage account or SIEM workspace owned by the managing director or an external security provider. The admins can write to it but can’t delete from it.

Watch the default retention. According to Microsoft’s retention reference, Entra ID audit logs are kept for seven days on the Free tier and 30 days on P1 and P2. ENISA’s guidance on 3.2.5 adds that the backup logs’ retention “shouldn’t be shorter than the logs’ review period”. If the oversight review below runs monthly, 30 days in the portal leaves no margin, so export the logs. Set alerts for the events that matter most: a new privileged role assignment, use of the break-glass account, and any change to logging settings. Retention periods and alarm thresholds are covered in our logging and monitoring guide.

Compensation 3: Targeted Management Oversight

In plain terms: someone outside the IT team looks at a short report every month and signs it.

Article 20(1) of the Directive already requires management bodies to “approve the cybersecurity risk-management measures” and “oversee [their] implementation”. Recital 5’s “targeted oversight by the entity’s management” turns that general duty into a specific check. A format that fits a small firm:

Role	Owns	Must not
Managing director	Approves new privileged roles; owns the log store; signs the monthly review	Hold day-to-day admin rights
IT lead	Separation-of-duties matrix, proportionality note, change approval	Approve own elevation or own access requests
Systems administrator	Implements approved changes; approves the other admins’ elevation	Change log retention or alert rules
Service-desk technician	Joiner-mover-leaver tickets; approves elevation when the others request	Grant access without a recorded authorisation
External reviewer	Periodic impartial review under 2.3.2	Review work they performed

Recommended internal practice; role names are illustrative.

The monthly report needs four lists: accounts created or given extra permissions, privileged elevations with their approvers, emergency changes, and alerts. Thirty minutes, a signature and a date. For the independent review in point 2.3.2, an annual review by an outside party (an auditor, another MSP or a consultant) is one way to provide the “alternative measures to guarantee the impartiality of the reviews” the regulation asks for. The regulation doesn’t fix an interval for either check, so set both in your policy and keep to them. For how the reporting line to management works, see our programme governance guide.

The Evidence File: What an Auditor Can Test

Build it in this order. Effort levels assume a team of three on a mainstream cloud stack.

Step and evidence	Annex anchor	Effort
1. Separation-of-duties matrix listing each conflict, how it’s split or what compensates	11.2.2(a), 1.2.5	Low
2. Signed proportionality note covering what can’t be split and why	Art. 2(2), 1.2.5	Low
3. Personal admin accounts, scoped roles, no standing tenant-wide rights	11.3.2(a)–(c)	Medium
4. Approval records for access requests and admin elevation	11.2.2(c), 11.3.2(a)	Low
5. Log export to a store the admins can’t delete, plus alert rules	11.2.2(f), 3.2.3, 3.2.5	Medium
6. Signed monthly management review reports	Recital 5 (non-binding), Art. 20(1) NIS2	Low
7. Emergency change records with the next-day review	6.4.3	Low
8. Independent review report with the alternative impartiality measure named	2.3.2	Medium

Write the matrix and the exceptions into your access control policy rather than keeping them as a loose spreadsheet. Our ISO 27001 access control policy template shows where the segregation rules and the exceptions sit in the document. One test catches most gaps: pick any privileged action from last month and trace it to a request, a different approver and a log entry that sits outside the actor’s control. If one of those links is missing, that’s where your next control goes.

Frequently Asked Questions

Is separation of duties mandatory under NIS2?

For the eleven provider types bound by Implementing Regulation 2024/2690, yes. Point 11.2.2(a) requires access rights to follow it, with no qualifier. Other entities must meet their national version of Article 21(2)(i), which asks for access control policies without naming the principle.

Can a one-person IT function comply?

It is much harder, because a two-person rule needs a second person. The managing director or an external provider has to take the approver and log-owner roles. Recital 5 frames management oversight and logging as substitutes, but with one administrator they carry the whole load, so document them carefully.

Does ISO 27001 accept compensating controls for segregation of duties?

Yes, as a fallback. According to TÜV NORD’s guidance on control A.5.3, the control expects other appropriate controls where segregation can’t be achieved, such as management oversight, peer review, and logging with alerts. The certification body also warns against treating an inability to separate as a reason to do nothing. The same matrix can serve both frameworks.

How often should the management review run?

Neither the Directive nor the Implementing Regulation sets an interval. Monthly is a common practical choice because it fits inside a 30-day log window. Whatever you choose, write it into the policy, because auditors test against the cadence you wrote down.

For the full set of Article 21(2)(i) requirements, see our NIS2 access control and HR security guide.

How This Guide Was Verified

Every Annex point and recital quoted above was checked against the official English text of Implementing Regulation 2024/2690 from EUR-Lex. The word counts (“separation of duties” once, “compensating” only in Recital 5, “size” twice in the Annex) come from searching that text directly. ENISA’s guidance was read in its full June 2025 PDF and NIST’s control text in SP 800-53 Rev. 5. Where a step rests on guidance or our own interpretation rather than binding text, the article labels it.

Sources

1. Commission Implementing Regulation (EU) 2024/2690, Articles 1 and 2, Recital 5, and Annex points 1.2, 2.3.2, 3.2, 6.4, 11.2 and 11.3 — EUR-Lex
2. Directive (EU) 2022/2555 (NIS2), Article 21(1) and 21(2)(i)
3. Directive (EU) 2022/2555 (NIS2), Article 20(1)
4. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025 (points 1.2.5, 3.2.5, 11.2.2, 11.3.2, 11.5.4 and footnote 92)
5. NIST, Special Publication 800-53 Revision 5, controls AC-5 and AU-9
6. Microsoft Learn, Approve or deny requests for Microsoft Entra roles in PIM
7. Microsoft Learn, Microsoft Entra data retention
8. TÜV NORD UK, Navigating ISO 27001 Annex A control A.5.3