What should organisations do differently for divestitures?

How divestitures change the security problem

A divestiture is not just a commercial separation. It is a security boundary change that rewires who owns systems, data, accounts, and administrative trust. The practical question is not only what is transferred, but what must be cut off, reassigned, or revalidated so the retained business and the carved-out entity no longer rely on the same access paths.

That is why separation planning has to start from shared access, shared credentials, shared administration, and shared services. If those dependencies are not inventoried early, the organisation usually discovers them too late, after the transaction has already fixed the legal structure but before the technical controls are ready.

What must be revoked, reassigned, or rebuilt

The most important security work in a divestiture is lifecycle control. Access must be explicitly revoked where it should end, reassigned where the business relationship continues, and rebuilt where the new entity needs independent operations. That includes user access, privileged access, service credentials, integrations, and any shared administrative channels.

The carve-out often inherits a messy mix of shared applications, overlapping entitlements, and historical exceptions. Treating that as an ordinary user offboarding exercise is a mistake. The correct control objective is to ensure the separated entity can operate independently without retaining hidden access to the former parent’s systems or data.

Where access is meant to remain shared for a transition period, it should be time-bound, documented, and reviewed like an exception, not left in place by default. A divestiture that does not have clear end dates for shared access is usually just postponing the same risk.

Why residual access becomes a real control failure

Residual access after a divestiture creates both security exposure and governance failure. If the separated entity can still reach shared systems, it may expose data that should no longer be shared, continue to act with inherited privilege, or create confusion over who is accountable for activity in the environment. That is why identity and entitlement cleanup are part of the transaction, not a post-close housekeeping task.

NIST Cybersecurity Framework 2.0 is a useful way to think about the problem because divestiture work spans govern, identify, protect, and recover activities at once. Likewise, NIST SP 800-53 Rev 5 Security and Privacy Controls aligns with the need to remove stale access, limit privilege, and preserve auditability during the separation process.

Practitioner Guidance

What to prioritise: Start with the shared assets that would cause the biggest blast radius if the carve-out retained access, especially admin accounts, directory trust, VPN or remote access, privileged toolchains, and shared SaaS tenants. Those are the places where one missed revocation can invalidate the rest of the separation plan.

What to verify: Require evidence that the separated entity no longer authenticates to retained systems, and that any access intentionally preserved is documented with an expiry date and owner. If you cannot show revocation, reassignment, or explicit exception handling for a pathway, assume the pathway still exists.

Common mistake: Teams often validate the legal transfer and the account lists, but not the actual dependency graph behind them. The result is duplicated access, lingering integrations, and cross-environment privileges that survive the closing date.

Practitioner takeaway: Treat divestiture as a controlled decommissioning of trust, not just a transfer of assets, and do not consider the separation complete until shared access is either removed or explicitly bounded.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of stale API keys and machine tokens?
• Should organisations treat non-human identities differently from human users in governance?
• Should organisations block local MCP servers or govern them differently?
• Should organisations treat PAM for Kubernetes differently from PAM for servers?