the work
access control
Who can get in, who said so, and when someone last checked. Every rule asks the same thing in slightly different words, which makes this the most reusable work on the site.
the reality
One access review, done once and kept properly, helps answer questions under NIS2, DORA, GDPR, ISO 27001 and SOC 2. The order matters: fix who has access first, then write the policy describing what you do.
The evidence kit lists these exports row by row, with an owner and a rhythm for each.
basis NIS2 Art. 21(2)(i); DORA Art. 9(4)(c); GDPR Art. 32(1)(b)
what to decide
- Who owns each important system, and so who approves access to itnamed owner, with the business
- Whether MFA is for everyone, and who can approve an exceptionboard, on a proposal from IT
- How often access is reviewed. No text gives a number outside finance, so pick one and keep to ithead of IT
- How long access logs are kepthead of IT, with legal
basis NIS2 Art. 21(2)(i), 21(2)(j); IR 2024/2690 Annex 11.2.3 as a reference
what to build
- Export the admin list from your identity provider and top five systems. Remove anyone who does not need it this week.
- Turn on MFA for every admin, then everyone. Keep a list of exceptions with an owner, a reason and a review date.
- Compare HR's leavers for the last six months with enabled accounts. Disable the differences and fix the process that missed them.
- Have each system owner confirm who should have access. Save the signed result, including what was removed.
- Give supplier and guest accounts an owner and an end date.
- Then write the two-page policy describing what you now do, and have management approve it.
basis IR 2024/2690 Annex 11.2.2, 11.3.2, 11.7.1 as a reference; DORA Art. 9(4)(c), 9(4)(d); KSC Art. 8(1)(2)(n), 8(1)(2)(l)
access has a life cycle, and most gaps sit at the end of it
- 1joinsaccess requested and approved by someone named
- 2worksleast access the job needs, with MFA
- 3movesold rights removed when the role changes
- 4reviewedowner confirms on a set rhythm
- 5leavesdisabled on the last day, compared with the HR list
supplier and guest accounts run the same loop, with an end date
basis IR 2024/2690 Annex 11.2.2, 11.2.3 as a reference; NIS2 Art. 21(2)(i), 21(2)(j)
the evidence it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| admin list export with date | head of IT | quarterly |
| MFA coverage report and exception list | head of IT | quarterly |
| leaver reconciliation | HR and head of IT | monthly |
| signed access review with removals | system owners | every 6 months, critical systems every quarter (your choice) |
| approved access policy | management | yearly |
basis IR 2024/2690 Annex 11.2.2(e), 11.2.3 as a reference. The rhythms are your choice.
one review, signed once
- 1exportwho has access today
- 2confirmthe system owner marks each name
- 3removewhat nobody could explain
- 4sign and dateand file the result
that file helps answer
- NIS2access control
- DORAaccess rights
- GDPRconfidentiality
- ISO 27001access rights
- SOC 2logical access
basis NIS2 Art. 21(2)(i); DORA Art. 9(4)(c); GDPR Art. 32(1)(b). ISO 27001 and SOC 2 not re-read at source.
what goes wrong
the policy comes first
A policy written before the clean-up describes a company that does not exist, and an auditor can tell.
leavers nobody told IT about
HR knows and IT does not. Without a monthly comparison the gap stays open for as long as nobody looks.
exceptions with no end
An MFA exception without an owner and a review date becomes permanent.
logs that expired
Platform defaults can be short. You find out when someone asks about last quarter. Check your retention now.
basis working practice. No legal text sets this.
what the texts leave open
- Where MFA is appropriate. NIS2 does not list the cases, so document where you use it and why you do not elsewhere.
- How often to review. The implementing regulation says planned intervals.
- How long to keep access logs. None of these texts sets a period.
basis NIS2 Art. 21(2)(j); IR 2024/2690 Annex 11.2.3
check it yourself
what each text says, for whoever checks this page
| text | says |
|---|---|
| NIS2 Art. 21(2)(i) | Human resources security, access control policies and asset management. |
| NIS2 Art. 21(2)(j) | Multi-factor or continuous authentication, where appropriate. |
| IR 2024/2690 Annex 11.2.2 | Listed digital providers: least privilege and separation of duties, changes on leaving, approvals, limits on third-party access, a register and a log. |
| IR 2024/2690 Annex 11.7.1 | Listed digital providers: MFA or continuous authentication where appropriate, by asset classification. |
| DORA Art. 9(4)(c) | Limit physical and logical access to what approved functions need. |
| DORA Art. 9(4)(d) | Policies and protocols for strong authentication. |
| GDPR Art. 32(1)(b) | Ongoing confidentiality of processing systems, sized to risk. |
| KSC Art. 8(1)(2)(n) | Poland: access control policies. Multi-factor authentication where appropriate is in point (l). |
- Directive (EU) 2022/2555 (NIS2) (EUR-Lex)
- Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)
- Regulation (EU) 2022/2554 (DORA) (EUR-Lex)
- Regulation (EU) 2016/679 (GDPR) (EUR-Lex)
- Poland: Act of 23 January 2026 amending the national cybersecurity system act, Dz.U. 2026 poz. 252 (Dziennik Ustaw)
fyi Last checked 2 November 2026. This is not legal advice. It is a plain reading of the texts listed on this page, and national law can add to them. Before you rely on it in front of a regulator, an auditor or your board, have a lawyer confirm it for your company. What this means.
your next step
Export your admin list now and count how many names you can explain.