IAM-003 User Account Lifecycle Management
Description
Formal processes exist for provisioning, modifying and deprovisioning user accounts. Access is granted only on documented approval. Accounts are disabled or removed promptly when a user changes role or leaves the organisation. Access changes are logged. Workforce accounts, service identities and the devices that authenticate to production are managed through a central identity provider or authorisation server that is the authoritative source for authentication and authorisation decisions, and any identity held outside it is a recorded exception with a named owner and a review date. Where an account carries usage conditions, such as permitted hours, permitted days or permitted source networks, those conditions are set on the account in that identity provider rather than stated only in the access request.
Rationale
Orphaned and over-provisioned accounts are a leading source of unauthorised access, and a controlled lifecycle keeps access tracking employment and role changes. An account created directly on a system stays invisible to the joiner and leaver process unless it is a recorded exception. Naming one identity provider as authoritative is how the lifecycle becomes enforceable. The lifecycle of non-human identities themselves is IAM-010's, and the credential rules are IAM-009's; IAM-003 states only where identities live and how they are approved. Usage conditions belong on the account because a condition written into a ticket cannot deny a login.
Applicability (9 profiles)
New row, from item 13 of the section 2 list in docs/s7-hipaa-proposals.md. 164.308(a)(3)(ii)(A) offers supervision as an alternative to authorisation and reaches workforce members who work in locations where the data might be accessed without holding a grant of their own. IAM-003 states the authorisation limb and holds the row as a partial for that reason. The supervision limb is stated nowhere: no canonical control treats supervision as a substitute for a grant, and INF-018 bounds who can be in a location without saying who watches them there. The specification is addressable, so a business associate that relies on authorisation alone owes a determination under 164.306(d)(3), which is the GOV-013 register as extended in migration 056.
Framework Mappings (21)
| IAM-06 | Access Provisioning | full |
| IAM-07 | Access Changes and Revocation | full |
| IAM-06 | Access Provisioning | full |
| IAM-07 | Access Changes and Revocation | full |
| HIPAA-164.308.a.3.i | Workforce Security | informative |
| HIPAA-164.308.a.3.ii.A | Authorization and/or Supervision | partial |
| HIPAA-164.308.a.3.ii.C | Termination Procedures | full |
| HIPAA-164.308.a.4.ii.B | Access Authorization | full |
| HIPAA-164.308.a.4.ii.C | Access Establishment and Modification | full |
| 5.18 | Access rights | full |
| NIS2-CIR-11.2 | Management of Access Rights | partial |
| NIS2-CIR-11.5 | Identification | informative |
| AC-2 | Account Management | full |
| AC-2(1) | Account Management | Automated System Account Management | partial |
| AC-2(11) | Account Management | Usage Conditions | full |
| AC-2(2) | Account Management | Automated Temporary and Emergency Account Management | partial |
| AC-2(3) | Account Management | Disable Accounts | partial |
| AC-2(4) | Account Management | Automated Audit Actions | full |
| IA-12 | Identity Proofing | partial |
| IA-13 | Identity Providers and Authorization Servers | full |
| CC6.2 | Prior to Issuing System Credentials and Granting System Access | full |
Evidence (3)
Access provisioning and deprovisioning request records showing approval workflows for account creation, modification, and removal.
Example: ServiceNow, Jira, or IT ticketing system export of access request tickets for the past 90 days, each showing the requester, approver, approval timestamp, and action taken.
Test: Request a sample of 10 to 15 recent access provisioning and deprovisioning tickets, including at least 3 offboarding cases. Verify for each: (1) an approval was recorded before access was granted or removed, (2) the approver is a named individual distinct from the requester, (3) for offboarding cases the account was disabled or removed within the SLA the policy defines, (4) where the request states a usage condition such as permitted hours or permitted source networks, that condition is set on the account in the identity provider and not only in the ticket.
Identity provider or directory audit logs showing account creation, modification, and deletion events tied to approved request records.
Example: Okta System Log, Azure AD Audit Log, or AWS CloudTrail export filtered for user lifecycle events (CreateUser, DeleteUser, UpdateUser) for the past 90 days, including actor, timestamp, and target account.
Test: Query the IdP audit log API for lifecycle events over the past 90 days. Cross-reference a sample of 10 events against the corresponding access request tickets. Verify: (1) no account was created or deleted without a matching approved ticket, (2) log entries include actor, target, and timestamp, (3) deprovisioning events occur within the policy-defined SLA after the trigger event (e.g. HR termination record).
Identity provider coverage report listing the systems whose authentication runs through the central identity provider and the recorded exceptions that do not, each with an owner and a review date.
Example: idp-coverage-report-2026-08-31.json
Test: Request the identity provider coverage report. Verify: (1) every production system and administrative interface either authenticates through the identity provider or appears on the exception list, (2) each exception carries a named owner and a review date that has not passed, (3) local accounts found on a sampled system outside the identity provider resolve to an exception entry, (4) the report is dated within the review interval the policy sets, (5) service identities and device identities that reach production are in scope of the report rather than excluded from it.
Questions (3)
Are formal, documented processes in place for provisioning and deprovisioning user accounts, including required approvals before access is granted?
Provisioning should require at minimum one named approver distinct from the requester. Approvals must be recorded in a ticketing or workflow system.
When an employee leaves or changes role, within what timeframe are their accounts disabled or access updated?
Same-day or next-business-day deprovisioning is best practice. Delays beyond 3 days create significant orphaned-access risk. The timeframe should be defined in policy and verifiable from logs.
Which of the following are managed through your central identity provider?
Options run from the most commonly covered to the least. An identity that lives outside the identity provider without being a recorded exception is invisible to joiner and leaver processing. Usage conditions set only in an access request cannot deny a login, which is why the question asks where they are set rather than whether they are agreed.