ISO 27001 Identity and Access Management (Annex A 5.16)

Introduction

Identity and Access Management (IAM) is the control layer that decides who can access which systems and data, and under what conditions. In your Comply Agent configuration, this is captured by the control “Identity Management” under the Identity and Access Management category and User Access Management subcategory. The control description focuses on implementing and managing the full lifecycle of digital identities - provisioning, modification, deprovisioning and regular reviews-to keep access rights aligned with current roles and responsibilities.

The objective in the Basic Information panel is clear: to ensure appropriate and authorised access to systems and data throughout the entire identity lifecycle. That scope explicitly covers human users (employees, contractors, partners) as well as non‑human identities such as service accounts, APIs and bots. By anchoring the control in Annex A 5.16, you show auditors that IAM is treated as a structured, policy‑driven discipline rather than ad‑hoc account management.

Implementation & Guidance

The Implementation & Guidance section in below image provides a concise but powerful mandate:

"Implement automated identity provisioning and deprovisioning workflows integrated with HR systems. Regularly review and reconcile access rights against current roles and responsibilities, addressing discrepancies promptly."

For an ISO 27001 Annex A 5.16 implementation, this translates into a set of concrete processes.

1. Joiner–Mover–Leaver (JML) workflows

Identity lifecycle starts with the joiner event. As soon as HR creates or updates a record, your IAM or IdP (for example, Active Directory, Azure AD or Okta) should automatically:

• Create a unique user identity with a corporate identifier.
• Assign base access based on role, department and location.
• Trigger approvals for any elevated or sensitive access.

For movers (role changes, department transfers), the workflow should adjust permissions automatically-revoking old access and adding new access according to updated roles. For leavers, HR termination events must immediately disable or delete accounts, including VPN, privileged accounts and key SaaS applications.

Comply Agent’s guidance explicitly references this automation and HR integration, and the image of this panel illustrates the emphasis on workflow‑driven identity management.

2. Role‑based access and least privilege

Identity management under A.5.16 should rely on role‑based access control (RBAC) wherever possible. Roles such as “HR Analyst”, “Finance Controller” or “Service Desk Agent” are mapped to standard permission sets in your systems. Users are assigned to roles, not to individual privileges, which makes it much easier to maintain least privilege and to review access centrally.

Regular reconciliation of access rights “against current roles and responsibilities”, as stated in your guidance text, is critical. This can be automated via scheduled jobs that compare HR data, IdP group membership and application roles, highlighting mismatches for the IAM team to correct.

3. Evidence examples

Your Implementation & Guidance section lists three key evidence examples:

• Access request and approval logs – Records of who requested access, what was requested and who approved it.
• User access review reports and attestations – Periodic certification that existing access is still justified.
• Deprovisioning tickets and completion confirmations – Proof that access was removed promptly when people left or changed roles.

These map directly to ISO 27001 expectations for identity management and user accountability. In the article, you can place the Implementation & Guidance to show readers how Comply Agent organises both guidance and evidence examples in the same view.

Operational Details

The Operational Details panel in the image shows:

• Frequency: Quarterly
• Review Cycle: Quarterly
• Owner Role: IT Manager
• Responsible Role: IT Manager
• Automation Score: 75%
• Last Updated: March 18, 2026

This configuration is a strong example of how to operationalise Annex A 5.16.

Quarterly execution ensures that JML processes are regularly tested and that any gaps in provisioning or deprovisioning are caught before they turn into audit findings or incidents. A quarterly review cycle also aligns with typical internal audit and risk committee rhythms.

The IT Manager as both owner and responsible role signals clear accountability for IAM tooling, integration with HR and the day‑to‑day operation of identity workflows. For larger organisations, you might keep IT as responsible but set the CISO or Head of Security as the control owner; Image shows a pragmatic setup that many mid‑size companies will recognise.

The automation score of 75% is particularly noteworthy. It implies that most identity events-especially provisioning, modification and deprovisioning-are driven through automated processes and connectors rather than manual ticket management. In practice, this might mean:

• HRIS integration that feeds joiner/mover/leaver events into the IAM platform.
• Automated group assignment and removal based on role changes.
• Scheduled scripts or tools that disable and later delete accounts.
• Automatic collection of logs and approvals into a central evidence store (Comply Agent).

Highlighting this operational detail in the blog will show readers that identity management is treated as a living control, not just a policy document.

Compliance & Risk Management

In the Compliance & Risk Management panel, your control is classified as:

• Control Type: Administrative
• Risk Domain: Access Control
• Maturity Level: 4
• Compliance Status: N/A
• Clause Reference: ISO 27001:2022 A.5.16

