Teams should prove separation by testing who can still reach the systems, data and automation that belong to the other side of the transaction. The useful evidence is not a broad certification summary but a targeted boundary check that shows inherited access has been removed and remaining operations still function.
How to evidence separation during a divestiture
The strongest proof is operational, not documentary. Teams need to show that access paths across the transaction boundary have been removed, that remaining permissions are limited to the correct side, and that any shared automation or integration no longer reaches assets it should not. The test should cover systems, data, and service access, not just user accounts.
What a boundary test should actually cover
A credible separation test starts with the inherited reach that often survives a carve-out: directory groups, shared admin roles, API credentials, service accounts, batch jobs, file shares, and delegated tooling. The goal is to prove that the divested entity can no longer authenticate or authorise into retained systems, while business-critical processes on each side still function under their new ownership.
That means testing real access, not only reviewing policy. Validate whether old credentials still work, whether tokens or certificates still have audience or scope that crosses the boundary, and whether automation can still call into systems that were meant to be cut off. If the divestiture includes shared platforms, prove that segmentation and tenancy controls now enforce the separation rather than relying on contractual intent.
What counts as convincing evidence
Convincing evidence is a targeted boundary pack that shows before-and-after state for access, plus the test results. Useful artefacts include revoked entitlements, successful negative tests, updated ownership records, and logs that show rejected attempts across the boundary. For automation-heavy environments, include service-to-service tests that confirm machine access has been constrained to the intended resources.
A strong evidentiary set also shows that the retained organisation has not broken its own operations while cutting access. That matters because divestiture work often creates pressure to leave temporary exceptions in place. Evidence should therefore prove both sides of the boundary: removed inherited access and preserved legitimate access.
Risk and Threat Considerations
Divestiture is a high-risk period because access that was once legitimate can remain technically valid after the business relationship changes. Shared credentials, cached sessions, federated trust, API tokens, and automation scripts can preserve reach long after ownership has moved. The main danger is not only accidental exposure, but also failed deprovisioning that leaves one party able to see, change, or extract the other party’s assets.
Failure mechanism: inherited permissions, trust relationships, and machine access survive the transaction cutover because they were not enumerated and tested end to end, or because shared services were not re-scoped before separation.
Impact: retained access can create data leakage, unauthorized administration, operational interference, and dispute over who can still control or observe critical systems. It also weakens the legal and audit posture of the separation because the organisation cannot prove that access was actually removed.
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-6 — Least Privilege | Divestiture separation depends on removing excess cross-boundary access. |
| IA-5 — Authenticator Management | Proving separation requires retiring or rescoping credentials, tokens, and keys. | |
| AC-17 — Remote Access | Cross-entity connectivity often persists through remote and federated access paths. | |
| Recommendation — Revoke nonessential cross-transaction access and validate least privilege at the boundary. Rotate or revoke inherited authenticators that can still reach the other side. Test and restrict remote access paths that cross the divestiture boundary. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Annex A access control supports proving that retained and divested access are separated. |
| A.8.5 — Secure authentication | Authentication must be revalidated when inherited access is removed during separation. | |
| Recommendation — Document and test access restrictions after the separation cutover. Verify that old authentication paths no longer permit cross-boundary access. | ||
Practitioner Guidance
What to verify: Treat the boundary as a live access problem, not a paperwork exercise. Verify that each account, token, key, role, integration, and automation path has an explicit owner on one side only, and that negative tests have been run against the former shared boundary.
Decision rule: If a control still depends on trust between the two parties, treat it as incomplete separation until that trust is replaced by explicit scoping, revocation, or isolation. If the business needs a temporary exception, time-box it and test it like any other privileged path.
Practitioner takeaway: The best divestiture evidence is a repeatable access test that proves the old boundary no longer works in practice, while the new operating model still does.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should security teams handle data discovery and access control during a merger or divestiture?