Business transformation changes the organisation’s shape; identity security has to preserve accountable access across that change. When the two are not coordinated, the security programme ends up certifying yesterday’s structure instead of governing today’s one.
What each function is responsible for
identity security is responsible for who and what can act, prove itself, and keep that access under control over time. Business transformation is responsible for changing operating models, processes, platforms, and organisational boundaries so the business can move faster or scale differently. The handoff point matters: transformation creates new actors, entitlements, and trust relationships, while identity security must make those changes governable.
In practice, the two functions are complementary but not interchangeable. Transformation leaders optimise for delivery, migration, and operating change; identity security optimises for accountable access, privilege boundaries, and lifecycle control. If one team defines the future state and the other still governs the old one, the organisation creates gaps in ownership, approvals, and offboarding that do not show up until audit, incident response, or a control failure.
Why the accountability model changes during transformation
Transformation work often moves faster than identity governance structures. New applications, automation paths, cloud services, partner integrations, and temporary migration accounts can appear before ownership, review cadence, and deprovisioning rules are updated. That is why identity security cannot be treated as a downstream clean-up function, and why business transformation cannot be treated as purely a business change exercise.
A useful way to separate the responsibilities is to ask whether the issue is changing how the organisation operates, or how access is made safe and accountable across that change. Transformation owns the former, including target operating model decisions and process redesign. Identity security owns the latter, including role design, access recertification, privileged access, secrets handling, and the controls that keep new organisational structures from inheriting old access assumptions.
Where this becomes most visible is in mergers, carve-outs, platform modernisation, shared service redesign, and automation programmes. Those efforts frequently create identity sprawl, orphaned access, duplicated roles, and misaligned approval chains. Teams that need a practical operating baseline often start with the identity security programme view, then align it to the broader transformation roadmap and ownership model.
Where coordination breaks down in real programmes
The most common failure is treating access governance as a one-time migration checklist. If the transformation team moves users, systems, or workflows without updating the authoritative identity model, the security function ends up certifying legacy structures that no longer reflect who actually performs the work. That weakens accountability even when the transformation itself is technically successful.
This is also where programme-level structure helps. A clear identity security operating model, such as the one described in the Identity Security Programme Guide, gives transformation leaders a way to assign RACI, roadmap, and funding responsibilities without collapsing identity governance into a generic change-management task. For lifecycle-heavy environments, the NHI Lifecycle Management Guide is useful where the transformation introduces non-human actors, automation, or service accounts that need provisioning, rotation, and offboarding discipline.
Business transformation also tends to expose whether the organisation can see its access estate at all. When identity data is fragmented, the programme cannot reliably tell whether access was removed, inherited, or duplicated. In that case, the question is not whether the transformation is strategic, but whether the access model is still trustworthy enough to support it.
Risk and Threat Considerations
Transformation becomes a security risk when the organisation changes structure faster than it changes entitlements, ownership, and review processes. The result is stale access, unclear accountability, and a larger attack surface created by temporary, inherited, or duplicated permissions.
Failure mechanism: New operating models are implemented before identity controls are realigned, so yesterday’s roles, approvals, and offboarding logic continue to govern today’s access paths.
Impact: Excess privilege, orphaned access, failed recertification, and weak auditability can persist across migrations, acquisitions, and automation rollouts, increasing the blast radius of both mistakes and compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Transformation reshapes operating context and ownership. |
| PR.AA-05 — Identity Management, Authentication, and Access Control | Access must remain governed through organisational change. | |
| Recommendation — Update identity ownership and approval paths to match the new operating model. Revalidate roles, approvals, and access paths after each transformation step. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Transformation introduces accounts that must be provisioned and removed cleanly. |
| AC-6 — Least Privilege | Changing structures often leaves unnecessary access in place. | |
| Recommendation — Tie account creation, review, and removal to current business ownership. Reduce inherited access to the minimum needed for the new state. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Identity security depends on maintaining controlled access during change. |
| Recommendation — Align access rules with the transformed organisation and its owners. | ||
Practitioner Guidance
What to prioritise: Establish the future-state ownership model before large-scale migration work starts. If the target operating model changes reporting lines, shared services, or application ownership, identity governance must be updated at the same time or earlier.
What to verify: Confirm that every transformed process has a named access owner, a review cadence, and a deprovisioning path. If any account, role, or entitlement cannot be tied back to a current business owner, treat it as a control gap rather than an administrative delay.
Common mistake: Assuming that a successful cutover means the access model is correct. Cutover proves the business can function; it does not prove that privilege, accountability, and lifecycle controls match the new structure.
Practitioner takeaway: Business transformation changes the map, but identity security must keep the map and the permissions synchronized; if they drift apart, the organisation scales misgovernance as efficiently as it scales the business.