ISO/IEC 27001:2022 · derived mapping target
A.5.16Identity management
Manage digital identities across their full lifecycle, from creation to removal, so every account maps to a known person or service. Stale or shared identities are a frequent source of breaches.
Mapping at a glance
A.5.16Identity managementISO/IEC 27001:2022
RCF-0061Identity lifecycleIdentity & Access Management · PolicyRCF-0062Identity lifecycleIdentity & Access Management · ProcessRCF-0063Identity lifecycleIdentity & Access Management · TechnicalRCF-0073SSO & federationIdentity & Access Management · PolicyRCF-0074SSO & federationIdentity & Access Management · Process
A.5.16 is covered by 10 Sekit CSF controls. +5 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0061Identity lifecycle · PolicysupportsSekit's Identity lifecycle control documents how accounts are requested, created, modified and removed across company systems, the written commitment behind A.5.16; the technical enforcement and joiner-mover-leaver procedure that carry it out day to day are mapped separately here.RCF-0062Identity lifecycle · ProcesssupportsRunning onboarding and offboarding from a repeatable checklist is what keeps A.5.16's lifecycle rule from depending on someone remembering every step for every new hire.RCF-0063Identity lifecycle · TechnicalsupportsWiring systems so a central identity platform disable action revokes access everywhere removes the manual steps that are the usual reason A.5.16's lifecycle promises fail in practice.RCF-0073SSO & federation · PolicysupportsRequiring business applications to sign in through the central identity provider is what makes every account traceable to a known person, the mapping A.5.16 asks for.RCF-0074SSO & federation · ProcesssupportsConnecting a new application to the identity provider as a routine step of adoption means it inherits the account lifecycle from day one, matching A.5.16's full-lifecycle scope.RCF-0075SSO & federation · TechnicalsupportsAuthenticating critical business applications through the central identity provider means every account there is tied to a known identity, the mapping A.5.16 requires.RCF-0088JML (joiner-mover-leaver) · PolicysupportsSekit's JML procedure names who triggers each joiner, mover and leaver event and the deadline for revoking a leaver's access, but writing the procedure down does not itself run it: the automated execution A.5.16 also needs is mapped separately as a technical control.RCF-0090JML (joiner-mover-leaver) · TechnicalsupportsConnecting HR or the staff directory to the identity provider so lifecycle events fire automatically closes the manual relay gap that stale or orphaned accounts, A.5.16's core risk, come from.RCF-0327Offboarding vendors · TechnicalsupportsAutomating supplier access revocation and technically confirming nothing residual remains applies A.5.16's lifecycle discipline to non-employee identities, not only staff accounts.RCF-0336Cloud IAM · TechnicalsupportsEnforcing MFA, role-based permissions and conditional restrictions in the cloud is identity management applied technically to cloud accounts, the systems A.5.16 asks organisations to cover.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Joiner-mover-leaver procedure
The process the company follows when someone joins, changes role, or leaves: how access and devices are granted and removed.
From the Sekit evidence catalog
In practice
The practical version of this control is one identity per person, wired through a central identity provider, with the joiner-mover-leaver procedure as the operating document auditors ask for by name. What breaks in real companies is the manual step in the middle: HR tells a manager, the manager tells IT, and somewhere in that relay a leaver's account stays active for weeks because nobody closed the loop. Auditors test this directly by asking for a list of accounts disabled in the last quarter and comparing dates against real departure dates from HR records.
Common gaps
The joiner-mover-leaver procedure exists on paper, but leaver accounts stay active for one to three weeks past the departure date because the HR-to-IT handoff is manual.
Service accounts and shared mailboxes are not tied to any named individual, so nobody can say who is accountable if one of them is compromised.
A mover event, an internal role change, only removes old access when someone happens to notice, rather than as an automatic step of the transfer.
Questions your auditor will ask
How does an account get created, and how is it tied to a real person?
Walk through the joiner-mover-leaver procedure's onboarding step, showing the account created against a verified HR record rather than a free-text request.
What happens to an account the day someone leaves?
Point to the leaver step of the procedure and the deadline it sets for disabling access, ideally same-day, plus evidence of recent leaver dates matched against disable dates.
Are there any shared or generic accounts, and how are they controlled?
Identify any shared logins that remain, the business reason each one still exists, and the compensating control, such as logged access, applied to it.
Where regulation demands it
NIS2 art. 11.5 (Identification) requires the same mapping of every account to a known person or service.
ENS op.acc.1 (Identificación) is Spain's equivalent baseline for identity management across its lifecycle.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.5.16?”
Also via MCP, free with account