ISO 27001 A.5.16: Identity Management

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 5.16 requires the full life cycle of identities to be managed, so that every individual and system accessing your information can be uniquely identified, held accountable, and granted exactly the access they need, for exactly as long as they need it.

The Bottom Line: Authentication (5.17) proves who is logging in; access rights (5.18) decide what they can do. Identity management (5.16) is the foundation under both, it guarantees that "who" is a single, real, accountable identity and that the identity disappears the moment it is no longer needed. Without it, every other access control is built on sand.

What the Standard Actually Requires

The ISO 27001:2022 Text

Annex A 5.16 states:

ISO 27001:2022 Annex A 5.16 asks organizations to manage identities across their whole lifecycle, from creation through to removal.

Short control, enormous scope. "Full life cycle" means from the business request that justifies an identity, through verification, creation, day-to-day change, all the way to timely disablement and deletion.

What ISO 27002:2022 Adds

The implementation guidance (Clause 5.16) requires that the identity management process ensures:

• (a) One identity, one person. An identity assigned to a person is linked to a single person, so that person can be held accountable for actions performed with it.
• (b) Shared identities are the exception. Identities used by multiple people (shared/generic accounts) are permitted only where necessary for business/operational reasons, and only with dedicated approval and documentation.
• (c) Non-human identities are governed too. Identities for non-human entities (service accounts, machines, workloads, bots) are subject to segregated approval and independent ongoing oversight.
• (d) Timely removal. Identities are disabled or removed promptly when no longer required, e.g. the person has left, changed role, or the associated entity is decommissioned.
• (e) No duplicate identities. Within a given domain, a single identity maps to a single entity, duplicate identities for the same entity are avoided.
• (f) Records of identity events. Records of all significant events concerning the use and management of user identities (and their authentication information) are kept.

The standard also expects a supporting process for changes to identity information (which can include re-verification of trusted documents), and, where third-party identities are used (e.g. social-media or federated credentials), the organisation must ensure the third party provides the required trust level and that associated risks are treated (linking to A.5.19 supplier security and A.5.17 authentication information).

The "shall vs should" Analysis

What Auditors Actually Check

1. A single authoritative source of identity (usually HRMS) feeding your directory.
2. Joiner–Mover–Leaver evidence, sample 5–10 recent joiners/leavers and trace identity creation and disablement.
3. No unexplained shared/generic accounts, and a register with approval for the ones that exist.
4. Service/non-human accounts have named owners and review evidence.
5. Orphaned and dormant account reports, and proof they are actioned.
6. Identity event logs retained (creation, enable/disable, attribute change).

What the Standard Does NOT Require

A common source of over-engineering, and wasted budget, is misreading 5.16. The control does not:

• Mandate a specific IGA product. You can satisfy 5.16 with Google Workspace + a disciplined spreadsheet reconciliation if your size warrants it. Tooling is risk-proportionate.
• Require biometrics or Aadhaar. Identity proofing must be proportionate; biometrics are one option, not an obligation.
• Forbid all shared accounts absolutely. It requires that shared accounts be the justified, approved, documented exception, not that they never exist.
• Demand real-time deprovisioning. It demands timely deprovisioning against a risk-based SLA you define and meet.
• Cover only employees. It explicitly extends to contractors, partners, and non-human entities, a scope many organisations miss.

Knowing the boundary lets you pass the audit without gold-plating, and concentrate spend on the few high-risk identity classes (privileged, service, leaver).

The Identity Management Process Model

ISO 27002:2022 frames provisioning/revocation as a multi-step procedure, and modelling it explicitly is what auditors want to see:

Each transition is logged (27002 (f)), giving you a defensible, end-to-end audit trail for every identity in the estate.

Why Identity Management Matters

The Business Risk Narrative

Identity is now the primary security perimeter. As organisations move to cloud and remote work, there is no network edge left to defend, there is only who is asking and can we trust that identity. When identity management fails, the failure mode is invisible and slow: an ex-employee's account stays live for months, a shared "admin" login is used by twelve people with no accountability, a service account created for a 2021 project still has standing access in 2026. Each is a breach waiting to be triggered.

Credential and Identity Statistics

Indian Regulatory Context

Identity management is not just good practice in India, multiple regulators mandate unique identification and prohibit shared credentials:

• DPDP Act 2023: A Data Fiduciary must implement reasonable security safeguards (Section 8(5)) and be able to demonstrate who accessed personal data. Unique, accountable identities are the precondition for honouring data-principal rights, breach attribution, and the maximum penalty exposure for security failures.
• RBI Cyber Security Framework (2016) & Master Directions: Banks, NBFCs and regulated entities must ensure unique user IDs, prohibit generic/shared IDs for privileged actions, and enforce timely deactivation on role change/exit. RBI IT inspections specifically look for orphaned and dormant accounts.
• SEBI CSCRF (2024): Market infrastructure institutions and intermediaries must maintain identity governance, periodic access recertification, and de-provisioning controls.
• IRDAI Information & Cyber Security Guidelines: Insurers must implement identity lifecycle controls and remove access on separation.
• CERT-In Directions (2022): Accurate identity records and logs underpin the ability to investigate and report incidents within the 6-hour window.
• IT Act, 2000: Section 43A (prior to DPDP Act) and Section 66C (identity theft) reinforce the need to protect and uniquely attribute digital identities.

Regulator-by-regulator detail:

