Access reviews, SoD checks, and deprovisioning break first because they depend on a stable role and entitlement model. When migration changes business processes before governance is updated, teams certify the wrong access state and create audit gaps, insider risk, and compliance exposure that only appear after the new model is already in use.
Where cloud migration and governance diverge
Governance breaks first when the operating model changes faster than the control model. Cloud migration often shifts who owns access, how entitlements are grouped, and which business process is the source of truth. If access certification, segregation checks, and offboarding still assume the old structure, the control no longer describes reality, so review results become stale before anyone notices.
That mismatch is not just administrative friction. It creates a control plane that looks intact on paper while the new environment is already issuing access in a different way. The practical failure is not the migration itself, but the delay between new processes going live and the corresponding governance rules being redesigned to match them.
Why access reviews and SoD fail first
Access reviews depend on a stable entitlement model. When roles, application boundaries, or shared responsibilities change during migration, reviewers are asked to certify access that no longer maps cleanly to business function. That is how low-value exceptions get approved and real excess access is missed, because the review is grading the old model against the new one.
Segregation of duties fails for the same reason, but the failure is subtler. A process that was previously split across systems or teams may become consolidated in the cloud, while governance logic still treats those steps as independent. The result is either false confidence, because the conflict is invisible, or false blocking, because the policy flags combinations that are no longer operationally meaningful. In cloud programs, entitlement semantics need to be redesigned before the migration goes broad; see the Imperva breach 2019 for a concrete example of how cloud credential exposure and access control drift can amplify one another during transition.
What deprovisioning gets wrong during transition
Deprovisioning is often the first operational control to break because it depends on clean ownership, timely lifecycle events, and a reliable link between the worker, role, and account. During migration, those links are frequently duplicated, renamed, or inherited across platforms, so the trigger to remove access is delayed or never fired. The account remains valid after the business need has moved on.
That creates a compound problem. An old account can remain active in the target platform even after the employee changes function, leaves a team, or is separated from the original process owner. The governance issue is not only that access persists, but that the organization may no longer know which system should be authoritative for revocation. This is where audit gaps and insider risk start to appear as a byproduct of process migration, not as an isolated security defect.
Risk and Threat Considerations
When governance lags migration, the highest risk is silent overexposure: access that should have been reviewed, constrained, or removed stays live under a newer operating model that the control team has not yet mapped. That can lead to unauthorized access, excessive privilege, and audit findings that surface only after the business has already committed to the new design.
Failure mechanism: The entitlement model changes faster than the review, SoD, and offboarding rules, so certification attests to the wrong state and revocation misses the new authoritative source.
Impact: Excess access persists, segregation conflicts go undetected, and compliance evidence becomes unreliable because the control is measuring an outdated representation of the environment.
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 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Cloud migration drift often leaves users with excess access during entitlement redesign. |
| AC-5 — Separation of Duties | The question centers on SoD checks failing when process boundaries change in migration. | |
| AC-2 — Account Management | Deprovisioning breaks when account lifecycle ownership and source systems change during migration. | |
| Recommendation — Re-baseline access to least privilege before cutover and remove obsolete permissions promptly. Re-map duties after migration so conflicting roles remain prevented in the new operating model. Update account lifecycle ownership and disable stale accounts from the new authoritative source. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Permissions | Access reviews and entitlement governance are central to the migration-control mismatch described. |
| Recommendation — Align managed access permissions with the post-migration role model and recertify accordingly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is a failure to keep access governance aligned with the changed operating model. |
| Recommendation — Redesign access control rules to match the migrated business process and ownership model. | ||
Practitioner Guidance
What to prioritize: Rebuild the role and entitlement model before broad migration cutover, and treat access governance as part of the target operating model, not a downstream cleanup task. If the migration changes business ownership, shared services, or approval paths, the control design must change with it.
What to verify: Confirm that each critical access review has a current authoritative source, a current reviewer, and a current revocation path. If any one of those still points to the legacy process, the control is already failing even if no incident has been observed.
Practitioner takeaway: The safest migration is the one where governance is redesigned early enough that the new access model is certifiable before it becomes the default.
Related resources from NHI Mgmt Group
- What breaks when cloud migration starts before data discovery?
- What breaks when identity governance starts before visibility?
- What breaks when a cloud service is not fully operational before FedRAMP assessment starts?
- How should security teams prepare data governance before a cloud migration so the move does not create new chaos?