Divestiture and Carve Out Security: Systems and Data

A carve-out splits systems, data and networks that were built to be one, and every shared database, interconnect, backup set or cloud account left half-separated becomes a path between two companies that no longer trust each other. Divestiture security is the work of separating infrastructure and data so that each side ends up with what it owns, nothing it does not, and no hidden links. This guide covers the technical separation of data, cloud estates, networks, applications, endpoints and security tooling, from the planning phase to the final cut-over. It is for security architects, infrastructure leads and separation programme managers on the seller's side, and is useful to buyers who need to know what to ask for. Identity separation (directories, tenants, accounts and NHIs) has its own guide, the Identity separation in divestitures guide; this page covers everything around it.

Source note: cloud platform behaviour, ICO and NIST points below are summarised from the official documentation listed in the references, as checked in November 2026. This is security guidance, not legal advice. Confirm against the official text before relying on it.

Key takeaways

Pick a separation pattern per system. Transfer, clone and sanitise, rebuild, or retain under a service agreement; each has a different security risk, and most carve-outs use all four.
Commingled data is the hardest part. ERP, data warehouses, file shares, email archives, logs and backups hold both businesses' data, and a clone carries all of it unless you filter it.
Cloud moves are not clean by default. Moving an AWS account, Azure subscription or Google Cloud project leaves behind some access and breaks other settings, so each platform needs its own checklist.
Every interconnect needs an owner and an end date. VPN tunnels, private links, firewall rules, DNS records and mail routing between the two companies must be listed and removed on schedule.
Finish with evidence of the cut. Network flow data, data deletion records and sanitisation certificates show that separation happened, which matters for regulators, auditors and the buyer.

Separation patterns

NHI Mgmt Group recommends choosing the pattern system by system during planning, not during cut-over. The choice drives most of the security work.

Pattern	What happens	Main security risk	Control that matters most
Transfer	The system, account or subscription moves to the divested business as it is	Seller data, credentials and admin paths travel with it	Pre-transfer data scrub and credential rotation
Clone and sanitise	A copy is made, then data that does not belong to the divested business is removed	Incomplete filtering leaves the seller's data in the clone, including in logs and history tables	Data allocation rules tested on the clone before handover
Rebuild	The divested business stands up a new system and migrates only its own data	Migration tooling and service accounts with access to both sides	Scoped, time-limited migration access, removed at the end
Retain under agreement	The seller keeps running the system for the divested business for a period	Shared system with two customers whose interests now differ	Logical separation, separate logging, fixed exit date; see the Third-Party Access Guide

Clean-room or "clone and go" approaches are quicker on day one but move risk into the sanitisation step. Rebuilds take longer but leave the cleanest result. When a system holds regulated data from both businesses, rebuild or retain usually beats clone.

Data separation

Start with an allocation register: every data store, which business owns each data set in it, and the rule for splitting it. The UK Information Commissioner's Office (ICO) data sharing code says that in mergers, acquisitions and restructures you should establish what data is being transferred, the purposes for which it was originally obtained and your lawful basis for sharing it, document the sharing, and seek technical advice where different systems are involved because of the risk of data loss, corruption or degradation. It also asks for appropriate security while systems are being integrated. (The ICO notes that this guidance is under review because of the Data (Use and Access) Act, so check the current version.)

Data location	Typical problem	Approach
ERP and finance systems	Shared ledgers, customers and suppliers across entities	Split by legal entity or company code; extract the divested entity's records; keep shared master data only where the agreement allows
Data warehouses and lakes	Joined and derived tables mix both businesses	Rebuild derived data from the divested business's sources rather than filtering outputs
File shares and collaboration sites	Folders used by both teams; inherited permissions	Classify by owning team, move, then remove the divested team's access to what stays
Email and archives	Mailboxes contain the other side's confidential correspondence	Agree a filtering and legal review approach; preserve anything under legal hold first; see the eDiscovery and Legal Hold Guide
Logs and security telemetry	Logs contain both businesses' user and system data	Decide who keeps historical logs and for how long; export what the divested business needs for its own investigations
Backups	Backup sets cannot be filtered without restoring them	Agree that the seller keeps historical backups under its retention policy and restores on request, or that new backups start clean at cut-over; see the Backup Security and Immutable Backup Guide
Source code and artefacts	Shared libraries and repositories; secrets in history	Agree licensing of shared code; scan history for secrets before transfer and rotate any found

Delete what leaves: once the divested business's data has moved, delete it from the seller's systems according to the agreement and the seller's retention schedule, and record the deletion. See the Data Retention and Secure Deletion Guide.
Personal data: update records of processing on both sides and check transparency obligations to individuals. See the Data Mapping and ROPA Guide.
Encryption keys: data encrypted with the seller's keys needs re-encryption under the divested business's keys, or the key has to move with the data and then be rotated.

Cloud estate separation

