Carve-Out Technology Separation and TSA Risk

What the Division Does Not Own

Start by writing down what "shared" means, because in a corporate estate it means almost everything, and almost none of it appears in a data room as a line item.

Category	What the division uses today	What it owns on day one standalone
Infrastructure	Parent data centres, hypervisor clusters, storage, backup platform, network transit, DNS, certificate authority, email	Servers physically in its own facilities, if any
Identity	Parent Active Directory forest or Entra tenant, single sign-on, conditional access, MFA registrations, privileged access vault	Nothing. Identity is the parent's.
Security services	Parent security operations centre, SIEM, endpoint detection console and licences, vulnerability scanning, email filtering, incident response retainer, threat intelligence	Agents installed on endpoints, reporting to a console it does not control
Applications	Parent ERP instance, HRIS, payroll, expense, ITSM, document management, and often CRM	Division-specific applications only
Contracts	Enterprise agreements, volume pricing, support contracts, cyber insurance, all held at parent level	Contracts naming the divisional entity, which is a short list
People	Parent domain admins, network engineers, SOC analysts, ERP team, procurement, vendor management	Whoever transfers, which is usually a small fraction

The Diligence Illusion

The standard technology diligence questionnaire produces a flattering and useless picture of a carve-out. Every control it asks about exists. It exists at the parent.

The right question is not what the division's security posture is. It is which capabilities exist inside the perimeter of the thing being bought, which are rented, and what it costs to build the rest. Run the entire finding list through one filter: on the day the transition services agreement ends, does this still work, and who operates it.

That filter reclassifies most of a standard report. A mature vulnerability management programme becomes a scanner licence to be purchased, a tool to be deployed, a process to be written and a person to be hired. Twenty-four by seven monitoring becomes either a managed service contract with a procurement cycle and an onboarding period, or an internal team that does not exist. Patching compliance of ninety-four percent becomes a question about who runs the patching tool after the parent's team goes back to the parent.

This is a scoping problem before it is a security problem, and it is the reason carve-out diligence needs a different scope from standalone diligence. See Tech DD vs IT DD vs Cyber DD and the enumeration in the Technology Due Diligence Checklist, and apply the standalone filter to every line.

The Security Services Gap Is the One That Bites First

Infrastructure separation is visible, budgeted and project-managed. Security services separation is invisible until the day it is not.

The specific mechanism: endpoint detection agents on the division's machines report into the parent's console, under the parent's licences, watched by the parent's analysts. At separation, one of three things happens. The licences do not transfer and coverage stops. The licences transfer but nobody is watching the console. Or the buyer procures a replacement product, which means an agent swap across every endpoint and server in the estate, on a schedule, with a coverage gap in the middle.

The same pattern repeats across the security stack: SIEM ingestion and the historical log data inside it, email filtering, web filtering, vulnerability scanning, data loss prevention, cloud security posture tooling, the incident response retainer, and the threat intelligence feeds. Each has a licence question, a data question (does the historical data come with you, and in what format) and an operations question (who reads the alerts).

Ask the operations question explicitly and in writing. Alerting that nobody triages is not a control. See What Is Incident Response.

Certifications Do Not Transfer

This is the compliance consequence that surprises deal teams and creates revenue risk rather than compliance risk, which is why it belongs in front of the deal partner and not in an appendix.

A SOC 2 Type II report is issued to a named service organization, covering a defined system boundary, over a defined period. The separated entity is a different legal entity with a different system boundary, operating different infrastructure, with different personnel. The parent's report does not cover it. A bridge letter from the parent's auditor covering the gap since the report date covers the parent, not the new company.

The same holds for every other scheme, with variations that matter:

• ISO 27001. The certificate carries a scope statement naming the organization, the locations and the boundaries of the information security management system. A new legal entity needs its own certification, which requires a functioning management system, an internal audit cycle, a management review and a Stage 1 and Stage 2 audit.
• PCI DSS. The Attestation of Compliance names the assessed entity and covers a defined cardholder data environment. Separate the entity and the environment changes, which means re-scoping and, at Level 1, a new assessment. See What Is SOC 2 Compliance for how attestation scoping works in practice.
• FedRAMP. Authorizations attach to a specific system and a specific authorizing official. A change of the entity operating the system is a significant change requiring notification and review.
• HITRUST, CMMC and sector schemes. All entity-scoped and all requiring their own assessment cycle.

