Control Definition
Identities — for people and for non-human entities such as services and devices — must be managed across their entire lifecycle: created only for a legitimate need, verified before issuance, kept unique to one accountable entity, updated as circumstances change, and disabled or removed promptly when no longer required.
Control Objective
To make every action on information and systems attributable to exactly one accountable entity, giving authentication, access rights, and audit trails a trustworthy foundation to operate on.
What This Really Means
Identity is the unit of accountability in an ISMS. Every downstream control — the secrets in A.5.17, the access rights in A.5.18, the privileged accounts in A.8.2, the logs in A.8.15 — silently assumes that an account maps to exactly one answerable person or system. A.5.16 is where that assumption is made true. In the access chain, A.5.15 writes the rules, A.5.16 establishes who exists, A.5.17 protects the proof, and A.5.18 manages what each identity can reach.
In practice the control means running identities like assets with a lifecycle. Creation anchors to an authoritative source — a person exists in the HR system or a contractor agreement before any account exists for them — and the requester's identity is verified before credentials are issued, because impersonation at issuance bypasses every authentication control downstream. Uniqueness is the discipline at the center: one identity per person, never reused after departure, with secondary admin accounts still traceable to the same human. When people change roles, the identity record changes with them; when they leave, the identity is disabled fast and deleted after a retention period.
Two populations need explicit handling. Shared and generic accounts — the ops mailbox, the legacy system that supports a single login — are permitted only as documented exceptions: registered, justified, assigned to a named owner, wrapped in compensating controls such as credential vaulting and session logging, and revalidated periodically. And non-human identities — service accounts, API clients, machine and workload identities — fall squarely inside the control, with the same expectations of approval, ownership, scoping, and removal. In cloud-heavy environments they outnumber the humans, which makes their inventory the harder half of the work.
For auditors, the heart of A.5.16 is the orphaned account. They will take a list of recent leavers from HR and check the directory and key applications for accounts that should be dead but are not. Pass or fail turns less on whether an orphan exists than on whether your own lifecycle — automated triggers plus periodic reconciliation — would have found it first.
Why It Matters
Orphaned accounts are standing backdoors. An identity that outlives its owner keeps its passwords, its sessions, and its entitlements, with nobody left to notice anomalous use — which is why credentials of former employees and forgotten service accounts appear so regularly in breach narratives. The risk compounds quietly: every missed leaver, every unowned service account, every shared login adds to an attack surface that no firewall sees.
The deeper damage is to attribution. When an account maps to two people — or to nobody — logs can say what happened but not who did it. Investigations stall, disciplinary and legal action loses its evidence base, and every control that depends on knowing the actor inherits the defect: access reviews cannot certify rights nobody owns, and incident response cannot scope a compromise it cannot attribute.
When identity lifecycle discipline slips, the consequences are concrete:
- •Standing backdoors – leavers' still-active accounts give attackers and disgruntled former staff unwatched entry points
- •Broken attribution – shared logins reduce audit trails to "someone did it," stalling investigations and weakening legal positions
- •Service-account sprawl – unowned machine identities with broad rights and never-rotated secrets accumulate into the riskiest population in the estate
- •Impersonation at issuance – accounts created or reissued without verifying the requester hand out legitimate credentials to social engineers
- •Cascading control failure – access reviews, revocation SLAs, and log monitoring all silently depend on the identity layer being correct
Regional Compliance Context
Indian organizations face a regulatory premium on attribution. CERT-In directions require security logs to be retained for 180 days and incidents to be reported within 6 hours — both presume the ability to tie events to a specific identity, which shared and orphaned accounts quietly break. For banks, NBFCs, and other RBI-regulated entities, supervisory expectations include uniquely identifiable users and disciplined handling of dormant accounts, so identity hygiene gaps can surface in regulatory inspections, not just certification audits.
Implementation Guidance
Anchor Identity Creation to an Authoritative Source
No account should exist without a corresponding record in a system of truth: the HRIS for employees, a contract or sponsor record for externals. Automate the joiner feed from HR into the directory or identity provider where the stack allows, so identity creation is an effect of onboarding rather than an ad hoc IT favor. This single linkage is what makes every later reconciliation possible.
Verify Identity Before Issuing or Reissuing Credentials
Prove the person is who the request claims before any credential leaves the building: HR-verified identity at onboarding, sponsor confirmation for contractors, and a scripted verification procedure for helpdesk reissuance — because the reset path is the classic social-engineering door. Scale the rigor to the risk: a privileged account warrants stronger proofing than a standard joiner.
Enforce One Identity Per Person With a Naming Standard
Assign each person a unique identifier that is never reused after departure, and apply a naming convention that survives growth. Where the same person needs a separate privileged account, link it visibly to their primary identity (for example, an admin- prefix on the same handle) so attribution holds across both. Duplicate or recycled identities are what turn log forensics into guesswork.
Manage Shared and Generic Identities as Registered Exceptions
Where a shared account is genuinely unavoidable, register it: business justification, named owner, the compensating controls that restore accountability — vaulted credentials checked out per use, session recording or logging — and a revalidation date. Keep a standing goal of elimination, and rotate the credential whenever anyone with knowledge of it changes role or leaves.
Inventory and Assign Owners to Non-Human Identities
Pull every service account, API client, and machine identity from the directory and cloud platforms into an inventory with purpose, scope, a named human owner, and a review or expiry date. Vault their credentials under A.5.17 disciplines. Require the same fields at creation going forward — an ownerless service account today is an unexplained privileged identity in two years.
Automate Mover and Leaver Events
Wire HR change and termination events to the identity layer: disable accounts within a defined SLA (same business day is the common bar), update attributes and group memberships on transfers, and delete identities after a documented retention window. Cover the full estate — federated apps inherit the change through SSO, but local accounts in non-federated SaaS need their own deprovisioning step.
Reconcile Identities Against Reality on a Fixed Cadence
Quarterly, compare directory and per-application accounts against HR and contractor records, hunting orphans, duplicates, and dormant identities. Investigate every orphan for root cause rather than just deleting it — the broken trigger that produced it will produce more. Keep the reconciliation reports and remediation trail; they are the strongest evidence this control runs continuously.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.16:
Documentation
- Identity lifecycle procedure covering creation, verification, change, disabling, and deletion for human and non-human identities
- Shared and generic account register with business justifications, named owners, and compensating controls
- Service account and machine identity inventory with purpose, scope, owner, and review dates
- Deprovisioning records showing disable timestamps reconciled against HR termination dates
- Periodic identity reconciliation reports (directory versus HR) with orphan findings and remediation
Interviews
- IAM or IT administrator on how identities are created, which source of truth drives them, and how uniqueness is enforced
- HR representative on how joiner, mover, and leaver events reach IT and within what timeframe
- CISO or security manager on the shared-account exception process and ownership of non-human identities
Observations
- Auditor selects recent leavers from HR records and checks their account status live in the directory and key applications
- Live directory inspection for naming-standard conformity, duplicate identities, and dormant accounts
- A sampled service account examined for documented owner, purpose, scope, and last credential rotation
Practitioner Insights
The leaver sample is the first test I run on this control, on almost every audit: ten recent departures from HR, checked against the directory and two or three key applications. Orphaned accounts remain among the most common access findings I see, but the finding is rarely the account itself — it is what the orphan proves about the lifecycle. An organization whose own quarterly reconciliation caught and closed the gap before I arrived gets a very different report from one hearing about it for the first time in the closing meeting.
In startups the identity problem is sprawl, not malice — every SaaS tool bought over three years has its own local accounts, and nobody can list them all. The highest-leverage move is unglamorous: put everything that supports it behind single sign-on, so identity becomes one switch instead of forty. And register the shared accounts honestly. Every small company has an admin@ or an ops login; the ones that document it with an owner and a vaulted credential pass the audit, while the ones that pretend it does not exist get caught in the first interview.
Common Challenges & Solutions
Challenge
Account deactivation depends on someone remembering to email IT when a person leaves.
Solution
Make the trigger structural: an HRIS-to-identity-provider integration that disables accounts automatically on the termination date, or — where integration is out of reach — a binding rule that HR notifies IT the same day, backed by a weekly reconciliation as the safety net. Measure the gap between termination date and disable timestamp; that metric is the control.
Challenge
A legacy system supports only one login, so a shared account is genuinely unavoidable.
Solution
Run it as a managed exception: register it with a named owner and business justification, vault the credential so each use is checked out and attributable to a person, rotate it whenever anyone who knew it changes role or leaves, and revisit the justification at every review cycle. The exception is acceptable; the undocumented exception is the finding.
Challenge
Hundreds of service accounts exist and nobody knows what half of them do.
Solution
Inventory first: pull every non-human account from the directory and cloud platforms, then assign each to a human owner with a stated purpose and scope. For the unknowns, monitor before you kill — log activity for a cycle, then disable in stages with a rollback path. Going forward, require an owner, a scope, and a review date at creation so the sprawl cannot regrow.
Challenge
Contractors and partner staff get accounts outside the HR-driven lifecycle, and nothing triggers their removal.
Solution
Adopt a sponsor model: every external identity has a named internal sponsor, a contract-linked end date, and automatic disablement at expiry unless actively renewed. Tie the external-identity list into supplier management under A.5.19 so contract closure and account closure become the same event rather than two separate hopes.
Challenge
Local accounts in SaaS applications drift away from the central directory, accumulating users who left months ago.
Solution
Push everything possible behind SSO with SCIM provisioning so disablement propagates automatically. For applications that cannot federate, name an application owner accountable for a quarterly account-to-HR reconciliation, and list those apps explicitly in the leaver checklist — the non-federated long tail is where orphans live.