Cloud separation is usually the fastest part of the carve-out if the divested business ran in its own accounts, subscriptions or projects, and the slowest if it shared them. Platforms are listed alphabetically. Each platform has documented behaviour when an account, subscription or project changes owner, and the security steps follow from it.

AWS

Before the move: check for service control policies that deny organizations:LeaveOrganization, which block the move; deregister any delegated administrator role the account holds; export organisation-level billing reports, which are deleted when the account leaves; and remove MFA from the root user if ownership changes so the new owner can sign in.
Access left behind: removing a member account does not delete OrganizationAccountAccessRole or other roles created for the old management account. Delete them, or the seller keeps a path in.
After the move: update policies that use the aws:PrincipalOrgID condition key, recreate account and OU tags, and review services that depended on trusted access in the old organisation.

Google Cloud

Before the move: recreate organisation-level custom roles in the destination organisation, because they do not exist there.
What changes: roles granted directly on the project move with it; roles inherited from the source organisation or folders are lost; the source organisation's policy constraints are replaced by the destination's. Project ID, resources and running services stay the same with no downtime, and the project stays linked to its original billing account until changed.
After the move: review direct project grants, which may still name seller users or groups, and relink billing. Moving a project back to "No organization" needs Cloud Customer Care.

Microsoft Azure

Before the move: transferring a subscription to another Microsoft Entra directory permanently deletes role assignments and custom roles, so export them first. Plan re-creation for resources the documentation says must be re-created rather than moved, such as AKS clusters and Azure Databricks workspaces, and disable customer-managed keys held in a key vault that is moving, which can otherwise leave data unrecoverable.
Access left behind: storage account access keys, management certificates and remote access credentials still work after the transfer. Rotate them to cut off users in the old directory.
After the move: re-enable or recreate managed identities, update Key Vault tenant IDs and access policies, re-create storage ACLs and Azure Policy assignments. Microsoft Sentinel workspaces are offboarded immediately and must be re-onboarded within 90 days to keep their data.

Where the divested business shared accounts, subscriptions or projects with the seller, rebuild rather than move: create new ones for the divested business and migrate workloads, so no shared history comes with them.

Network and DNS separation

Build a register of every connection between the two estates before cut-over, using network flow data as well as firewall configuration, because undocumented links are common.

Connection	Where to find it	Separation action
Site-to-site VPNs and private circuits	Firewall and router configuration, carrier contracts	Replace with a time-limited, filtered interconnect for the service agreement; remove at exit
Cloud peering and transit	VPC peering, transit gateways, virtual WAN, shared VPC host projects	Remove peering; move workloads out of shared VPCs
Firewall rules	Rules referencing the other side's address ranges	Remove at exit; re-address where ranges overlap
Remote access	VPN gateways, jump hosts and remote access tools	Separate gateways; remove the other side's users and devices
DNS	Internal zones, conditional forwarders, public zones and registrar accounts	Transfer domains the divested business owns; remove records pointing to the other side's addresses to avoid dangling records
Email routing	MX, SPF, DKIM and DMARC records, mail connectors and relays	Separate mail flow; update SPF includes and DKIM keys so neither side can send as the other
Certificates	Shared wildcard and SAN certificates	Issue new certificates per business; revoke shared certificates whose private keys the other side held

See the Domain and DNS Management Policy Template and the Network Segmentation Guide.

Applications, code and endpoints

Source repositories: when a GitHub repository is transferred, its webhooks, secrets and deploy keys stay associated with it, and the original owner is added as a collaborator. Review and rotate secrets and deploy keys, remove the old owner and check webhooks that post to seller systems. Scan full history for committed secrets before transfer.
CI/CD and build systems: runners, artefact repositories and signing keys are often shared. Give the divested business its own runners and new signing keys; do not copy the seller's signing key.
SaaS applications: split workspaces or create new tenants; check integrations that connect the divested business's tenant to the seller's.
Endpoints: unenrol devices from the seller's management and security tools, re-image or re-enrol into the divested business's tools, and remove seller certificates and VPN profiles. Do not let devices leave with seller management agents still installed.
Retired hardware and media: servers, storage and devices that are not transferring but held divested data must be sanitised. NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization, was finalised in September 2025. See the Media Sanitisation Guide.

Security tooling and logs

Detection coverage on day one: the divested business must have EDR, SIEM, email security and vulnerability scanning running before the seller's tools are removed. Plan a short overlap, not a gap.
Licences tied to the seller: security tools licensed to the seller's tenant stop when the divested estate leaves. Order replacements early.
Historical logs: decide who holds pre-separation logs, for how long, and how the other side can request them for an investigation.
Incident handling during separation: agree a joint process for incidents that touch both estates until cut-over. See the Third-Party Incident Response Playbook.

How to implement

The steps below are NHI Mgmt Group recommendations.