The throughline across every Indian regulator is the same as ISO 27002 5.16: unique, accountable identities; no unmanaged shared logins; prompt removal on exit. Implementing A.5.16 well satisfies the identity expectations of all of them at once.

Industry-Specific Consequences

impact of Non-Compliance

The overhead is rarely the certificate, it is the breach the missing control enabled. A single orphaned privileged account can be the entry point for a –50 crore ransomware event; a shared admin login can make a fraud impossible to pin on anyone, turning a recoverable incident into an unrecoverable one. Identity management is among the highest-use, lowest-overhead controls in the entire Annex.

Identity-First Security and Zero Trust

The architectural shift of the last decade is that identity has replaced the network as the control plane. In a Zero Trust model, which Indian regulators (RBI, MeitY guidance, NCIIPC) increasingly reference, every access decision is made per request based on the identity, its device, and context, with no implicit trust from network location. None of that works if the identity itself is untrustworthy. Zero Trust is therefore built on top of A.5.16: you cannot "never trust, always verify" if you cannot first guarantee that the thing you are verifying is a single, real, accountable identity. Practically, this means:

• Strong identity (5.16) → strong authentication (5.17, 8.5) → least-privilege authorisation (5.15, 5.18) → continuous verification (8.16).
• Just-in-time and just-enough access, so identities hold near-zero standing privilege.
• Continuous evaluation: a session can be revoked mid-stream if the identity's risk changes.

Organisations that get identity management right find that Zero Trust, conditional access, and privileged access management all become achievable; those that skip it find every advanced initiative collapses back onto a foundation of shared logins and orphaned accounts.

The Non-Human Identity Explosion

A decade ago "identity" meant "employees." Today, in any cloud-native estate, non-human identities outnumber humans many times over, service accounts, workload identities, Kubernetes service accounts, CI/CD pipeline tokens, API keys, RPA bots, and IoT/OT devices. Each is an identity that can authenticate and act, often with broad standing privilege and a static secret that never rotates. Attackers know this: compromised service accounts and leaked API keys are now among the most common cloud-breach root causes. ISO 27002:2022 anticipated this by explicitly bringing non-human entities into 5.16(c). For Indian SaaS companies and digital-first BFSI players, governing machine identity is no longer optional, it is frequently the single largest pool of ungoverned access in the organisation.

Anatomy of an Identity-Driven Breach

To make the risk concrete, here is the depressingly common pattern that an A.5.16 failure enables, step by step:

1. The gap: A developer leaves in March. Offboarding is manual and ticket-based; her GitHub and AWS identities are never disabled, an orphaned identity (failure of 27002 (d)).
2. The exposure: Her personal credentials were reused on a site that suffered a breach; the password appears in a credential-stuffing list.
3. The entry: In July, an attacker validates the credential against the still-active GitHub identity. There is no MFA because the account was "inactive" and never enrolled.
4. The escalation: The identity has standing access to a private repository containing a hardcoded AWS service-account key (failure of machine-identity governance, 27002 (c)).
5. The impact: The attacker uses the service-account key, which has broad, never-reviewed permissions, to access a production data store containing customer PII.
6. The aftermath: Because access was via a shared/orphaned identity with weak logging, attribution and scoping take weeks (failure of 27002 (f)). Under CERT-In rules the organisation owes a report within 6 hours of awareness; under the DPDP Act it faces penalty exposure up to for inadequate safeguards.

Every link in that chain is an A.5.16 control: timely disablement, no orphaned identities, governed machine identities with no standing secrets, and complete identity event records. Get 5.16 right and this entire scenario becomes impossible at step 1.

Scope and Applicability

What the Control Covers

• All identities that can access organisational information or processing facilities: employees, contractors, interns, partners, customers (where applicable), and non-human identities (service accounts, machine/workload identities, API clients, RPA bots, IoT/OT devices).
• The entire lifecycle: request → proofing/verification → creation → activation → modification (role/attribute change) → suspension → disablement → deletion/archival.
• The directories and identity providers that hold these identities and the processes that feed and reconcile them.

Who It Applies To

Every organisation, regardless of size. A 20-person startup on Google Workspace has identity management obligations just as a 20,000-person bank does, the controls scale, the principle does not.

Size-Based Applicability

A Worked Identity Inventory

When defining scope, enumerate every identity class, the ones organisations miss are almost always non-human or external. A representative inventory for a mid-sized Indian SaaS company:

Anything not on this list and yet present in a directory is, by definition, an orphan to investigate.

Statement of Applicability (SoA) Considerations

A.5.16 will almost always be applicable in your SoA. Two drafting tips that prevent audit pain: (1) explicitly state that scope includes non-human identities, a surprising number of nonconformities arise because the SoA implicitly read "users" as "humans"; (2) reference the related controls (5.15, 5.17, 5.18, 8.2) so the assessor sees the identity chain is coherently implemented rather than as disconnected fragments.

Key Definitions and Terminology

Relationship to Other Controls

The Identity Control Chain

These controls are not independent boxes to tick, they form a dependency chain, and 5.16 sits at its root:

1. A.5.15 Access control sets the policy, the rules and topic-specific policy that govern who may access what, and on what basis (need-to-know, least privilege).
2. A.5.16 Identity management establishes the subject, a unique, proofed, accountable identity for every entity those rules will apply to. Without it, the rules have nothing reliable to attach to.
3. A.5.17 Authentication information secures the proof, the credentials (passwords, MFA, certificates) by which an identity demonstrates it is who it claims.
4. A.5.18 Access rights performs the authorisation, provisioning, reviewing, modifying and revoking the specific entitlements each identity holds.
5. A.8.2 Privileged access rights adds extra restriction for the high-risk subset of identities.

