IDM-03 Locking and withdrawal of user accounts in the event of inactivity or multiple failed logins
Automatically lock accounts of staff and automated system components left unused for two months, require authorised approval to reinstate them, revoke them outright after six months, and re-run the full granting procedur
4
artefacts
1
held by a system
2
at each review
moderate
to go live
Cloud console / configuration management
where the evidence lives
teal = a system already holds it · olive = produced at each review
system holds itEvidence a system already holds
- System configuration showing the dormancy threshold set at two months · Cloud console / configuration management
periodic reviewEvidence produced at each review
- Unlock approval records naming the authorising person or system component · Document repository
- List of accounts deleted at the six month point with evidence of full re-request where reinstated · Identity provider / directory
governing documentDocuments that govern the control
- Report of accounts locked for dormancy in the period with their lock dates · Policy repository / GRC workspace
First move
Start with the 1 of 4 artefacts that already live in a system (Cloud console / configuration management); keep the periodic reviews but log each one as a dated record with a named reviewer.
Common gaps auditors find
- Dormancy locking applies only to interactive staff logins and skips technical accounts
- Locked accounts survive far beyond six months because deletion is a manual housekeeping task
- Service desk reactivates dormant logins on a phone call with no recorded authorisation
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetIDM-02 Granting and change of user accounts and access rights · IDM-04 Withdraw or adjust access rights as the task area changes