Treating identity management as an Administrative control reflects the reality that IAM is as much about governance and process design as it is about technology. Policies, procedures and role definitions are just as important as IdP and SSO implementations.

The Access Control risk domain ties A.5.16 to related controls like A.5.18 (Access rights), A.5.15 (Access control) and any system‑specific technical controls. In your article, you can explain that effective identity management reduces risks such as:

• Unauthorised access through orphaned or stale accounts.
• Privilege creep when users collect access over time.
• Untraceable activity due to shared or generic accounts.

Maturity Level 4 signals to auditors that the organisation has moved beyond ad‑hoc practices. At this level, you typically see:

• Documented and approved identity lifecycle procedures.
• Integrated IAM tooling and HR systems.
• Regular metrics (e.g. time to deprovision, number of orphan accounts, results of access reviews).
• Continuous improvement based on incidents or audit findings.

Your Compliance & Risk Management image will visually reinforce this maturity story.

Framework Mappings

Your Framework Mappings panel shows that a strong identity lifecycle process supports numerous frameworks, not just ISO 27001:

• ISO 27001: A.5.16 Identity management (exact) – confirms that the control directly implements the Annex A requirement.
• SOC 2: CC6.2 (partial) – relates to user provisioning, modification and termination for the Security, Availability and Confidentiality criteria.
• GDPR: Article 32 (partial) – requires appropriate technical and organisational measures to ensure a level of security appropriate to risk, including access control and user authentication.
• NIST SP 800‑53 / NIST family: AC‑2 (related) – covers account management functions like creating, disabling and reviewing accounts.
• ISO 27001 enriched: A.5.1, A.5.10, A.5.12, A.6.3 – links identity management to information security policies, access control, privileged access management and segregation of duties.
• NIST CSF enriched: PR.AC‑1, PR.AC‑4, PR.AC‑6 – cover identity management, access enforcement and least‑privilege principles.

Evidence Library

The Evidence Library imge above for this control lists three key evidence types:

1. Access Logs (auto‑collect) – Logs from identity management systems (e.g. AD, Azure AD, Okta) that record provisioning, deprovisioning and access changes. Auto‑collection means Comply Agent can ingest and associate these logs with the control automatically.
2. Procedure Document – Formal documentation of identity lifecycle management procedures. This typically includes JML workflows, approval matrices, role definitions, exception handling and escalation paths.
3. Audit Trails (auto‑collect) – Records from SIEM or IAM audit logs that show who performed which identity‑related actions, and when. These support investigations, internal audit and external certification audits.

In the article, explain that these three evidence types together provide a complete picture:

• Design evidence (Procedure Document) shows how the control is supposed to work.
• Operating evidence (Access Logs, Audit Trails) shows that it is actually working over time.

Because two of the three are marked auto‑collect, you can emphasise how Comply Agent reduces manual evidence gathering, a key pain point for most ISO 27001 projects.

FAQs for “ISO 27001 Identity and Access Management (A.5.16)”

1. Is identity management (A.5.16) mandatory for ISO 27001 certification?

Yes. Identity management is an Annex A organisational control and is normally marked “applicable” in the Statement of Applicability whenever user or system accounts exist. You must show defined processes and evidence that identities are created, reviewed and revoked in a controlled way.

2. How often should identities and access rights be reviewed?

ISO 27001 does not prescribe a fixed interval, but most organisations perform quarterly reviews for high‑risk and privileged accounts and at least annual reviews for standard users. Your Comply Agent setup using a quarterly review cycle is fully aligned with good practice.

3. What is the difference between A.5.16 Identity Management and A.5.18 Access Rights?

A.5.16 focuses on the lifecycle of identities (joiner, mover, leaver), ensuring each user or service has a unique, well‑managed identity. A.5.18 focuses on the specific access rights those identities receive, including approvals, reviews and removals in line with access control policy.

4. Which systems usually integrate into an ISO 27001‑compliant IAM process?

Typical integrations include HR or ERP systems for joiner–mover–leaver events, identity providers like Active Directory or Okta for account management, ticketing tools for approvals, and SIEM platforms for collecting identity‑related audit logs.

5. What evidence do auditors look for to verify Annex A 5.16?

Auditors expect a documented identity lifecycle procedure, access and approval logs from your IdP or IAM tool, deprovisioning records for leavers, and audit trails or reports showing that access reviews and reconciliations actually occurred.

6. Can automation replace manual checks in identity management?

Automation should handle routine provisioning, deprovisioning and synchronisation, but human checks remain essential for high‑risk access and periodic certifications. A setup like Comply Agent’s, with around 75% automation plus quarterly manual reviews, is generally ideal for ISO 27001