Read top to bottom, the chain answers four questions in order: What are the rules? Who is asking? Can they prove it? What may they do? A weakness at the identity layer (step 2) silently undermines everything below it: perfect MFA on a shared account still yields no accountability; a flawless access-review on duplicate identities still leaves a bypass path. This is why auditors who find shared logins or orphaned accounts treat it as systemic, it casts doubt on the integrity of the entire access-control program, not just one control.

The Identity Lifecycle (Joiner–Mover–Leaver)

Figure · Process

The seven stages of an identity

The heart of A.5.16 is a controlled lifecycle. Every identity must move through defined, evidenced stages.

Joiner

1. Business justification, HR/manager raises a request; the identity must be justified before it is created (27002 "Other information": confirm the business requirement first).
2. Identity proofing, verify the person is who they claim (link to A.6.1 screening; in India, document + Aadhaar/PAN-based verification where lawful and consented).
3. Establish identity, create a unique identifier in the source of truth (HRMS), provisioned to the directory/IdP. Enforce a naming standard that guarantees uniqueness and avoids reuse of a former employee's ID.
4. Configure and activate, birthright/baseline access only; everything else via access-request (A.5.18).
5. Issue authentication information, per A.5.17 (secure distribution, forced first-login change, MFA enrolment).

Mover (role/attribute change)

• Trigger from HRMS on transfer/promotion.
• Re-evaluate all access; remove access no longer needed (prevent "privilege creep").
• Re-verify trusted documents where the change warrants it.
• Update attributes (department, manager, location) so downstream authorisation stays correct.

Leaver

