Annex A 5.16: Identity Management

Annex a 5.16: identity management requirement means you must run a governed identity lifecycle so every user, admin, service account, and API identity is uniquely identified, appropriately authenticated, authorized, reviewed, and removed on time. To operationalize it, define identity types and owners, standardize joiner/mover/leaver workflows, and keep recurring evidence that access is issued, changed, and revoked under control. ¹

Key takeaways:

• Put one accountable identity governance process over all identity types (workforce, privileged, service, third party, and customer identities).
• Operationalize with lifecycle controls: request/approve/provision, periodic review, and deprovisioning with proof.
• Audit readiness depends on evidence: tickets, approvals, system logs, and access review results mapped to 5.16.

Annex A 5.16 sits in the organizational controls of ISO/IEC 27001:2022 and drives a practical outcome: identities are managed deliberately, not ad hoc. Most security failures you will see in audits are not “no MFA” in isolation; they are lifecycle failures. Accounts exist without owners, service accounts never expire, third party access persists after projects end, and privileged access gets granted outside a governed channel.

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to treat identity management as an operational control set with measurable outputs: complete inventory of identity types, documented provisioning standards, consistent approvals, and routine validation that access still matches role and business need. ISO 27001 does not require a specific tool, but auditors will expect a repeatable process that works across your environment (cloud consoles, SaaS apps, endpoints, on‑prem directories) and produces evidence on demand. This page turns annex a 5.16: identity management requirement into a checklist you can assign, track, and defend in an audit. ¹

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.16 implementation expectation (Identity Management).” ¹

Operator interpretation: You must establish and operate a managed approach to identities across the organization. In practice, an auditor will look for (1) defined identity types and authoritative sources, (2) controlled issuance and change of identities and their credentials, (3) governance over privileged and non-human identities, and (4) timely removal and periodic validation. Your job is to make the lifecycle provable, not aspirational. ¹

Plain-English interpretation (what 5.16 requires)

Identity management under Annex A 5.16 means:

• Every account represents a known identity (human or non-human) with an owner and purpose.
• Access is granted through a controlled path (request, approval, provisioning) tied to role and business need.
• Changes are governed (role changes, transfers, temporary access, privilege elevation).
• Access is removed promptly when no longer required, and the organization can prove it.
• The process covers your whole estate, including third-party identities and service accounts, not only your primary directory. ¹

Who it applies to (entity and operational context)

Entity scope: Any organization running an ISMS under ISO/IEC 27001, including service organizations, because identities are the control plane for system access. ²

Operational scope (typical):

• Workforce identities: employees, interns, temps.
• Third party identities: contractors, consultants, managed service providers, implementation partners.
• Privileged identities: admin accounts, root access, emergency/break-glass accounts.
• Non-human identities: service accounts, workload identities, automation users, CI/CD tokens, API keys.
• Customer identities (if applicable): application users and administrative tenants.

Systems in scope: identity providers (IdP), directories, HRIS, ticketing, endpoint management, cloud IAM, SaaS applications, databases, code repositories, support tooling, and any system with local accounts.

What you actually need to do (step-by-step)

Use this as a build sheet. Assign an owner per step and require evidence outputs.

1) Define identity governance (policy + ownership)

1. Name an Identity Control Owner (often Security, IT, or IAM team) and a Process Owner for joiner/mover/leaver (often IT Ops).
2. Define identity types you support (workforce, privileged, service, third party, customer) and minimum control expectations for each.
3. Establish authoritative sources:
   • HRIS (or equivalent) for workforce status.
   • Contracting/procurement source for third party start/end dates.
   • CMDB/IaC repo for service accounts and workloads.
4. Document standards: unique IDs, naming conventions, credential rules, and where identities may be created.

Operator tip: Auditors look for “who can create an identity where” and “how you prevent side-door accounts.”

2) Build a complete identity inventory (including non-human)

