Ownership should be shared, but IAM must have explicit authority to review changes that affect identity logic. HR owns the source data, while IAM owns the downstream access outcomes. If either side can change the contract alone, the organisation creates silent failure risk and forces operations teams to clean up after production.
How should HR and IAM divide ownership of change impact review?
HR and IAM should not treat change impact review as a handoff where one team signs off and the other simply implements. The workable model is shared ownership of the review, with HR accountable for the accuracy and intent of source data and IAM accountable for the identity rules, provisioning logic, and downstream access effects that data creates.
The key distinction is between the business event and the access consequence. HR can own the employee or contractor change, but IAM must validate whether that change alters joiner, mover, or leaver behaviour, role mapping, entitlements, or timing. If neither team owns the full review path, the organisation ends up with orphaned access, broken deprovisioning, or approvals that look valid but no longer match reality.
This is why change impact review should be written into the operating model rather than left to personal judgement. A clear review boundary prevents “someone else will catch it” behaviour, especially where HR systems, identity platforms, payroll, and downstream applications each hold part of the truth. The Identity Security Programme Guide is useful here because it frames ownership, RACI, and governance as operating-model questions, not just technical ones.
What must each team own to avoid silent failures?
HR should own the source-of-record accuracy: job changes, manager changes, location, employment status, leave, termination, and any business meaning behind those events. IAM should own the translation layer: how those attributes trigger access changes, what gets provisioned or removed, and which approvals or controls are required before the change is allowed to take effect.
That split matters because source data and access outcomes are not the same thing. A correct HR record can still produce the wrong access if the mapping logic is stale, too coarse, or missing exception handling. Likewise, a correct IAM workflow cannot compensate for ambiguous upstream data if the identity event is incomplete or inconsistent. For identity lifecycle design and ownership boundaries, the NHI Lifecycle Management Guide and the broader Lifecycle Processes for Managing NHIs section are directly relevant because they stress provisioning, rotation, offboarding, and governance as lifecycle controls, not isolated admin tasks.
Practically, the review should answer three questions every time: does the source event change identity state, does it change privilege or access scope, and does it create a need for recertification or reapproval. If any answer is yes, IAM should be in the approval path, not merely the implementation queue.
Where does the review process usually break down?
The failure mode is usually not a dramatic outage. It is a slow divergence between HR intent and IAM enforcement. That can leave access active after termination, retain privileged roles after a transfer, or create duplicate identities when a name, manager, or employment classification changes. These are governance failures first, and technical failures second.
The most common pattern is unclear authority. HR believes it owns the employee record, IAM believes it owns access, and operations becomes the de facto reconciliation layer. That is where silent failure risk appears: changes are processed, but nobody validates whether the downstream access state still matches the source event. The Top 10 NHI Issues resource is relevant as a governance analogue because it highlights ownership, visibility, offboarding, and excessive permissions as recurring identity-control failure modes.
Another break point is change velocity. If HR can update fields that alter access logic without IAM review, the organisation creates a bypass around least-privilege controls. The problem gets worse when exceptions are informal, because the exception trail becomes impossible to audit later.
Risk and Threat Considerations
When change impact review is not explicitly shared, the organisation creates a trust gap between the system of record and the system of access. That gap can be exploited accidentally through process drift or deliberately through manipulated joiner, mover, leaver events that preserve more access than intended.
Failure mechanism: A source data change is accepted without IAM validating whether it alters access, so the identity platform continues to enforce outdated mappings, approvals, or entitlements.
Impact: The result can be silent overprovisioning, delayed deprovisioning, unauthorized access retention, and cleanup work that only appears after an incident or audit finding.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Change impact review governs provisioning and revocation outcomes for role and account changes. |
| IA-5 — Authenticator Management | Identity changes often affect credentials, reset flows, and lifecycle controls downstream. | |
| AC-6 — Least Privilege | Review must prevent HR-driven changes from creating excess privilege or lingering access. | |
| Recommendation — Require approval and review points for identity changes that alter access. Track and control credential changes when HR events affect identity state. Validate that each change preserves least-privilege access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Ownership of change review directly affects access decision boundaries and approvals. |
| A.5.16 — Identity management | The question concerns which team governs identity-impacting changes across HR and IAM. | |
| A.5.18 — Access rights | Change impact review determines when access rights must be amended or removed. | |
| Recommendation — Define who can approve access-impacting changes and who must review them. Assign clear identity ownership and review responsibility across HR and IAM. Reassess and update access rights whenever HR events change identity status. | ||
Practitioner Guidance
Decision rule: If a change can affect access, entitlement, or identity state, IAM must have veto or required-review authority, even when HR remains the source-of-record owner. If a change only affects descriptive employee metadata with no access consequence, HR can own it alone.
What to verify: Confirm that the workflow separates source-data ownership from access-outcome ownership, and that every change type has a named reviewer, an escalation path, and a testable rule for when IAM must intervene. The strongest control is a review model that can prove, after the fact, who approved the access consequence and why.
Common mistake: Treating HR-to-IAM integration as an implementation detail rather than a control boundary. That shortcut usually works until a termination, transfer, or manager change produces access that nobody can explain or revoke quickly.
Practitioner takeaway: Shared ownership works only when IAM is the authority on access impact and HR is the authority on source data, with no unilateral change path across the boundary.