Who is accountable for identity control gaps during a carve-out programme?

Why This Matters for Security Teams

Carve-out programmes create a temporary but high-risk identity state: one business is being separated, another is retaining shared services, and both need clean access boundaries before legal, operational, and audit obligations diverge. The identity control gap is not just an IAM issue. It is a governance issue that touches ownership, source-of-truth decisions, access revocation, and evidence collection.

NHIMG research shows how costly this can become when identity ownership is vague. The Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, while only 20% of organisations have formal offboarding and revocation processes for API keys. In carve-outs, that gap expands because access decisions are often split across M&A, infrastructure, IAM, security, and compliance teams. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports defined accountability and evidence-backed control operation, but it does not assign business ownership for the separation itself.

Practically, the business owner of the separated entity must own the outcome, because technical teams can execute controls only after the ownership boundary is clear. In practice, many security teams encounter unresolved entitlements only after the carve-out has already exposed systems, data, or secrets to the wrong side of the separation.

How It Works in Practice

The accountable owner should be the leader responsible for the separated business outcome, not the team that happens to administer the directory, vault, or network. That owner sets the target state: which identities stay, which move, which must be re-issued, and which must be removed. IT infrastructure, IAM, security, and compliance then become control owners for specific deliverables under that business mandate.

In a well-run carve-out, the operating model usually includes four layers:

• Business ownership defines which users, service accounts, API keys, certificates, and admin paths belong to the divested entity.
• IAM and infrastructure teams execute access removal, re-parent accounts, split tenants, and rebuild trust relationships.
• Security validates least privilege, monitors for orphaned access, and checks for secrets left behind in code, pipelines, or vaults.
• Compliance and audit teams preserve evidence that access was removed on time and that any temporary exceptions were approved.

This is especially important for non-human identities. NHIs often outnumber human identities by 25x to 50x, so the hidden risk is usually in service accounts, automation tokens, and CI/CD credentials rather than named users. The 52 NHI Breaches Analysis and the Top 10 NHI Issues show that poor visibility and weak rotation are recurring failure patterns. NIST identity guidance and control families such as AC and IA help translate that ownership into enforceable review, removal, and logging steps, but the programme still needs a named business decision-maker to settle disputes quickly.

That ownership model works best when it is documented in the separation plan, tied to a RACI, and reviewed at each milestone, because carve-out delays often come from unresolved questions about who can approve access removal for shared platforms, especially when identities span multiple tenants, environments, or third-party integrations.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance speed against assurance during a time-sensitive transaction. There is no universal standard for every carve-out structure, so the accountable party can shift slightly in practice, but the accountability principle should not. The business owner remains responsible even when execution is delegated.

One common edge case is a shared-services model, where the parent company temporarily continues to host identity infrastructure, vaults, or logging for the separated entity. Another is a partial carve-out, where only a product line or region is moving. In both cases, accountability must still be explicit for secrets rotation, access recertification, and account retirement. A practical rule is that whoever benefits from the post-separation operating model owns the decision risk, even if another team performs the technical work.

Current guidance suggests treating temporary exceptions as time-bound, approved, and measurable, not as open-ended workarounds. That is especially important when service accounts are embedded in automation or code, because those access paths are easy to miss during a spreadsheet-led review. The Ultimate Guide to NHIs — Standards reinforces the need to align policy, lifecycle control, and rotation discipline to reduce residual access. In carve-outs, the hardest failures usually occur when temporary shared access is never converted into a formal exception register and therefore never gets closed.

Related resources from NHI Mgmt Group

• Who is accountable when layered identity security leaves gaps between Microsoft and non-Microsoft environments?
• Who is accountable when hybrid identity governance leaves systems outside central policy control?
• Who is accountable when break glass access is used in a healthcare identity programme?
• Who is accountable when a cloud identity governance platform is used in a regulated environment and a control failure occurs?