The timing problem is arithmetic. A SOC 2 Type II requires an observation period over which controls operated effectively, commonly three to twelve months. That period cannot begin until the controls are operating in the new company's own environment, which cannot happen until separation is far enough advanced. Add assessor scheduling and report production. The realistic path from close to a first Type II report is frequently twelve to eighteen months, and transition services agreements are frequently shorter than that.

Now read the customer contracts. Enterprise customers commonly require their vendor to maintain a current SOC 2 or ISO certificate, to provide the report annually, and to notify on any material change. Losing the certificate, even temporarily, can trigger a notification obligation, a remediation obligation, a service credit, an audit right or a termination right. That is revenue exposure with a date attached, and it belongs in the model.

Cyber insurance follows the same rule. The parent's policy does not travel with the division. The new company places its own cover, and the underwriter will ask about controls the new company does not yet operate. Answering those questions against the parent's control set rather than the new entity's actual state creates a coverage problem at exactly the wrong moment. See What Is a Cyber Insurance Attestation.

The Transition Services Agreement Is a Countdown, Not Insurance

Deal teams treat the TSA as cover. It is a clock with an escalating price.

Duration Realism

Typical technology TSAs run six to eighteen months with extension options. Separation programmes for a mid-sized division routinely run longer. The overruns are not random; they cluster in the same five places every time: identity separation, ERP, historical data migration, regulated workloads, and custom integrations that nobody documented and nobody remembers building.

The reason the overrun is systemic is worth stating plainly, because it explains why experienced teams keep making the same error. The TSA duration is negotiated by transaction lawyers, during the deal, against a services schedule assembled by the parent's IT function under time pressure, before anyone has performed the discovery required to know how long separation takes. The number is set before the work is understood. It is then treated as a plan.

The planning rule that follows: assume the first credible separation plan arrives sixty to ninety days after close and is longer than the TSA. Negotiate extension rights, and the price of extension, before you need them. Extension rights obtained in month fourteen cost what the parent decides they cost.

Cost Realism

Three cost mechanics are routinely missed in the model.

Markups and step-ups. TSA services are commonly priced at cost plus a margin. Extension periods frequently carry escalating rates, stepping up at each extension, sometimes to well above the base rate. The step-up is not a pricing accident. It is the parent's exit-forcing mechanism, and it is designed to bite precisely when the buyer is least ready to exit.

Running the old thing and building the new thing are two budgets. The TSA fee keeps the lights on. It does not fund the separation programme: the new data centre or cloud footprint, the new identity platform, the new ERP, the integration work, the programme management, the contractors, the dual-running period when both environments are live. Only one of those budgets is usually in the model, and it is the smaller one.

Dual running. For most of the separation, the new company pays the parent for the old service and pays vendors for the new one. Budget for overlap on every workstream, not a clean cutover.

Ask one question in diligence that changes the answer: are the TSA fees included in the quality of earnings normalization, and are they in the synergy case or netted against it. The answers are frequently no and no.

One more cost sits on the other side of the agreement. Reverse TSAs, where the separated business continues providing a service back to the parent, are common where the division held a specialist capability or a customer-facing system. They tie up the new company's scarce engineering capacity during precisely the period it needs that capacity for its own separation, and they are rarely priced to reflect that. Where a reverse TSA exists, count the headcount it consumes against the separation plan rather than treating it as revenue.

What a TSA Does Not Cover

Read the schedules, not the body of the agreement. The body is short and reasonable. The schedules are where the separation lives.