1. Export accounts from your IdP/directory and from high-risk platforms (cloud, code repo, ticketing, finance, data stores).
2. Normalize into a register with fields: identity type, system, owner, purpose, privilege level, creation date, last used, and disable/delete status.
3. Flag unknowns: orphaned accounts, shared accounts, inactive accounts, unowned service accounts.

Minimum outcome: You can answer, “How many privileged accounts exist and who owns them?” without hand-waving.

3) Standardize joiner/mover/leaver workflows

1. Joiner (provisioning):
   • Require a request (ticket or workflow) that states role, access needed, and start date.
   • Require approval rules (manager + system owner for sensitive apps).
   • Provision through centralized identity where possible (SSO/SCIM), otherwise through controlled admin steps.
2. Mover (change):
   • Triggered by HR changes or manager request.
   • Remove old role access before adding new access where feasible.
   • Treat privilege elevation as a separate, higher scrutiny workflow.
3. Leaver (deprovisioning):
   • Triggered by HR termination or contract end.
   • Disable identity quickly in the authoritative identity system, then cascade to downstream systems.
   • Capture proof of disablement and downstream removals (logs or admin screenshots are acceptable if consistent and controlled).

Third party access: Put end dates on third party identities at creation. If your systems cannot enforce expiry, create a scheduled review/disable job tied to contract end.

4) Control privileged identities explicitly

1. Maintain a privileged account register: admin users, elevated roles, break-glass accounts.
2. Require stronger controls for privileged identities:
   • Separate admin accounts from daily-use accounts where possible.
   • Approval + time-bound access for elevated permissions where your tooling supports it.
   • Additional logging and review expectations for privileged activity.
3. Define and test emergency access procedures (break-glass) with documented access and post-use review.

5) Govern service accounts, API keys, and automation identities

1. Require an owner (person or team) and purpose for every non-human identity.
2. Store secrets in an approved secrets manager; prohibit embedding long-lived credentials in code repositories.
3. Rotate credentials based on your risk posture and technical feasibility; document exceptions with compensating controls.
4. Review non-human identities for inactivity and excessive privilege.

6) Implement periodic access reviews (recertification)

1. Define review populations: privileged access, sensitive systems, and high-impact data repositories.
2. Assign reviewers: system owners and business owners, not only IT.
3. Record outcomes: approved, removed, modified, exception granted (with rationale and expiry).
4. Track remediation to completion.

Audit reality: A well-run access review closes many 5.16 findings because it proves ongoing control operation.

7) Map and evidence the control (make it auditable)

Create a simple “control operation” narrative:

• Inputs (HR events, tickets, contract end dates)
• Activities (approval, provisioning, review, removal)
• Outputs (logs, tickets, review attestations)
• Frequency (event-driven + periodic reviews) Then map those outputs to Annex A 5.16 so evidence collection is routine, not a scramble. ¹

Required evidence and artifacts to retain

Keep artifacts that prove both design (what you intended) and operation (what you did).

Core documents

• Identity Management Policy / Standard aligned to Annex A 5.16.
• Role/access model (even if lightweight): roles, groups, entitlement descriptions, owners.
• RACI: identity owner, system owner, approvers, IAM/IT operators.

Operational evidence (samples auditors ask for)

• Joiner/mover/leaver tickets with approvals and timestamps.
• Provisioning logs (IdP, directory, SaaS admin audit logs).
• Deprovisioning proof for leavers and expired third party accounts.
• Privileged access register and approvals for elevation.
• Service account inventory with owners and purpose.
• Access review packages: reviewer lists, results, remediation tracking.

Retention approach: Align to your internal audit and legal retention requirements; auditors care that evidence is accessible and consistent.

Common exam/audit questions and hangups

Expect these prompts:

• “Show me your identity types and how they are governed.”
• “Where is the authoritative source for employment status and contractor end dates?”
• “Provide a sample of terminated users and prove access was removed.”
• “List all privileged accounts and show approvals for each.”
• “How do you identify and control service accounts and API keys?”
• “Show your last access review for a critical system and the remediation results.”

Hangups that cause findings:

• Manual processes with no traceable approvals.
• Deprovisioning that relies on email notifications and good intentions.
• “We use SSO” presented as a complete identity management program without lifecycle proof.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating IAM as only the IdP.
   Fix: include local accounts, cloud IAM, SaaS-native users, and non-human identities in the scope register.

2. Mistake: no owner for service accounts.
   Fix: require a human owner and a renewal/attestation step; disable accounts without owners.

3. Mistake: contractors live forever.
   Fix: set expiry at creation; tie renewals to procurement or contract management signals.

4. Mistake: access reviews are performed but not closed.
   Fix: track remediation as tickets with due dates and evidence of completion.

5. Mistake: privileged access is “whoever needs it.”
   Fix: define privileged roles, document approvals, and keep a privileged account register.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Operationally, weak identity management increases likelihood of unauthorized access, persistence after termination, and misuse of privileged or non-human credentials. Those are common root causes in incident investigations and drive audit findings because they undermine multiple controls that depend on identity. ²

Practical execution plan (30/60/90-day)

Use phased milestones rather than calendar promises; scope and tooling vary by environment.

First 30 days (stabilize and define)

• Assign control owner, process owner, and system owners for critical apps.
• Publish an Identity Management standard: identity types, approvals, and deprovision triggers.
• Produce a first-cut inventory: directory/IdP export plus privileged accounts in key systems.
• Choose evidence format: where tickets, logs, and review outputs will be stored for audit.

Days 31–60 (operationalize workflows)

• Implement joiner/mover/leaver workflows in your ticketing or IAM workflow tool.
• Enforce approvals for sensitive systems and privileged access.
• Build a service account register with owners and purpose.
• Pilot an access review for privileged access and one critical business system.

Days 61–90 (make it repeatable and auditable)

• Expand inventory coverage to remaining SaaS and cloud platforms.
• Establish periodic access reviews for defined populations and track remediation to closure.
• Add exception handling: time-bound exceptions with documented compensating controls.
• Create an Annex A 5.16 control narrative and evidence index for your ISO audit pack.

Where Daydream fits naturally: If your bottleneck is evidence collection and audit readiness, Daydream can act as the system of record for control operation. Store the 5.16 control narrative, map required artifacts, schedule recurring evidence requests from IT and system owners, and keep an audit-ready trail without building spreadsheets that age poorly. ¹

Frequently Asked Questions

Does Annex A 5.16 require a specific IAM tool (Okta, Entra ID, etc.)?

No. ISO 27001 focuses on outcomes and control operation, not vendor selection. Auditors will still expect consistent lifecycle execution and evidence across systems. ²

Are service accounts and API keys in scope for identity management?

Yes, in practice they must be. Treat non-human identities as first-class identities with owners, purpose, and governed credential handling, because they authenticate and authorize access like users do. ³

How do we handle third party users who need temporary access?

Create third party identities with an owner, a documented business purpose, and a planned end date. Require renewal/attestation for extensions and disable access when the engagement ends.

What evidence is usually strongest for provisioning and deprovisioning?

A ticket or workflow record showing request and approval, combined with system audit logs showing the account was created/changed/disabled. Pairing “who approved” with “what happened in the system” reduces audit debate.

We have local accounts on some systems. Is that an automatic failure?

Not automatically, but it increases scrutiny. You need compensating governance: inventory of local accounts, approvals, periodic review, and a clear deprovision trigger tied to HR or contract status.

How should we define “privileged” for purposes of 5.16?

Define it based on capabilities, not job titles. Privileged identities can administer systems, change security settings, manage identities, or access sensitive data at scale; keep a register and require higher scrutiny approvals.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview

3. ISMS.online Annex A control index