Plan (signing): build the system and data inventory, choose a separation pattern per system, list interconnects and agree which services the seller will keep running under a service agreement.
Prepare (signing to close): stand up the divested business's landing zone and security tooling; test data allocation rules on clones; export role assignments, policies and billing reports from cloud estates that will move.
Pilot: move one low-risk system end to end, including data scrub, credential rotation and interconnect removal, and confirm with flow logs that nothing still talks across.
Migrate in waves: group systems by dependency; for each wave, rotate credentials, move or rebuild, validate, then remove the old access path.
Roll back safely: keep the source system read-only for an agreed period after each wave, never live in parallel, so you can recover without both sides writing to it.
Cut over and exit: remove interconnects, revoke shared certificates, delete transferred data from the seller's systems, sanitise retired media, and collect evidence of each step.

Decision guidance

The guidance below is NHI Mgmt Group's recommendation.

Transfer or rebuild: transfer when the divested business ran in its own accounts or subscriptions with little shared data. Rebuild when the estate is shared, regulated data is mixed, or the seller's admin history is hard to clean.
Clone or retain: cloning a shared ERP is quick but carries the seller's data; retaining it under a service agreement keeps one copy but creates a shared system. Prefer retain for a short period followed by a rebuild when filtering is unreliable.
Small carve-out: a team of a few dozen people using SaaS tools may need only new tenants, device re-enrolment and data export. Keep it simple and finish fast.
Large carve-out: thousands of users, data centres and regulated data need a separation management office, a full interconnect register and staged waves over months.
Buyer as a large acquirer: if the divested business goes straight into a buyer's estate, the buyer's standards decide the target state; agree them early so the seller does not build a standalone environment that is then rebuilt again.

Detection and measurement

Monitor for traffic and access that should no longer exist:

Cross-estate flows: network flow logs and firewall logs showing traffic between the two estates outside the agreed interconnect.
Access from the other side: sign-ins and API calls to moved cloud estates from the seller's address ranges or identities, and the reverse.
Use of old credentials: attempts to use rotated keys, revoked certificates or deleted roles, which show a missed dependency or misuse.
Data still in place: discovery scans of the seller's stores for data classified as belonging to the divested business after the deletion date.

Metrics:

Percentage of systems with an agreed separation pattern and owner.
Interconnects open against the register, trending to zero at exit.
Data stores with a recorded deletion or transfer certificate.
Days of detection coverage gap for the divested business (target zero).
Retired assets with sanitisation records.

Common failure patterns

Cloning without filtering history: a cloned database is scrubbed in its main tables but keeps the seller's data in audit tables, logs and backups.
Forgetting the management role: an AWS account moves but OrganizationAccountAccessRole remains, a Google Cloud project moves with direct grants that still name seller groups, or an Azure subscription moves but storage access keys are never rotated, leaving the seller with a path in.
Undocumented interconnects: a legacy VPN or peering connection nobody listed stays up after exit because the register was built from documentation rather than flow data.
Dangling DNS and shared certificates: records still point to addresses the other side controls, and wildcard certificates with shared private keys stay valid.
Detection gap at cut-over: the seller's EDR and SIEM are removed before the divested business's tools are live.
Retained service with no exit date: a system kept running "for now" becomes a permanent shared dependency.

Framework mapping

Activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5
System and data inventory, allocation register	ID.AM-02, ID.AM-07	CM-8 System Component Inventory
Interconnect register and data flows	ID.AM-03	SC-7 Boundary Protection
Removing interconnects and cross-estate access	PR.IR-01	SC-7 Boundary Protection, AC-20 Use of External Systems
Data transfer, retention and deletion	ID.AM-08, PR.DS-01	SI-12 Information Management and Retention
Key and certificate separation	PR.DS-01	SC-12 Cryptographic Key Establishment and Management
Media sanitisation	ID.AM-08	MP-6 Media Sanitization
Historical logs and backups	PR.PS-04	AU-11 Audit Record Retention, CP-9 System Backup
Retained services and exit	GV.SC-10	SA-9 External System Services

The threats addressed include MITRE ATT&CK T1199 Trusted Relationship, where a remaining link between the companies is abused, and T1078.004 Cloud Accounts, where access left in a moved cloud estate is used.

Practitioner checklist

Inventory every system and data store and record a separation pattern and owner for each.
Build an allocation register for commingled data and test the split rules on a clone before handover.
Agree who keeps historical logs and backups, for how long, and how the other side requests them.
Follow each cloud platform's move checklist, including removing old management roles and rotating keys that survive the move.
Build the interconnect register from flow data, give each link an end date and remove it on schedule.
Transfer domains, separate mail flow and issue new certificates; revoke shared certificates.
Rotate secrets and deploy keys in transferred repositories and give the divested business its own signing keys.
Have the divested business's security tooling live before the seller's tools are removed.
Delete transferred data from the seller's systems and sanitise retired media, with records.
Close with evidence: flow logs showing no cross-estate traffic and signed confirmation from both sides.

Divestiture and Carve Out Security: Separating Systems, Data and Infrastructure Cleanly