• Exit assistance and data extraction. Unless expressly scoped, the parent has no obligation to hand you your data in a usable form. Negotiate an extraction obligation specifying format, completeness, scope of history, timing, and a testing right. "Reasonable cooperation" is not an extraction obligation.
• Service levels. Many technology TSAs commit the parent to services "substantially consistent with historical practice" rather than to a measured service level with a remedy. Historical practice was delivered by a team that now has no commercial interest in the division and a full-time job elsewhere. Service degrades, and there is frequently no contractual instrument to arrest it.
• Change. Parents typically refuse to make changes to TSA services. The new company therefore cannot fix anything in the environment it is renting. When a security gap is found in a TSA-provided service, the remediation path is usually "migrate off sooner," not "fix it."
• Third-party consents. The parent's vendors may not permit the parent to provide the service to a third party. Consents are required, can be refused, and are routinely priced. Get the consent list early and treat every missing consent as a schedule risk.
• Security incident responsibility. Who investigates an incident in a TSA-provided service, who has the right to bring in forensics, who notifies regulators and customers, who pays, and who owns the evidence. Negotiate this expressly. In the absence of express terms, an incident during a TSA becomes a commercial argument between two parties who no longer share interests, conducted during the seventy-two hours when speed matters most.

When the TSA Expires and Stand-Up Is Not Done

There are three outcomes and all of them are bad.

Extend and pay. The step-up rates apply. The separation budget takes an unplanned hit and the programme, having demonstrated that deadlines do not hold, tends to slip again.

Cut over anyway. Declare readiness, migrate on the contractual date, and absorb whatever breaks. This is the outcome that produces regulatory attention, because what breaks is customer-facing.

Partial cutover. Move what is ready, extend what is not, and operate a hybrid with dependencies spanning two estates and no single owner. Often the worst of the three, because it combines cost with fragility and nobody can describe the resulting architecture on one page.

The governance rule that prevents the second outcome: write the go/no-go criteria before the pressure arrives, in objective and evidenced terms, and place the decision with someone who has the authority to spend money on an extension. A go/no-go decision made by a programme manager whose performance is measured on hitting the date is not a decision. Include a documented recovery test of the new environment among the criteria, and a rollback plan that has been tested rather than written. See What Is Business Continuity Planning and RPO vs RTO, noting that backup and recovery is itself frequently a TSA-provided service that disappears on the same date as everything else.

The Four Workstreams That Overrun

Identity Separation

The hardest work in a carve-out and the least budgeted. It is also the work with the longest dependency chain, because almost nothing else can complete until identity is settled.

Splitting an Active Directory forest or an Entra tenant involves, at minimum: migrating or recreating every user object with the permissions attached to it, untangling nested group membership that has accumulated over a decade, recreating group policy, re-establishing every application integration bound to the old tenant (SAML assertions, OIDC clients, LDAP binds, Kerberos service principal names), reissuing certificates, rebuilding conditional access, rebuilding privileged tiering, and re-registering multi-factor authentication for every single user.

Two parts of that list cause most of the damage.

Service accounts. A mature estate holds hundreds to thousands. Ownership is undocumented. Many carry passwords last rotated years ago, embedded in scripts, scheduled tasks, application configuration files and integration middleware. Each one either migrates, is recreated, or breaks something at three in the morning, and the only way to know which is to inventory them before the migration rather than after. The service account inventory is the dependency that blocks the rest of the identity programme, and it is the task most often started late because it produces nothing visible.

MFA re-registration. Splitting a tenant means every employee re-enrols a second factor. That is an authentication-grade event across the entire workforce, and it is simultaneously the best social engineering opportunity the company will ever hand an attacker. Carve-outs are announced publicly with dates. Attackers read announcements. Build the help desk identity verification process before enrolment starts, not after the first fraudulent reset, and consider phishing-resistant factors for the privileged population as part of the same exercise rather than as a later project.

The privileged access vault is a separate problem. It belongs to the parent, it holds credentials for both estates, and its contents cannot simply be exported. See What Is Privileged Access Management, What Is Identity and Access Management and What Is Identity Governance.

Entangled ERP and Data

If the division runs on the parent's ERP instance, there are three paths and each has a cost profile the model should carry explicitly.

• Clone the instance. Fastest technically. Carries the parent's configuration debt and the parent's data into the new company, which creates a data protection problem as well as a technical one. Licensing frequently forbids it outright.
• Implement new. Longest and most expensive, and the most common outcome for anything other than the smallest carve-outs. Budget in multiples of the initial estimate and in quarters rather than months.
• Stay on TSA. Cheapest today. Most expensive at expiry, because the decision has been deferred to the point of least bargaining power.

