Access control policy template: the parts most leave out
There is no shortage of free access control policy templates. Most of them cover the same ground — least privilege, need to know, review access periodically, use strong passwords — and all of it is correct. What they tend to miss is the part that actually fails.
In practice, access control breaks in the same four places every time. Nobody removes access when people leave. Service accounts have no owner, so nobody dares switch them off. Administrators use privileged accounts to read email. And the multi-factor authentication exception list, which started as a temporary measure for one legacy system, is now three years old and has grown.
None of those are exotic problems. They are what an auditor finds in the first afternoon, and they are what this article is organised around.
In a hurry? The NIS-2 Compliance Suite contains this policy written out, along with the access review register and the joiner-mover-leaver workflow. Editions from €390. If you want to check where you stand first, the free gap assessment takes ten minutes.
What the law actually asks for
Two provisions of NIS-2 govern access control, and together they say less than you might expect. Article 21(2)(i) requires policies on human resources security, access control and asset management. Article 21(2)(j) requires the use of multi-factor authentication or continuous authentication solutions, along with secured voice, video and text communications.
That is the whole of it. The directive is deliberately outcome-based: it names the objective and leaves the method to you, which is a gift if you already have a mature environment and a problem if you were hoping for a checklist.
The detail lives elsewhere. For entities in the digital infrastructure and digital provider sectors, Commission Implementing Regulation (EU) 2024/2690 spells out access control in section 11 of its Annex, covering the policy itself, rights management, privileged accounts, administration systems, identification, authentication and MFA. That regulation applies directly and identically across the Union, with no national transposition, so if it covers you it is the more specific of the two documents.
If you hold ISO 27001, the overlapping controls are A.5.15 to A.5.18 and A.8.2 to A.8.5. They cover most of the same ground, which is why an existing ISMS gets you a long way here — with one gap worth naming, which comes later in this article.
The access model
Access is granted by role, approved by the owner of the system, and every exception carries an expiry date.
Your policy should open with the model, because everything else follows from it.
Access is granted on least privilege and need to know — to what the role requires, not to what happens to be convenient. That sentence is easy to write and hard to hold, because the pressure in every organisation runs towards granting more rather than less, and the person asking is usually in a hurry.
Wherever possible, grant against defined role profiles rather than individually. Individual exceptions will still happen, but tracking them separately, each with a justification, is what keeps the exception from quietly becoming the norm.
Approval belongs to the owner of the system or the data, not to the IT team that provisions it. Separating the request, the approval and the execution is what makes the audit trail mean something: three parties, three records, no single person who can grant themselves access to anything.
Where a single identity could both perform and approve an action that materially affects the service or its security, segregate the duties. Many organisations are too small to do that properly, which is fine — but then name the compensating control instead, usually independent review of the log, and write it into the policy. A compensating control that exists only in someone’s head is not one.
Identity: one person, one account
Every person and every non-human actor gets a unique, attributable identity. This sounds obvious until you look closely, because an action that cannot be traced to one identity has not really been logged, and two of the most common identity problems are things people stop noticing.
The first is shared accounts. Your policy should prohibit them, and then deal honestly with the ones that exist anyway — the legacy appliance that only takes one login, the vendor support account nobody can rename. Section 11.5 of the CIR Annex asks for control of shared identifiers, not for the pretence that they are absent. So register them, restrict their use to named individuals, hold the credential under controlled custody, and review the activity. A policy that bans shared accounts while three of them run in production is worse than one that governs them, because it tells an auditor that the policy is not describing reality.
The second is service accounts, and this is the one that shows up in almost every access review. Every service account, application identity, automation credential and machine-to-machine token needs a named human owner, a written purpose, a rotation schedule and an expiry date. Miss the owner and you have created an account nobody will ever decommission, because nobody knows what breaks if they do. That is how organisations end up with credentials from a project that ended four years ago, still valid, still privileged, still nobody’s problem.
Granting and changing access
The request-approve-provision sequence is standard, but two details inside it are worth writing down explicitly.
The first is that every request carries a business justification, and “same as Marco” is not one. That phrase is how a single person’s accumulated privileges get cloned across a whole department, and it happens because it is the fastest thing to type.
The second concerns people who move rather than leave. When someone changes role, their rights are re-based on the new role, not added to the old ones. This is the most common route to over-privilege in any organisation: someone moves from finance to operations, keeps both sets of access, and three years later has quietly accumulated the reach of four different jobs. Your policy needs to say plainly that a mover is treated as a leaver from the old role and a joiner to the new one.
Once access is granted, tell the user what they have been given and have them acknowledge the acceptable use conditions. That acknowledgement is your evidence that the obligation was communicated, and it takes one form to collect.
Multi-factor authentication, and the exception list
MFA scope by scenario. The exception list is where policies quietly fail.
Article 21(2)(j) names MFA explicitly, and section 11.7 of the CIR Annex ties the scope to the cases identified by your risk assessment. In practice a defensible policy applies it at least here:
| Scenario | MFA required |
|---|---|
| Remote access to the network or systems | Always |
| Privileged and administrative access | Always, including break-glass |
| Systems holding your most sensitive data | Always |
| Cloud administration and management consoles | Always |
| Internal access to standard systems | Per risk assessment |
Every organisation has an exception list. The question is not whether you have one but whether it is governed, and governing it means four things written on every line: what is excluded, why, what compensating control applies instead, and the date the exception expires.
The expiry date is the one that matters. Without it, “legacy system” becomes a permanent exception wearing a temporary name, and it will be found — it is close to the first thing anyone looks for. Where you are still using one-time codes over SMS, the honest move is to record that as a known limitation in the risk register rather than count it as full compliance. It is not a reason to panic, but it is a reason to be straight about it in writing.
Privileged access
If you only tighten one part of your policy this quarter, tighten this one.
The single most valuable rule is that administration is never performed from the account used to read email and browse the web. Separate accounts for separate purposes removes an entire class of attack, and it costs nothing but discipline.
Beyond that, keep a register of privileged accounts recording the holder, the scope, the justification and the date of the last review — and review it quarterly rather than annually, because privileged access accumulates faster than standard access does. Section 11.4 of the CIR Annex also asks for restricted administration systems, which is worth taking seriously: administering production from an unmanaged laptop defeats every other control in the policy, however well written.
Where your tooling supports just-in-time elevation, use it. Privileges that activate for a task and expire on their own are better than privileges that sit there permanently and get used occasionally. Break-glass accounts should exist, be stored under dual control, and have every use logged and reviewed the next working day.
One last point that is easy to miss: privileged actions must be logged somewhere outside the control of the account performing them. An administrator who can edit the record of what they did on a system has not been logged in any meaningful sense.
Revocation: the same-day rule
This is the part most templates handle in a single sentence, and it causes more findings than the rest of the policy combined.
Access is revoked on the day the trigger occurs — termination, end of contract, role change, or a security event. Not at the end of the month, not when someone gets round to it. Where a termination is not amicable, revocation precedes the notification to the individual, which means HR, the line manager and security have to have agreed the sequence in advance, because it cannot be improvised on the morning.
The directory account is the easy part, and stopping there is the mistake. A complete revocation covers:
- the directory or identity provider account
- remote access and VPN
- cloud consoles and admin portals
- SaaS applications outside single sign-on — the ones a department bought with a credit card
- service accounts held personally
- shared credentials the person knew, which now need rotating
- physical access badges
- API keys and personal access tokens
Then the assets come back and the return is recorded. For suppliers the same logic applies when an engagement ends, with the revocation confirmed back to them: supplier accounts left live after a contract expired are among the most common findings in this whole area, precisely because nobody owns the closing step.
Worth measuring: record the date the leaver trigger was known and the date access was actually revoked. The gap between those two numbers is the most useful access control metric you can keep, and the easiest to put in front of management.
Access reviews
Review privileged access quarterly and standard access annually, and have the system or data owner do it rather than IT.
Two rules separate a real review from a ceremonial one. The first is that silence is not confirmation: access that has not been affirmatively reviewed gets revoked, not carried over. Without that rule the review becomes a form that gets signed, which is worse than no review because it produces evidence of a control that is not operating.
The second is to reconcile against HR and supplier records rather than reviewing the access list in isolation. That reconciliation is how you find orphan accounts — identities with no corresponding person or contract, the ones that survive every reorganisation because each new manager assumes someone else owns them.
Record the review, the findings and the actions. The record is what an auditor asks for; the review itself is what protects you.
Where ISO 27001 does not reach
If you already run an ISO 27001 ISMS, controls A.5.15 to A.5.18 cover most of what is described here, and you are further along than you probably think. Two things do not carry over automatically.
One is the explicit MFA expectation. ISO 27001 addresses authentication broadly and leaves the strength to your risk assessment; Article 21(2)(j) names multi-factor authentication as a measure. The controls overlap but the specificity does not, so make sure your policy states the scope rather than implying it.
The other is the evidence standard. ISO 27001 asks whether the control exists and operates, which is also what a NIS-2 supervisory check asks — but with administrative penalties attached, and for essential entities without the authority needing a reason to look. Same question, different consequences.
ISO 27001 is one way to demonstrate compliance, not a legal substitute. NIS-2 is framework-neutral.
The policy is the easy half. What takes the time is the access review register, the joiner-mover-leaver workflow, the privileged account register and the exception log — all of which have to exist and be current for the policy to mean anything. The NIS-2 Compliance Suite contains all of them, alongside twelve other procedures.
The policy, section by section
Adapt the wording; keep the structure.
- Purpose and scope — which systems, which people, including contractors and third parties.
- The access model — least privilege, role-based, segregation of duties or the compensating control.
- Roles and responsibilities — who approves, who provisions, who reviews.
- Identity — unique identities, shared account rules, non-human identity requirements.
- Requesting and granting — the workflow, the justification requirement, the re-basing rule for movers.
- Authentication — MFA scope, permitted factors, password requirements, session handling.
- Privileged access — separate accounts, register, administration channels, break-glass.
- Third-party access — time-bound, tied to a contract, MFA mandatory, reviewed.
- Revocation — the same-day rule and the full checklist of what it covers.
- Access reviews — frequency, who performs them, what happens to unreviewed access.
- Exceptions — the format: what, why, compensating control, owner, expiry.
- Version control — date, owner, approval, next review.
Four things to do this week
Rewriting a policy takes longer than most people budget for. If that is more than you can take on right now, these four give the best return for the least effort, and none of them needs the policy to be finished first.
Start by pulling the list of accounts that have not logged in for ninety days, then find out which of them belong to people who have left. It is usually an uncomfortable morning and the fastest risk reduction available to you.
Next, find the service accounts with no owner and assign one to each, even provisionally. An owner can eventually decide whether an account is still needed; without one, nobody ever will.
Third, take your current MFA exception list and put an expiry date on every line. The lines you find you cannot date are the ones you should not be carrying.
Finally, pick the most recent person who left and check how long each of their accesses stayed live afterwards. That number is your real policy, whatever the document says.
Frequently asked questions
Does NIS-2 require multi-factor authentication? Article 21(2)(j) names multi-factor authentication or continuous authentication solutions as a measure entities must use. It does not prescribe where, which is left to your risk assessment — but remote and privileged access are difficult to justify excluding.
Can we keep shared accounts? Where a technical constraint makes them unavoidable, yes — provided they are registered, restricted to named individuals, held under controlled custody and their activity reviewed. What is not defensible is a policy banning them while they run in production.
How often should access be reviewed? Quarterly for privileged access and annually for standard access is a defensible default. Adjust to your risk: an organisation with high staff turnover needs a shorter cycle.
Who should approve access requests? The owner of the system or the data, not the IT team that provisions it. Separating approval from execution is what makes the audit trail meaningful.
Is an ISO 27001 access control policy enough for NIS-2? It covers most of the ground, but check two things: that MFA scope is stated explicitly, and that your evidence would survive a check where the authority does not need a reason to look.
Where to go next
An access control policy is one of ten risk-management measures NIS-2 requires, and knowing where you stand on the other nine matters as much as getting this one right.
The free NIS-2 gap assessment asks twelve questions, one per obligation, and scores you measure by measure. It takes about ten minutes and tells you which obligations you could evidence today if someone asked.
If you would rather start from a written set, the NIS-2 Compliance Suite contains the access control procedure described here, the review registers and the joiner-mover-leaver workflow, as part of thirteen procedures covering all ten Article 21 measures. Editions from €390.
You may also want to read our guide to building an incident response plan that survives the 24-hour clock, which covers the one measure with a statutory deadline attached.
Sources
Directive (EU) 2022/2555 and Commission Implementing Regulation (EU) 2024/2690 are available on EUR-Lex.