Skip to content
compliancebase
ISO 27001A.5 — Identity management

A.5.16

Identity management

ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026

Objective

Manage the full lifecycle of identities — provisioning, modification, and removal — consistent with the access control policy.

Points of focus

  • Provisioning is triggered from a system of record (HRIS or contractor tracker), not ad hoc requests
  • Role changes trigger access re-evaluation, not just new grants layered on old ones
  • Deprovisioning happens within a defined SLA of termination or contract end
  • Non-human identities (service accounts, API keys) are inventoried with an owner and rotation plan

Implementation notes

Automate provisioning and deprovisioning from the HRIS into the IdP so account lifecycle doesn't depend on someone remembering to file a ticket. Set contractor accounts to expire on the contract end date by default, requiring an explicit extension rather than an explicit removal. Inventory service accounts and API keys separately from human identities, with an owner and a rotation cadence, since these are the identities most likely to be forgotten and most likely to hold broad access. Track deprovisioning time-to-complete against an internal SLA — same day for high-risk terminations is a reasonable bar — and review misses as an operational metric, not just an audit artifact.

Audit tip: Pull the last three terminations and show the gap between the HR termination date and the account-disable timestamp in the IdP logs. A gap measured in weeks, not hours, is the finding — not the existence of an offboarding checklist.

Evidence auditors typically request:

  • HRIS-to-IdP provisioning log or integration configuration, e.g. Workday or BambooHR into Okta or Google Workspace
  • Deprovisioning tickets showing the termination timestamp and the account-disable timestamp, demonstrating SLA
  • Contractor account list showing expiry dates tied to contract end dates
  • Service account/API key inventory with an owner, purpose, and last rotation date

Common gaps

  • Deprovisioning is manual and depends on someone filing a ticket, so terminated employees retain access for days or weeks
  • Contractor accounts have no expiry date and outlive the engagement
  • Service accounts and API keys have no named owner, so nobody notices when they should be rotated or revoked
  • Role changes add new access without removing what the old role no longer needs, accumulating permissions over time

Cross-Framework Mapping

FrameworkRequirementImplementation note
ISO 27001A.5.16This control
SOC 2CC6.2, CC6.3CC6.2 and CC6.3 test provisioning and deprovisioning directly — the same termination-ticket evidence answers both frameworks.
GDPRArticle 32Article 32 expects timely access removal as part of confidentiality; a slow deprovisioning SLA is a weak position under both ISO and GDPR, not just an ISO gap.

Primary sources

Frequently Asked Questions

The standard doesn't specify a number; your own policy does. Set an SLA you can actually meet and evidence adherence — 'we deprovision promptly' with no timestamps doesn't survive sampling.

A.5.15 sets the rules for who should have access; A.5.16 is the mechanics of creating, changing, and removing the identities that hold that access.

Yes. Every non-human identity should map to an accountable person or team responsible for its permissions, rotation, and eventual decommissioning.

Document it separately — customer-controlled SSO changes who manages deprovisioning for that tenant's users and should be reflected in your shared-responsibility notes.

Framework versions referenced in this page:

  • ISO/IEC 27001 — ISO/IEC 27001:2022

Last verified: July 2026 · Primary sources linked above