Data extraction is its own workstream. How many years of transactional history come with the business, in what format, reconciled by whom. Tax and audit will want history. Customers will want their own records. The parent will want to retain its own and will resist handing over shared master data. Then there is the genuinely entangled material: shared customer and vendor master records, shared purchase orders, intercompany balances, a shared chart of accounts, and shared document repositories where the division's files and the parent's files sit in the same folders with the same permissions.

Cost this properly rather than estimating it. The method matters more than the number: see Quantifying Technical Debt for the Deal Model.

Licences That Do Not Transfer

The assumption that software licences follow the business is wrong often enough that it should be treated as false until proven otherwise, contract by contract.

The economics are simple and unfavourable. The parent bought at enterprise volume with negotiated discounts. The new company buys at its own volume, which is a fraction of the parent's, at or near list price. The same functionality costs meaningfully more standalone, and the increase is a permanent hit to the opex line rather than a one-time separation cost.

The mechanism that most often kills an entitlement is the affiliate definition. The division enjoyed the licence because it was an affiliate of the licensee. On close it stops being one. Read every material technology contract for: assignment restrictions, change of control provisions, the affiliate definition, territory and entity limitations, and whether the licence metric is tied to the licensed entity, its revenue, its headcount or its processor cores.

Categories where this bites hardest: enterprise agreements with major platform vendors, database and middleware licensing where metrics are complex and audit exposure is high, virtualization, security tooling, engineering and design tools, and any product where the parent negotiated a bespoke enterprise arrangement that simply has no standalone equivalent.

Two further points. First, a separation is a known trigger for a vendor licence audit. Vendors read press releases, and a corporate reorganisation tells them entitlement questions are open. Budget for the possibility. Second, treat any vendor cost figure you are given as an estimate until it is a written quote to the new entity. Where the exposure is material, get the quote before close. See What Is Vendor Risk Management.

Network Separation

Shared IP address space, shared routing, shared internet egress, shared VPN concentrators, firewalls carrying rules that reference both estates, shared DNS, and certificates issued by the parent's certificate authority. Untangling all of that is well-understood engineering work with a predictable duration.

The dangerous part is the interim state. During the TSA the two companies are usually still connected, frequently with a flat or near-flat path between them, governed by rules written when they were one organization. Both sides now have a supply chain relationship with an entity they no longer control and whose security decisions they no longer see.

Handle the interim connection deliberately. Enumerate every required flow. Deny by default. Attach an owner and an expiry date to every rule, and review the rule set monthly rather than at the end. Log the traffic and give both parties visibility. Treat the interconnect as a third-party connection with a termination date, because that is exactly what it is. See What Is Network Segmentation and What Is Attack Surface Management.

Who Holds the Keys After Close

Ask the question in writing, before signing, and require a written answer: after close, who holds domain administrator rights, cloud tenant global administrator rights, hypervisor root, firewall administration, backup console administration, and the registrar and DNS accounts for the new company's own domains.

During a TSA the honest answer is usually the parent, in whole or in part. That is often unavoidable. It is also a third-party access relationship with privileged rights over your entire estate, and it should be governed like one rather than accepted silently because it is inconvenient to discuss.

Negotiate five things into the TSA:

• A named, enumerated list of parent personnel holding privileged access, maintained and provided on a defined cadence.
• Access through a logged and monitored path rather than direct administrative credentials.
• Visibility for the new company into that access log.
• Recertification at a defined interval, with the new company's approval required for additions.
• A removal obligation at exit, with a deadline and a written attestation from a named officer.

Then assume the attestation is incomplete, because it will be. Residual parent access is the failure that persists longest and is discovered latest. The categories to enumerate independently at TSA exit: named administrative accounts for parent staff, including staff who never worked on the division; shared accounts whose passwords were never rotated; federation trusts and directory synchronisation still running; VPN and remote access accounts; jump host and bastion access; guest accounts in SaaS tenants; service principals, app registrations and OAuth grants in the cloud tenant; long-lived API keys; certificates issued by the parent's certificate authority; and backup and disaster recovery console access, which is the one most often forgotten and the most dangerous to leave open.