• Trigger from HRMS on resignation/termination/contract end.
• Disable immediately on last working day (or earlier for involuntary exits), to a defined SLA (e.g. ≤4 hours for privileged, ≤24 hours for standard).
• Revoke sessions/tokens, disable (not just "hide") the account, reclaim devices and licences.
• Delete or archive after the retention period; never silently leave the identity active.
• Special handling for rehires (don't resurrect stale access) and role-to-contractor transitions.

Lifecycle Evidence (what to keep, 27002 (f))

Identity Types: Human, Non-Human, Shared and Third-Party

Human Identities

Employees, contractors, interns, partners. Each gets one identity, linked to one person, for accountability (27002 (a)). Contractors should be visually distinguishable (e.g. naming convention ext.firstname) and time-boxed with an automatic expiry that must be renewed.

Non-Human / Machine Identities (27002 (c))

The fastest-growing and least-governed identity class. Covers service accounts, application/workload identities, API clients, RPA bots, CI/CD pipelines, and OT/IoT devices.

Shared / Generic Identities (27002 (b))

Default position: avoid. Where genuinely necessary (e.g. a legacy plant HMI, an emergency break-glass account), they must be:

• Formally approved and entered in a shared-account register;
• Justified with a business/operational reason;
• Compensated with extra controls (vaulted credentials, session recording, individual attribution at the access layer).

Third-Party / Federated Identities (27002 "Other information")

When you accept identities issued elsewhere (social login, a partner's IdP, a customer SSO federation):

• Confirm the trust level is sufficient for the access granted;
• Treat the issuer as a supplier (A.5.19) and the credentials per A.5.17;
• Define what happens when the federation breaks or the partner offboards the user.

Machine Identity and Secrets, A Deeper Look

Because non-human identities are the largest and least-governed class, they deserve a dedicated operating model:

Inventory first. You cannot govern what you cannot see. Build a service-account/machine-identity inventory covering: identifier, type (service account, workload, API client, bot, device), owner, purpose, systems it can access, secret type and location, creation date, and last review. In cloud, enumerate IAM roles, managed identities, and key/secret stores; in CI/CD, enumerate pipeline tokens and deploy keys.

Secrets are the weak point. Most machine-identity breaches are really secret breaches, a hardcoded API key in a Git repo, a static service-account password in a config file. Controls:

• Vault all secrets (HashiCorp Vault, CyberArk Conjur, cloud KMS/Secrets Manager); never store in code or plaintext config.
• Rotate on a schedule and on compromise; prefer short-lived, dynamically-issued credentials over static ones.
• Scan repositories and pipelines for leaked secrets (e.g. pre-commit hooks, secret scanners).
• Prefer workload identity federation (OIDC-based, no long-lived secret) for cloud-to-cloud and CI/CD access.

Block interactive use. Service accounts must not be usable for interactive logon, must not have mailboxes, and should be constrained to the specific hosts/workloads that need them.

Lifecycle and ownership. Every machine identity has a named human owner accountable for it, segregated approval at creation (27002 (c)), quarterly necessity review, and, critically, decommissioning when the workload retires. Orphaned service accounts from retired projects are the single most common standing-risk in cloud estates.

Detailed Implementation Guidance

Establish a Single Source of Truth

Designate HRMS as the authoritative source for human identities (and a CMDB/cloud inventory for non-human ones). Every identity in the directory must trace back to a record in the source of truth; anything that doesn't is an orphan to be investigated. This single decision eliminates most identity findings.

Centralise into One Directory / IdP

Consolidate identities into a primary IdP (Microsoft Entra ID, Okta, Google Workspace) and federate the rest via SSO. Reducing the number of identity stores reduces duplicates (27002 (e)) and the attack surface.

Automate Provisioning and De-provisioning

• Connect HRMS → IdP so joiners/leavers are event-driven, not ticket-driven.
• Use SCIM to push/withdraw accounts in downstream SaaS automatically.
• Map birthright access by role/department so new joiners are productive on day one without over-provisioning.

Govern Non-Human Identities

Maintain a service-account inventory (owner, purpose, scope, secret location, last review). Block interactive logon, vault secrets, rotate on a schedule, and review quarterly. Adopt a machine-identity platform as scale demands.

Detect Duplicates, Orphans and Dormancy

Run scheduled identity reconciliation: directory vs HRMS. Flag duplicate identities (merge/retire), orphaned accounts (disable), and dormant accounts (e.g. no login in 60–90 days → review/disable). Make these reports a standing operational task, not an annual scramble.

Tier the Approach by Risk

Integrate Identity Threat Detection (ITDR)

At higher maturity, monitor the identity fabric itself: impossible-travel, MFA fatigue, dormant-account reactivation, mass attribute changes, and directory privilege escalation. Identity is now an attack surface, not just a control.

Identity Proofing in the Indian Context

Step 2 of the process model, verify the entity before allocating a logical identity, is where Indian organisations have powerful, locally-relevant options. Use them proportionately and lawfully (with consent, and mindful of UIDAI rules and the DPDP Act):

Key rule: identity proofing assurance should match the access the identity will hold. A vendor read-only account needs less than a core-banking administrator. Record the proofing evidence and link it to the identity (this is what closes the loop between A.6.1 screening and A.5.16).

Access Certification and Recertification

Creating identities correctly is half the job; proving over time that they should still exist and still hold their access is the other half. Run periodic certification campaigns:

• Who certifies: the identity's manager (existence/role) and the resource/data owner (access).
• Cadence (risk-based): Tier-0 privileged monthly; standard staff semi-annually; low-risk annually; service accounts quarterly.
• What good looks like: targeted, manageable campaigns (not 500-line spreadsheets that get rubber-stamped), with revocation actually executed and evidenced.
• Micro-certifications: trigger an ad-hoc review on a mover event or a privilege grant, rather than waiting for the next cycle.

Certification is the control that catches the identities that slipped past JML automation, the contractor who quietly became permanent, the analyst who moved teams but kept old access.

Federation, SSO and Customer Identity (CIAM)

• Workforce SSO/federation reduces the number of identities and credentials (fewer duplicates, smaller attack surface). Standards: SAML 2.0, OIDC, SCIM for provisioning.
• B2B federation: when partners bring their own IdP, treat that IdP as a supplier (A.5.19), agree the trust level, and define de-federation on offboarding.
• CIAM (customer identity): if you manage customer/data-principal identities, the same lifecycle principles apply, plus DPDP-specific duties, consent, data-principal rights (access/correction/erasure), and the ability to attribute access. Keep workforce and customer identity domains separated.

Identity Maturity Model (L1–L5)

Use this to baseline current state and set a target. Auditors and boards both respond well to a maturity narrative.

Most Indian SMEs pursuing certification should target L3 for the audit and plan a roadmap to L4; regulated BFSI entities are typically expected at L4.

Sector-Specific Implementation Notes (India)

BFSI (banks, NBFCs, fintech). RBI expects unique user IDs, no shared privileged logins, maker-checker with individual attribution, and timely deactivation on exit. Privileged identities must be PAM-brokered (ARCON, CyberArk and BeyondTrust are common). Expect IT inspections to pull leaver lists and orphaned-account reports directly. Service accounts in core-banking and payment-switch environments need the tightest governance. Target L4.

Healthcare / health-tech. Patient PII makes attribution non-negotiable for DPDP. Avoid generic "reception"/"ward" logins; where clinical workflow demands shared workstations, use fast user-switching with individual identities rather than a shared account. Machine identities integrating with hospital systems (HL7/FHIR interfaces) must be inventoried and owned.

IT/ITeS and SaaS. The dominant risk is contractor and multi-tenant sprawl, identities across dozens of client tenants and SaaS apps. SCIM automation and time-boxed contractor identities are essential; client SOC 2 and security questionnaires will specifically probe joiner/leaver evidence. Machine identity (CI/CD, cloud workloads) is usually the largest ungoverned pool.

Manufacturing / OT. Plant HMIs and legacy control systems often can't support individual logins; treat these as justified shared accounts in the register, with compensating controls (physical access control, session logging, network segregation per A.8.22). Don't let "OT is different" become "OT is ungoverned."

Government / CII. NCIIPC-regulated entities must demonstrate rigorous identity governance for privileged and administrative identities; orphaned privileged accounts are treated as serious findings.

Tools, Technologies, and Solutions

Identity Providers / Directories

Identity Governance & Administration (IGA)

Adjacent Tooling

• PAM (privileged identities): CyberArk, Delinea, BeyondTrust, ARCON (Indian-origin, widely used in Indian BFSI).
• Machine/secrets identity: HashiCorp Vault, CyberArk Conjur, Akeyless, Venafi (machine identity).
• ITDR: Microsoft Defender for Identity, CrowdStrike Identity, Semperis.

Tool selection rule: start with the IdP you already pay for, add SCIM automation, then layer IGA only when manual certification stops scaling. Tools don't fix process, a single source of truth and a disciplined JML do.

Detailed Comparison Matrix

For most Indian SMEs the pragmatic path is Entra ID or Google Cloud Identity for the directory + SSO, SCIM to the top apps, and native governance (Entra ID Governance / Okta OIG) before investing in a standalone IGA suite. Standalone IGA (SailPoint/Saviynt) is justified at L4 maturity, large user counts, or heavy SoD/regulatory certification demands (typical in BFSI).

Identity Standards and Protocols You Should Know

Identity management runs on a small set of open standards. Knowing what each does prevents architecture mistakes and helps you ask vendors the right questions:

A practical rule: prefer OIDC + SCIM for new integrations (modern, automatable), reserve SAML for apps that only support it, and push toward workload identity federation to eliminate static machine secrets. Mismatched protocols, e.g. SSO without SCIM, are a classic cause of the "logged out but still provisioned" gap, where an identity is blocked from logging in centrally yet retains a standing local account in a downstream app.

Identity Management Policy Template

Below is an extract you can adapt (full version in the toolkit).

Identity Management Policy — Acme Technologies Pvt Ltd
ISO 27001:2022 Annex A 5.16

1. Purpose
   To ensure every entity accessing Acme's information and systems is uniquely
   identified and accountable, and that identities are managed across their full
   lifecycle.

2. Scope
   All human and non-human identities in all environments (on-prem, cloud, SaaS, OT).

3. Policy Statements
   3.1 Each person shall be assigned a single, unique identity. Sharing of personal
       credentials is prohibited.
   3.2 Shared or generic identities are prohibited unless formally approved, justified,
       recorded in the Shared Account Register, and compensated with additional controls.
   3.3 Non-human identities shall have a named owner, segregated approval, and quarterly
       review. Interactive logon for service accounts is prohibited.
   3.4 Identities shall be created only on confirmed business need and after identity
       proofing consistent with A.6.1 screening.
   3.5 HRMS is the authoritative source of truth for human identities. Any directory
       identity without a source-of-truth record shall be investigated and disabled.
   3.6 Identities shall be disabled within defined SLAs on termination or role change
       (privileged ≤4h; standard ≤24h) and deleted/archived per the retention schedule.
   3.7 Duplicate identities for the same entity within a domain are prohibited.
   3.8 Records of all significant identity events shall be retained for [3–7] years.

4. Roles and Responsibilities
   IAM Lead (owner), HR (triggers), Application owners (downstream provisioning),
   CISO (governance), Internal Audit (assurance).

5. Review
   Reviewed annually or on significant change.

Joiner–Mover–Leaver Procedure (extract)

JML Procedure — Acme Technologies Pvt Ltd (A.5.16)

JOINER
  J1. HR creates employee record in HRMS (source of truth) with start date, role,
      department, manager, employment type (permanent/contractor + end date).
  J2. Identity proofing completed and evidenced (see A.6.1); assurance level set by role.
  J3. HRMS event provisions a UNIQUE identity to Entra ID (naming standard: first.last,
      collisions resolved with middle initial/number; ext.first.last for contractors).
  J4. Birthright access applied by role; additional access via access request (A.5.18).
  J5. Authentication information issued securely; MFA enrolled at first logon (A.5.17).
  J6. Manager confirms access on day 5; exceptions logged.

MOVER
  M1. HRMS transfer/promotion event triggers access re-evaluation.
  M2. Access not required in the new role is removed (no privilege accumulation).
  M3. Attributes (dept, manager, location) updated; downstream entitlements recalculated.
  M4. Micro-certification sent to new manager and affected resource owners.

LEAVER
  L1. HRMS exit event (resignation/termination/contract end) triggers disablement.
  L2. SLA: privileged identities disabled <=4h; standard <=24h of effective exit
      (immediate for involuntary terminations).
  L3. Sessions/tokens revoked; account disabled (not hidden); devices/licences reclaimed.
  L4. Mailbox/data handled per retention; manager notified of completion.
  L5. Identity deleted/archived after retention period; rehires get a fresh identity.

EXCEPTIONS & SHARED ACCOUNTS
  X1. Any shared/generic or non-human identity routed to segregated approval and the
      Shared/Service Account Register before creation.

Identity Request Form (fields)

Identity Request Form
- Requestor / Manager:
- Entity type: [Employee | Contractor | Partner | Service account | Workload | Bot | Device]
- Business justification:
- Role / department / location:
- Employment/engagement end date (if non-permanent):
- Proofing evidence reference (links to A.6.1):
- Birthright access profile requested:
- For non-human: named owner, systems accessed, secret type/location, review cadence:
- Approver (segregated for shared/non-human):
- Decision / date:

Shared / Service Account Register (columns)

Identifier | Type | Owner | Business reason | Systems accessed | Secret location |
Compensating controls | Approved by | Last review | Next review | Decommission trigger

Maintaining these two artefacts, a request form that captures justification and proofing, and a living register for the exception accounts, is, in practice, what turns "we manage identities" from an assertion into evidence an auditor can test.

Risk Assessment and Treatment

Treatment Strategy

Sequence treatment by risk × ease, not alphabetically. The highest-risk, fastest-to-fix items are orphaned privileged accounts and standing service-account secrets, treat these first. Shared logins are higher-effort (they need process change and sometimes application rework) but high-value, so schedule them second. Duplicate-identity and dormancy issues are continuous-improvement items handled by recurring reconciliation rather than one-off projects.

For each risk, choose an explicit treatment option and record it in the risk register: modify (e.g. automate disablement), retain with justification (e.g. a documented break-glass account with compensating controls), avoid (e.g. prohibit interactive service-account logon outright), or share (e.g. push identity assurance onto a federated partner under A.5.19). The residual risk after treatment must be accepted by the risk owner, typically the CISO for identity risks, with privileged-identity residuals escalated to the ISMS steering committee.

Audit and Compliance Checklist

(The toolkit 04-audit-evidence-checklist.md maps each question to the exact ISO 27002:2022 5.16 guidance clause and a sample evidence artefact.)

Metrics and KPIs

Building the Identity Dashboard

Metrics only drive behaviour when someone sees them on a cadence. Build a one-page identity dashboard, reviewed monthly by the IAM Lead and quarterly by the ISMS steering committee, with three bands:

• Red (act now): orphaned accounts > 0, any leaver missed SLA, any unowned privileged/service account, any hardcoded secret found.
• Amber (watch): dormant accounts trending up, JML automation rate below target, certification campaign slipping.
• Green (assure): unique-identity coverage 100%, deprovisioning within SLA, all service accounts reviewed in-quarter.

Trend the numbers over time, auditors and boards both value a downward orphan/dormant trend and an upward automation rate far more than a single point-in-time snapshot. Where your IGA/IdP supports it, automate the data feed so the dashboard reflects live state rather than a manually-curated export (which itself becomes a finding if it diverges from reality).

Common Pitfalls and Audit Failures

What Auditors Actually Probe

A.5.16 is one of the controls where auditors go beyond documents and ask for live evidence. Be ready for this kind of exchange:

• "Show me your last five leavers from the HR system. Now show me those accounts in the directory.", They are checking your disablement SLA against real exits. A single still-active ex-employee account is a finding.
• "Pick a random privileged account. Who owns it? When was it last reviewed?", Tests ownership and certification of the high-risk subset.
• "List your shared and service accounts. Where's the approval and the register?", Tests 27002 (b) and (c).
• "Run your orphaned-account report in front of me.", Tests whether reconciliation is real and routine, not a screenshot made for the audit.
• "This person moved from Finance to Sales last quarter, show me their access changed.", Tests mover handling and privilege creep.

The organisations that sail through are not the ones with the thickest policy; they are the ones whose operational reports (orphan, dormant, leaver-SLA, service-account review) are run on a schedule and produce clean, owned, actioned output.

The First 30 Days: Quick Wins

If you are starting from a low base, this sequence delivers visible risk reduction fast and builds the audit evidence trail:

1. Day 1–3: Export all accounts from every directory; reconcile against the HR system. Disable every account with no matching active person (orphans). This alone clears the most common finding.
2. Day 4–7: Produce a dormant-account report (no logon 90+ days); review and disable.
3. Day 8–14: Enumerate shared/generic and service accounts; assign an owner to each; start the register.
4. Day 15–21: Document the JML process and the disablement SLA; wire HR exit → directory disablement (even a daily batch beats manual).
5. Day 22–30: Define the naming/uniqueness standard; run a duplicate-identity check; set the recurring schedule for all the above reports.

By day 30 you have eliminated orphans, owned every shared/service account, and stood up the recurring controls, enough to satisfy an auditor that the lifecycle is genuinely managed.

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1, Indian IT Services Company (Pune, 1,800 staff): JML Automation

Challenge. A fast-growing IT services firm onboarded/offboarded 60–80 people a month across Microsoft 365, Jira, GitHub, AWS and 30+ client SaaS tenants. Offboarding was manual and ticket-based. An ISO 27001 surveillance audit found 23 active accounts belonging to ex-employees, two with privileged GitHub access, a major nonconformity and a red flag for several client SOC 2 attestations.

Solution (Singahi-guided, 8 weeks).

1. Declared HRMS (Darwinbox) the source of truth; integrated to Entra ID.
2. Built event-driven leaver automation: exit in HRMS → disable identity, revoke sessions, reclaim licences within 4 hours.
3. Deployed SCIM provisioning to the top 12 SaaS apps; mapped birthright access by role.
4. Stood up a weekly orphan/dormant reconciliation report owned by the IAM Lead.
5. Built a service-account inventory with owners and quarterly review.

Results. Ex-employee active accounts went from 23 → 0; mean time to deprovision dropped from ~9 days to under 4 hours; the nonconformity was closed and two at-risk client contracts were retained. Onboarding time-to-productivity also improved because birthright access was now automatic.

Illustrative Scenario 2, Indian Private-Sector Bank (5,200 staff): Eliminating Shared & Orphaned Privileged Identities

Challenge. An RBI IT inspection flagged shared maker/checker logins in a branch application, generic database admin accounts used by the DBA team, and orphaned privileged identities in the core banking environment, each an RBI Cyber Security Framework violation and a fraud-attribution risk.

Solution (Singahi-guided, 14 weeks).

1. Mapped every privileged identity to a named owner; retired generic DBA logins in favour of individual identities brokered through ARCON PAM with session recording.
2. Converted shared branch logins to individual identities with attribution at the application layer; retained one break-glass account, vaulted and alarmed.
3. Ran identity reconciliation against the HRMS to find and disable 41 orphaned privileged accounts.
4. Instituted monthly certification for Tier-0/Tier-1 identities and a service-account governance standard.

Results. Shared privileged logins eliminated; every privileged action now attributable to an individual; orphaned privileged accounts reduced to 0; the RBI observations were closed at follow-up, and the bank passed its ISO 27001 recertification with no identity findings.

Illustrative Scenario 3, Indian Health-Tech SaaS Startup (Bengaluru, 220 staff): Machine Identity & DPDP Readiness

Challenge. A health-tech SaaS startup processing patient PII for hospital clients was preparing simultaneously for ISO 27001 certification and DPDP Act readiness. A pre-audit found the human-identity side was reasonable (Google Workspace + decent offboarding) but the machine-identity side was wild: 140+ service accounts and API keys across AWS, dozens of static keys hardcoded in repositories, a shared "deploy" account used by the whole engineering team, and no inventory of any of it. For a company whose customers' patients' data was at stake, this was both an audit blocker and a DPDP liability.

Solution (Singahi-guided, 9 weeks).

1. Built a machine-identity inventory across AWS, GitHub and CI/CD; assigned a named owner to every entry.
2. Migrated static AWS keys to IAM roles / workload identity federation; moved remaining secrets to AWS Secrets Manager with rotation; added secret scanning in pre-commit and CI.
3. Replaced the shared "deploy" account with per-engineer identities and an OIDC-based pipeline identity (no standing secret).
4. Implemented quarterly service-account certification and a decommissioning step tied to project retirement.
5. Mapped the whole identity model to DPDP Section 8(5) safeguards so access to patient PII became fully attributable.

Results. Hardcoded secrets eliminated; standing static keys reduced by ~85%; every access to patient data attributable to a unique identity; ISO 27001 certification achieved first attempt, and the identity evidence pack doubled as the DPDP security-safeguards demonstration for hospital-client due diligence.

Multi-Framework Mapping

Implementation Roadmap

Phase 1, Foundation (Weeks 1–3)

• Designate HRMS as source of truth; inventory all directories and identities.
• Run first orphan/dormant/duplicate reconciliation; disable obvious orphans (quick win).
• Draft and approve the Identity Management Policy.

Phase 2, Centralise & Automate (Weeks 4–7)

• Consolidate to a primary IdP; enable SSO/federation.
• Integrate HRMS→IdP for event-driven JML; configure SCIM to top apps.
• Define naming standard and birthright access by role.

Phase 3, Govern Non-Human & Privileged (Weeks 8–10)

• Build service-account inventory with owners; block interactive logon; vault secrets.
• Bring Tier-0/Tier-1 identities under PAM; start monthly certification.

Phase 4, Assure & Mature (Weeks 11–12+)

• Stand up access-certification campaigns and dashboards (the KPIs above).
• Add ITDR monitoring; schedule recurring reconciliation.
• Internal audit dry-run against the Section 13 checklist.

Detailed 90-Day Plan

RACI Snapshot

(R = Responsible, A = Accountable, C = Consulted, I = Informed.)

Sustaining the Control (Continuous Improvement)

Certification is a point in time; identity drifts continuously as people join, move and leave and as engineers spin up new workloads. To keep A.5.16 healthy between audits:

• Operationalise the reports. Orphan, dormant, leaver-SLA and service-account-review reports must run on a schedule with a named owner, not be recreated for each audit. Drift is caught weekly, not annually.
• Tie identity into change. New systems, cloud accounts and integrations must register their identities (especially non-human) at creation, via your change process (A.8.32) and project management (A.5.8).
• Review after every incident. Feed identity-related incidents back into the process (link A.5.27 learning from incidents), most reveal a JML or machine-identity gap.
• Re-baseline maturity annually. Re-run the L1–L5 assessment each year and advance one level; pair each ISMS management review (Clause 9.3) with the identity dashboard.
• Watch the joiners of automation. As you automate JML, periodically test that the automation still works (a broken HR→IdP connector silently re-creates the manual gap you closed).

Organisations that treat identity as a running service rather than a project are the ones that pass surveillance audits effortlessly and never appear in a breach post-mortem for an orphaned account.

FAQ

Q1: Is A.5.16 mandatory for certification? Yes. Like all Annex A controls it is assessed against your Statement of Applicability. Identity management is applicable to essentially every organisation; declaring it "not applicable" is almost never defensible.

Q2: What's the difference between A.5.16, A.5.17 and A.5.18? 5.16 manages the identity (who/what exists and is it unique and accountable). 5.17 secures the authentication information (the credentials proving the identity). 5.18 manages access rights (what the identity may do). They are a chain: identity → authentication → authorisation.

Q3: Are shared accounts ever allowed? Only as a justified, approved, documented exception with compensating controls (vaulting, session recording, individual attribution). They are never the default.

Q4: Do service accounts and bots really count as "identities"? Yes, 27002 5.16(c) explicitly covers non-human entities. In cloud estates they often outnumber humans many times over and are the biggest source of standing risk.

Q5: What is the single highest-impact quick win? Run an orphaned/dormant account reconciliation against HRMS and disable everything with no owner. It is fast, cheap, and removes the most common audit finding.

Q6: How does identity management support DPDP Act compliance? You cannot honour data-principal rights, attribute access to personal data, or investigate a breach within CERT-In's 6-hour window unless every access maps to a unique, accountable identity.

Q7: How often should we certify identities and access? Risk-based: Tier-0 privileged monthly, standard staff semi-annually, low-risk annually.

Q8: We're a 30-person startup. Do we really need IGA tooling? No. At your size, Google Workspace or Microsoft 365 as a single directory, an HR-triggered JML checklist, SCIM to your top few apps, and a quarterly orphan/dormant reconciliation fully satisfy A.5.16. Buy IGA tooling when manual certification stops scaling (typically a few hundred users), not before.

Q9: How is "identity management" different from our existing "user access review"? Access reviews (recertification) are one part of 5.16 (Section 9.9), focused on whether access is still appropriate. 5.16 is broader: it also covers unique identification, proofing, the JML lifecycle, non-human and shared identities, duplicate prevention, and event logging. A good access review on top of poor identity hygiene still fails the control.

Q10: Can we use Aadhaar for employee identity proofing? You can, but proportionately and lawfully. Prefer offline/QR or masked Aadhaar, obtain consent, handle it per UIDAI rules and the DPDP Act, and never store the full Aadhaar number unless you have a clear legal basis and need. For most roles, PAN/passport/driving-licence verification plus employment checks is sufficient; reserve stronger proofing for high-assurance roles.

Q11: What do we do about service accounts we're afraid to touch? That fear is itself the finding. Start by inventorying and assigning an owner to each; then, in a test window, monitor usage to learn dependencies before rotating secrets or constraining the account. Never leave an "untouchable" account ungoverned, those are exactly the ones attackers target.

Q12: How does 5.16 interact with privileged access (A.8.2)? Privileged identities are a high-risk subset of the identities 5.16 governs. 5.16 ensures they are unique, owned, and lifecycle-managed; A.8.2 adds the extra restrictions (PAM, just-in-time, session recording). You implement 5.16 for all identities and layer A.8.2 controls on the privileged ones.

Q13: Auditors keep asking about "accountability." What exactly do they mean? Accountability means any action in your systems can be traced to a single, named, real entity. Shared logins, generic accounts, and duplicate identities all destroy accountability because the logs can no longer answer "who did this?" Restoring accountability, one identity, one entity, fully logged, is the core purpose of A.5.16(a) and (f).

Q14: Do guest/external collaborator identities (e.g. Entra B2B guests) count? Yes. Guest identities are real identities with access to your resources and must be lifecycle-managed: justified, time-boxed, reviewed, and removed when the collaboration ends. Stale guest accounts are a frequent and easily-missed finding.

Key Takeaways

• A.5.16 is the root of the access-control chain. Identity (5.16) → authentication (5.17) → access rights (5.18) → privileged restriction (8.2). A weak identity layer undermines every control above it.
• The control is one sentence with enormous scope: manage the full life cycle of every identity, human and non-human, uniquely and accountably.
• The six ISO 27002 requirements are your spec: one-identity-per-person accountability (a), justified/approved shared accounts (b), governed non-human identities (c), timely disablement (d), no duplicates (e), and retained identity event records (f).
• A single source of truth (HRMS) + event-driven JML eliminates the most common findings (orphaned and ex-employee accounts) almost by construction.
• Non-human/machine identities are the biggest ungoverned risk in modern cloud estates, inventory them, own them, vault and rotate their secrets, decommission them.
• In India, A.5.16 satisfies the identity expectations of RBI, SEBI, IRDAI, CERT-In, NCIIPC and the DPDP Act simultaneously, unique, accountable identities and prompt removal on exit.
• Quick win: reconcile directories against HR this week and disable every owner-less account.

References and Further Reading

Primary standards

• ISO/IEC 27001:2022, Annex A control 5.16 (normative control statement).
• ISO/IEC 27002:2022, Clause 5.16, Identity management (purpose + guidance (a)–(f) and the multi-step provisioning model used throughout this guide).
• ISO/IEC 24760 (series), A framework for identity management (formal identity model and lifecycle terminology).

Supporting frameworks

• NIST SP 800-53 Rev 5, IA-2, IA-4, IA-5, IA-8, AC-2 (identification, identifier and account management).
• NIST SP 800-63A, Digital Identity Guidelines: Enrollment & Identity Proofing (assurance levels for joiner proofing).
• NIST CSF 2.0, PR.AA (Identity Management, Authentication and Access Control).
• CIS Controls v8, Control 5 (Account Management) and Control 6 (Access Control Management).
• PCI DSS v4.0, Requirement 8 (unique identification and account lifecycle).
• SOC 2 (TSC 2017), CC6.1–CC6.3 (registration, authorisation, and removal of identities).
• COBIT 2019, DSS05.04 (manage user identity and logical access).

Indian regulations

• Digital Personal Data Protection Act, 2023, security safeguards (Sec 8(5)); penalty schedule.
• RBI, Cyber Security Framework in Banks (2016); Master Direction on IT Governance, Risk, Controls and Assurance Practices.
• SEBI, Cybersecurity and Cyber Resilience Framework (CSCRF), 2024.
• IRDAI, Information and Cyber Security Guidelines.
• CERT-In, Directions under Section 70B of the IT Act, 2000 (April 2022).
• IT Act, 2000, Sections 43A, 66C, 70B.

Singahi resources: the A.5.16 toolkit (policy, JML procedure, registers, audit-evidence checklist, dashboards) and related guides for A.5.15 Access control, A.5.17 Authentication information, A.5.18 Access rights, and A.8.2 Privileged access rights.