--- title: "ISO 27001:2022 Annex A 5.16 identity management: joiner to leaver" canonical: https://www.grcmana.io/vault/iso-27001/annex-a-5-16-identity-management published: 2023-02-22 updated: 2026-10-07 author: "Harry West" framework: "ISO 27001" control: "A.5.16 Identity management" journeyStage: implementation --- # ISO 27001:2022 Annex A 5.16 identity management: joiner to leaver ## Key takeaways Annex A 5.16 governs the whole life of every identity, human and machine, from verified creation to prompt retirement. Drive the lifecycle from HR events, centralise accounts in one identity provider, and let the leaver reconciliation prove same-day revocation. Shared logins and unowned service accounts are the findings auditors and enterprise buyers look for first. - **Scope of the control** — The control governs the whole life of an identity: justified creation, tracked change and prompt retirement, with each human account belonging to exactly one accountable person. - **Leaver deadline** — Set a stated deadline for disabling leavers and measure it. Same day is the defensible standard, and the HR-to-directory reconciliation is the artefact that proves it. - **Machine identities** — Service accounts, CI/CD runners, bots and integrations need a named human owner, their own approval route and a register, reviewed on the same cadence as staff accounts. - **Shared accounts** — Shared logins are tolerated only as documented exceptions, with a written business case, explicit approval and compensating measures such as enhanced logging, and each is treated as something to retire. The enterprise questionnaire asks one question: how fast are leavers disabled? You answer "quickly", and the buyer asks for the evidence. This guide covers ISO 27001:2022 Annex A 5.16 identity management for UK regulated firms and B2B SaaS companies with 25–250 staff. It shows how to run joiners, movers and leavers from HR events and how to govern shared and machine accounts. It also covers the reconciliation an auditor accepts as proof that leavers lose access the same day. It is written for the security or IT lead who owns the control with a small team. ## What does ISO 27001 Annex A 5.16 require? ISO/IEC 27001:2022 Annex A control 5.16 identity management governs the whole life of every identity: justified creation, tracked change and prompt retirement. Each human account belongs to one person, machine identities get their own approval route, and key events are logged. The control supplies the 'who' beneath A.5.17's secrets and A.5.18's access rights. ISO/IEC 27001:2022 Annex A 5.16 identity management starts the clock at creation. Before an account exists, you confirm who is asking and why the business needs it. Where sign-in is delegated to an outside provider, you assess the trust you inherit rather than assume it. Nobody holds duplicate identities in the same system. A.5.16 identity management ISO/IEC 27001:2022 is a preventive control. Verified creation and prompt retirement stop illegitimate accounts from existing, which is where account-based attacks start. Attribution matters as much as secrecy here, because one person per identity is what makes logs mean something. Auditors begin here because every later question depends on it. You cannot review the access rights of an account nobody can attribute, and you cannot defend a secrets policy for an identity nobody approved. The 2013 edition covered less. Its nearest equivalent, A.9.2.1, dealt with registering and de-registering users. The 2022 control governs the entire life of every identity. It also pulls in the service accounts, bots and devices that most 2013-era processes ignored. ## How does ISO 27001 identity management work from joiner to leaver? ISO 27001 identity management runs on HR events: hiring creates an account after verification, a role change updates it, and departure disables it by a stated deadline. Same day is the defensible standard. Each step needs a defined route and a record, so the joiners, movers and leavers policy the NCSC recommends is visibly working. HR records should drive those routes, not IT guesswork. The [NCSC 10 Steps to Cyber Security: Identity and access management](https://www.ncsc.gov.uk/collection/10-steps/identity-and-access-management) asks for a joiners, movers and leavers policy so access can be revoked when no longer needed or changed for movers. It adds that temporary accounts, such as those created to test a process, should be removed or suspended once they are no longer required. Each stage has its own job: - **Joiner: verify, then issue.** HR records the hire. IT confirms identity in line with pre-employment screening, then creates the account against a recorded approval and a stated need. For a system identity, the check is that the requesting service and its business case are real. - **First credential: deliver safely.** Hand it over out-of-band, force a change on first use and enrol MFA before the account touches anything real. - **Mover: swap, don't stack.** A role change modifies the account. New access arrives and old access leaves in the same change. - **Leaver: disable by the deadline.** Departure disables every account by the stated time, including the SaaS logins that sit outside single sign-on. A leaver process with no deadline isn't a process. It's a hope. Measure the deadline too. A stated service level only counts if you can show each leaver met it, and the reconciliation in the evidence section does exactly that. Three habits undo the lifecycle: - **Corridor departures.** Leavers are communicated by conversation, so orphaned accounts stay live for weeks. - **Verbal say-so.** Accounts are created without an approval trail or a verification record for the auditor's sample. - **Additive moves.** Movers keep their old identity footprint alongside the new one, so privilege builds up with every promotion. ## How do you implement ISO 27001:2022 Annex A 5.16 identity management in a 25–250 person firm? Fold the lifecycle rules into your access control policy rather than writing a standalone procedure; that is proportionate at 25–250 staff. Then centralise accounts in one identity provider with single sign-on, so there is exactly one place where accounts are created, suspended and audited. With a modern IdP already in place, expect one to two weeks of work. For ISO 27001:2022 A.5.16 identity management, what matters is that creation, change and retirement each have a defined route. A lifecycle section of a page or two inside the access control policy meets that. A separate procedure becomes worthwhile only when identity volume or regulatory scrutiny demands it. Sequence the work in this order: 1. **Map where accounts live.** Export users from the identity provider and from every SaaS admin panel that holds its own list. 2. **Move everything behind one IdP.** Put each application behind single sign-on. Without a modern IdP, this step comes first and dominates the effort. 3. **Write the lifecycle section.** Record the join, move and leave routes, the leaver deadline and the shared-account exception route. 4. **Clean the directory.** Merge duplicate identities, remove orphans and name an owner for every machine account. 5. **Switch on the log and the sweep.** Record creations, permission changes and disablements, and sweep for dormant accounts on a schedule. With an IdP already running, steps three to five are the policy work and account hygiene that fill those one to two weeks. Identity sprawl is the pitfall that step two removes. A dozen unconnected SaaS admin panels are unmanageable by hand, each with its own copy of the user list. One person ends up with two identities in the same system, and attribution fails as surely as it does with a shared login. One IdP lets a lean IT team show an auditor a single export instead of twelve. ## Are shared accounts allowed under ISO 27001 A.5.16? Shared accounts are not flatly banned, but the bar is high. Each human identity belongs to one person, so administrators get named admin accounts. A genuinely unavoidable shared login, such as a front-desk till, needs a written business case, explicit approval and compensating measures, typically enhanced logging. Treat each one as an exception to retire. Attribution is why the bar sits where it does. If five people used the login, nobody did. That failure undermines disciplinary action, legal position and the regulatory narrative all at once. A shared login doesn't save time. It moves the cost to the investigation. An exception record is short. It holds: - the business case for why a personal account cannot work; - the named approver and the approval date; - the compensating measures, typically enhanced logging of what the account does; - a custodian accountable for it; and - a review date with a path to retirement. Generic logins multiply when nobody is asked to justify them. The support@ mailbox, the admin account and the shared deploy user appear one convenient moment at a time. None has an owner, and nobody can say who did what with them. A scheduled search of the directory for generic names turns the pile back into a short register. ## How do you govern service accounts, bots and API keys under A.5.16? Give every machine identity a named human owner, its own approval route and a place in a register. Then review them on the same cadence as your human accounts. Service accounts, CI/CD runners, bots and integrations often outnumber staff. The person who requested one should never be the only one who knows it exists. The fastest-growing identity exposure isn't human at all. Machine identities hold standing privileges and sit unmonitored by default, which is why attackers and auditors have both moved their attention here. A service account nobody owns is a credential nobody is watching. The register is where ownership becomes visible. Each entry carries: - **Owner:** a named person, not a team mailbox. - **Purpose:** the business reason the identity exists. - **Scope:** the systems it touches and the privileges it holds. - **Approval:** who approved it, and when. - **Expiry or review date:** when someone must confirm it is still needed. The usual failure is the credential created mid-sprint. A CI/CD runner token or an integration key solved Tuesday's problem, then never entered an inventory, never got reviewed and never expired. Making registration part of the ticket that creates the credential closes that gap before it opens. ## What evidence settles an A.5.16 audit? The leaver reconciliation settles most of the control: HR departure dates lined up against directory disablement timestamps. If dates and timestamps match across a sample, the auditor relaxes. If you cannot produce the comparison at all, everything else gets second-guessed. Supporting evidence includes provisioning records, an identity inventory covering machines, and lifecycle logs. Build the reconciliation from two exports. Pull departures for the audit period from the HR platform and disablement timestamps from the directory. Place them side by side, with the gap for each leaver. Add a note explaining any exception. One sheet then answers the auditor's first question before it is asked. Keep the supporting set alongside it: - the lifecycle rules, usually a section of the access policy; - provisioning records showing who asked, who approved and the stated need; - verification and screening records from before credential issue; - an identity inventory, being the IdP export plus the service-account register with named owners; - lifecycle event logs and the dormant-account sweep results; and - periodic review sign-offs from system owners. If the reconciliation shows a gap, show it with its cause. An honest exception with an explanation is easier for an auditor to accept than a clean sheet that disagrees with the logs. ## What will an auditor ask about ISO 27001 A.5.16, and how is it graded? An ISO 27001 2022 Annex A 5.16 identity management audit traces your newest starter from request through approval to activation. It traces leavers from HR date to disablement timestamp and mines a directory export for dormant, shared and duplicate accounts. The auditor also picks one service account and asks for its owner. Repeated late disablements grade major. Expect five questions in the room: - "How does an account come to exist here? Walk me through your newest starter." - "Do you have any shared logins, and if so, where's the approval and what compensates?" - "How would you find an account that should be dead but isn't?" - "Who owns this service account, and when did anyone last confirm it's still needed?" - "How do first credentials reach a new starter, and what forces them to change?" Certification-body practice grades findings like this: - **Major:** leavers still active weeks after departure, or an unmanaged culture of shared administrator credentials. - **Minor:** a single late disablement, one creation missing its approval, or a dormant account that slipped the sweep. Minors add up. Several of them repeating across the sample read as a pattern, and a pattern grades major. Preparation therefore means running your own sample first and fixing the repeat offenders, rather than defending each one in the room. ## How do you automate ISO 27001 A.5.16 evidence with GRC engineering? Wire the HR platform to the identity provider so starter, mover and leaver events flow through automatically, with platform timestamps as evidence. Add a scheduled job that diffs the HR roster against active accounts. Then add a managed machine-credential register, lifecycle events streamed to the SIEM, and automatic suspension of dormant accounts at your threshold. Identity lifecycle is arguably the best return on automation in the whole of Annex A, because the evidence falls out of the configuration: - **HR-to-IdP wiring.** Disablement fires the moment HR records the departure, and the platform's timestamps are the evidence. No checklist required. - **Weekly orphan detection.** A job diffs the HR roster against active directory accounts and flags anything live without an employee or a documented exception. It is the audit's favourite test, run weekly instead of annually. - **Machine-credential register.** Owners, purposes and expiry dates, with alerts on anything unowned or overdue for review. - **Lifecycle events in the SIEM.** Creations, privilege changes and disablements land as they happen, so record-keeping becomes configuration rather than discipline. - **Dormancy by policy.** Idle accounts suspend automatically at the threshold. Ninety days idle is the conventional trigger, and genuine seasonal users sit on an exception list documented once. Dormant accounts stop silting up the directory because nobody has to remember to hunt for them. The sweep runs, the exceptions are known, and the output is saved as evidence. The payoff is commercial as well as technical. When an enterprise buyer asks how fast leavers are disabled, you answer with a timestamped export instead of a promise. Buyers ask it because it is a one-question test of operational discipline. | Lifecycle event | Manual route | Engineered route | Evidence produced | | --- | --- | --- | --- | | Joiner | Email request, account built by hand | HR hire event creates the account in the IdP | Approval record and creation timestamp | | Mover | Access added, old access forgotten | Role change swaps the access set | Permission-change log entry | | Leaver | Corridor message to IT | HR departure disables every account | Reconciliation of dates and timestamps | | Machine identity | Created mid-sprint, never listed | Register entry required at creation | Owner, purpose and expiry record | | Dormant account | Annual hunt, if at all | Automatic suspension at threshold | Sweep results and exception list | ## Frequently asked questions ### Does A.5.16 cover devices as well as service accounts? Yes. Machine identities under A.5.16 include devices as well as service accounts, bots and integrations, so they need their own approval route and ongoing supervision. Start with the identities that authenticate to your systems with standing privileges, such as service accounts and device certificates, then work outward. Each one still needs a named human owner in the register. ### Is 90 days the required dormant-account threshold under A.5.16? No. Ninety days is a convention, not a requirement. An auditor tests that your threshold is written down and applied, not which number you chose. Consider a shorter window for privileged and machine accounts, where an idle credential carries the most risk. Measure idle time in every system, because an app outside single sign-on keeps its own last-login record. ### Does A.5.16 allow sign-in through an outside identity provider? Yes, but the trust you inherit has to be assessed rather than assumed. Check how the provider handles its own joiners and leavers, whether it enforces MFA and which logs you can obtain from it. Record that assessment alongside your supplier reviews, because an auditor will ask how a deprovisioned user loses access through that route. ### Should A.5.16 leaver accounts be deleted or just disabled? Disable on the leaver's last day, then delete on a retention schedule. Disabling stops the access immediately and preserves the lifecycle record, while deletion handles data you no longer need. The [ICO Storage limitation principle guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/) expects you to review the data you hold periodically and erase or anonymise it when it is no longer needed. Set the schedule and log each deletion.