Do a formal access termination at exit and treat it as an engineering exercise, not an email. Enumerate from the systems, not from the interview. Compare what you find against the parent's attestation and raise the difference. Then rotate everything the parent could plausibly have known: domain administrator credentials, service account passwords, API keys, shared secrets, database passwords, certificates and their private keys, and encryption keys where the design permits. See What Is Third-Party Risk Management and What Is Identity Governance.

Finally, note that the exposure runs both ways. While the estates remain connected, a compromise of the parent is a route into the new company, and the new company's controls during separation are weaker than either party's were beforehand. That risk window, and what to do about it, is the subject of Post-Close Technology Integration.

Related Reading

• Technology Due Diligence: The Complete Guide for Private Equity
• Post-Close Technology Integration: The First 100 Days
• Technology Due Diligence Checklist
• Quantifying Technical Debt for the Deal Model
• The Technology Due Diligence Report
• What Is Cyber Due Diligence

Frequently Asked Questions

Why does a carve-out inherit nothing from the parent company?

Because the division was assessed, secured and operated as part of a larger estate. Its infrastructure, directory, security operations centre, monitoring tooling, enterprise licences, ERP instance and specialist engineers all belong to the parent. The division has access, not ownership. Standalone diligence measures the parent's controls at the division and reports them as the division's, which produces a flattering and useless picture. The correct test for every finding is whether the capability still exists on the day the transition services agreement ends, and who operates it once the parent's team goes back to the parent.

How long should a technology transition services agreement run?

Typical technology TSAs run six to eighteen months with extension options, and separation programmes for mid-sized divisions routinely run longer. The overrun is systemic rather than accidental: the duration is negotiated by transaction lawyers, during the deal, against a schedule assembled by the parent's IT function, before anyone has done the discovery needed to know how long separation takes. Assume the first credible separation plan arrives sixty to ninety days after close and is longer than the TSA. Negotiate extension rights and the price of extension before you need them, not in month fourteen.

What happens when a TSA expires before separation is complete?

Three outcomes, all bad. Extend and pay, which triggers escalating step-up rates designed to force exit and blows the separation budget. Cut over anyway, declaring readiness against a contractual date and absorbing whatever breaks, which is the path that produces customer-facing failure and regulatory attention. Or partially cut over, leaving a hybrid estate with dependencies spanning two companies and no single owner. Prevent the second by writing objective go/no-go criteria before the pressure arrives and placing the decision with someone who has authority to spend money on an extension.

Why is identity separation the hardest part of a carve-out?

Because almost nothing else can complete until it is settled, and because two specific tasks are far larger than they look. Service accounts number in the hundreds or thousands in a mature estate, ownership is undocumented, and their credentials are embedded in scripts, scheduled tasks and application configuration. Inventorying them is the dependency that gates the whole programme and it produces nothing visible, so it starts late. Separately, splitting a tenant forces every employee to re-register multi-factor authentication, which is an authentication-grade event across the workforce and a first-class social engineering opportunity on a publicly announced date.

Do software licences transfer in a carve-out?

Frequently not, and the assumption should be treated as false until proven contract by contract. The mechanism that usually kills the entitlement is the affiliate definition: the division held the licence because it was an affiliate of the licensee, and on close it stops being one. The parent also bought at enterprise volume with negotiated discounts, so the separated entity repurchases the same functionality at its own much smaller volume, at or near list price. That is a permanent operating expense increase, not a one-time separation cost. Separations are also a known trigger for vendor licence audits.

Does a parent company's SOC 2 or PCI certification cover the separated entity?

No. A SOC 2 Type II report is issued to a named service organization over a defined system boundary; the separated entity is a different legal entity with different infrastructure and personnel. ISO 27001 certificates carry a scope statement naming the organization. A PCI Attestation of Compliance names the assessed entity and its cardholder data environment. Each requires its own scoping and its own assessment. A Type II also requires an observation period, commonly three to twelve months, which cannot start until controls operate in the new environment. That timeline rarely fits inside a TSA.

Who holds administrative access to a carved-out business after close?

