control
access reviews
The cycle that keeps access matched to people: what happens when someone joins, moves or leaves, and the periodic review where each system owner signs off who still needs access.
- what it protects
- against access that outlives the job: leavers still enabled, movers with every old right
- who owns it
- HR and head of IT, with a named owner for each system
- start with
- compare HR's list of leavers with enabled accounts and disable the differences
what it is
An access review is how access stays matched to people. It has two parts. The first runs all year: when someone joins, moves or leaves, their access changes to match. The second runs at an interval you choose: each system owner looks at who has access and confirms it, and the result is signed and kept.
The first part fails quietly. HR records an exit and IT never hears of it, or a person changes team and keeps every old right. A monthly comparison of HR’s list with enabled accounts catches most of it. The second part catches the rest, and leaves the record that shows you looked.
No text outside finance gives a number for the interval. The implementing regulation for listed digital providers says planned intervals. Pick one, shorter for critical systems and for administrators, and keep to it.
basis NIS2 Art. 21(2)(i); IR 2024/2690 Annex 11.2.2(b), 11.2.3 as a reference. The interval is your choice.
how the comparison catches access that outlived the job
- 1hr listwho left or changed role since the last run
- 2enabled accountsan export from each important system
- 3compareevery name that sits in one list and not the other
- 4fix and recorddisable, trim, ask the owner, and note the date
what the comparison can turn up
- leavers still enabledan open door with a name on it
- movers with old rightsaccess that grew with each new role
- accounts nobody ownsno one to ask, so no one to approve
- dormant accountsno sign-in for the period you set
basis working practice. No legal text sets this.
an example
Picture a company of 150 people with several business systems and an HR system that records every exit.
HR records a leaver and the message stays in HR. A sales manager who moved to finance still opens the customer database. Once a year someone clicks approve on a list nobody read, and the record shows that nothing was removed.
Each month HR's list of leavers and movers is compared with enabled accounts, and the differences are fixed that week. Every system has a named owner who confirms the access list on a set rhythm, and the signed result shows what was removed.
An illustration. It is not a real case.
what it has to do for each rule
| rule | where | what the text asks | what the control has to do |
|---|---|---|---|
| NIS2 | NIS2 Art. 21(2)(i) | Human resources security, access control policies and asset management. | Tie access to the HR record: a joiner, mover or leaver event starts a change and someone completes it. |
| IR 2024/2690 | IR 2024/2690 Annex 11.2.2(b) | Listed digital providers: change rights on termination or change of employment. | Disable or change accounts on the last working day or on the move, and compare HR's list with enabled accounts. |
| IR 2024/2690 | IR 2024/2690 Annex 11.2.2(e) | Listed digital providers: a register of access rights granted. | Keep an access register for the important systems, with an export for each. |
| IR 2024/2690 | IR 2024/2690 Annex 11.2.3 | Listed digital providers: review access rights at planned intervals and document the result. | Pick an interval, have each system owner confirm who should have access and save the signed result with the removals. |
| IR 2024/2690 | IR 2024/2690 Annex 11.5.4 | Listed digital providers: review identities and deactivate those no longer needed without delay. | Review enabled accounts with no recent sign-in and deactivate the ones nobody claims. |
| DORA | DORA Art. 9(4)(c) | Limit physical and logical access to what approved functions need. | Remove rights that a change of role has made unnecessary, as well as those of people who left. |
| GDPR | GDPR Art. 32(1)(b) | Ongoing confidentiality of processing systems, sized to risk. | Review the systems that hold personal data more often than the rest. |
basis NIS2 Art. 21(2)(i); IR 2024/2690 Annex 11.2.2(b), 11.2.2(e), 11.2.3, 11.5.4 as a reference; DORA Art. 9(4)(c); GDPR Art. 32(1)(b). What the control has to do is practice.
what to look for when you choose
- Does a leaver event in the HR system reach IT on its own, or does someone have to remember to send it?
- Can you export, for each system, who has access and through which group or role?
- Can a system owner approve or remove access from that list without help from IT?
- Does the review record the date, the reviewer and what was removed?
- Does it show last sign-in, so dormant accounts stand out?
- Can you set a different interval for critical systems?
- Does it cover guest, supplier and shared accounts, with a sponsor and an end date?
- Does anything remind owners who have not finished, and does the record keep their answer?
basis working practice. No legal text sets this.
three levels, from first step to strong
Each level adds something visible. Stop where the risk you accepted allows.
- start
Compare HR's list of leavers from the last six months with enabled accounts, disable the differences and name an owner for each important system.
- solid
Run the comparison every month, export access for each important system and have the owners sign a review on a set rhythm, with removals recorded.
- strong
Review critical systems and administrators more often, flag accounts with no recent sign-in, give guests and suppliers a sponsor and an end date, and ask why when a review removes nothing.
basis working practice. No legal text sets this.
where it goes wrong
HR knows, IT does not
Without a monthly comparison of HR's leaver list with enabled accounts, the gap stays open for as long as nobody looks.
movers keep every old right
People who change role gather access. The mover step is the one most often skipped, because nothing is switched off when no one leaves.
the review is a click-through
An owner who approves everything has not reviewed anything. Record what was removed, and ask what it means when the answer is nothing.
owners nobody named
A system without an owner has no one to approve access, so its review never happens. Name the owner first.
basis working practice. No legal text sets this.
the proof it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| HR leaver list compared with enabled accounts | HR and head of IT | monthly |
| access register: one export per important system | system owners | quarterly |
| signed access review with removals | system owners | every 6 months, critical systems every quarter (your choice) |
| list of accounts with no sign-in for the period you set, with the decision on each | head of IT | monthly |
| guest and supplier export with sponsor and end date | head of IT | quarterly |
basis practice. The rhythms are your choice; the implementing regulation says planned intervals.
check it yourself
- 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)
your next step
Compare HR's list of leavers from the last six months with your enabled accounts and disable the differences.