During a transition services agreement it is usually the parent, in whole or in part, and that fact is often never written down. Ask in writing before signing who holds domain administrator, cloud tenant global administrator, hypervisor root, firewall, backup console, and registrar and DNS access. Then govern it as the privileged third-party relationship it is: a named list of parent personnel, access through a logged path, visibility into that log for the new company, periodic recertification, and a removal obligation at exit with a deadline and a written attestation from a named officer.

What is residual parent access and why does it persist after separation?

Residual access is the administrative access the parent retains after the TSA ends, usually because removal was handled as an email request rather than an engineering exercise. The categories that persist: named admin accounts for parent staff, shared accounts with unrotated passwords, federation trusts and directory synchronisation still running, VPN and jump host access, guest accounts in SaaS tenants, service principals and OAuth grants, long-lived API keys, certificates from the parent's certificate authority, and backup console access. Enumerate from the systems rather than the parent's attestation, verify the difference, then rotate every credential the parent could have known.

TSB and Lloyds: A Ten-Year TSA and a Three-Year Deadline

TSB is the most thoroughly documented technology separation failure in the public record, because two regulators investigated it and published their findings. Read it as a carve-out case, not as an IT case.

The separation. Lloyds Banking Group divested TSB in June 2014, a condition imposed following the group's state support during the financial crisis. TSB went to market with roughly 5.2 million customers and no IT platform of its own. It continued running on Lloyds' platform under an outsourcing arrangement that permitted continuation until July 2024. Two exit routes were contemplated: a carve-out, meaning an independent copy of the Lloyds platform, or a migration to an entirely new system. Following an external assessment in December 2014, TSB initially preferred the carve-out route.

The deadline changed when the owner changed. In July 2015 Banco Sabadell acquired TSB. Sabadell's offer document projected IT efficiency savings of approximately 160 million pounds per year from migrating TSB onto its own Proteo platform. Migration by the end of 2017 was central to the acquisition case and to the numbers presented to Sabadell's investors.

Note precisely what happened there, because it is the transferable lesson. The contractual runway ran to 2024. The investment case required 2017. The operative deadline was the one in the buyer's model, and it was roughly seven years shorter than the one in the agreement.

Execution. Sabadell appointed its own subsidiary, SABIS, to design, build, test and operate the new platform, named Proteo4UK. SABIS in turn engaged approximately eighty-five third-party subcontractors. The main migration event ran from 20 to 22 April 2018.

Outcome. Digital banking login success rates ran around ten percent in the immediate aftermath. Telephone banking took 69,000 calls by two in the afternoon, with waits reaching ninety minutes and call abandonment around seventy percent. Branch systems and payment processing failed, with between forty-eight and fifty-nine percent of some transaction types unsuccessful. A data incident exposed information relating to approximately 600 customers. TSB did not return to normal service until 10 December 2018, roughly seven and a half months later. The bank received 225,492 complaints and paid 32.7 million pounds in customer redress.

Regulatory finding. In December 2022 the Financial Conduct Authority and the Prudential Regulation Authority fined TSB a combined 48.65 million pounds, split 29.75 million and 18.9 million, after a thirty percent settlement discount from 69.5 million. The FCA found that TSB "failed to exercise due skill, care and diligence in managing the outsourcing arrangements with, and services provided by, SABIS"; that TSB "did not at the outset conduct a formal and comprehensive assessment of whether SABIS had the ability and capacity to perform the services"; and that TSB had not ensured that it had "sufficient visibility over the risks associated with the fourth parties SABIS was sub-contracting to." On readiness, the regulator characterised SABIS's confirmation as "forward looking statements of good intention or expectation rather than statements of fact."

Four things transfer directly to a mid-market carve-out.

• The investment case sets the real deadline. Whatever the TSA permits, the programme will be run against the synergy date. If the two differ, say so in the investment committee memo and price the gap.
• Fourth-party risk is not theoretical. Eighty-five subcontractors sat behind a single supplier, and the regulator's specific finding was that the bank could not see the risks they carried.
• A readiness attestation from the party doing the work is not evidence. Go/no-go criteria need to be objective, independently verified, and owned by someone with the authority to spend money on delay.
• Time is not the constraint people assume. Ten years of contractual runway produced a failed migration, because the programme consumed whatever time it was given and the decision to go was made against a commercial date rather than a technical one.