Cybersecurity During a Carve-Out: Who Owns Risk Until the TSA Ends?

On day one after a carve-out closes, the new company often runs on the seller's systems, the seller's network, and the seller's security stack - under a transition services agreement written by deal lawyers, not security people. The business has been sold. The attack surface has not moved.

This creates an uncomfortable gap that most deal teams acknowledge and few govern. Somewhere between signing and TSA exit, an incident will happen: a compromised account on the shared network, a vulnerability in a system the divested business still depends on, a breach in a dataset mid-separation. When it does, the first question is not technical. It is: whose problem is this, and who is allowed to do what about it?

Carve-out cybersecurity under a transition services agreement is a governance problem before it is a technical one. The organizations that handle it well mapped the responsibilities before close. The ones that struggle are reading the TSA during an incident.

TLDR

• Until the TSA ends, the divested business depends on systems and controls it no longer owns and may not be allowed to touch. Risk ownership during that window must be explicit.

• The TSA defines services and service levels, not risk accountability. The responsibility map - who can accept, mitigate, and escalate each risk - is a separate artifact someone must build.

• Access dependencies cut both ways: the buyer depends on the seller's security posture, and the seller's network carries the buyer's risk. Neither side can protect itself alone.

• Incident duties are the sharpest gap. Who detects, who decides, who notifies, and in what order should be agreed before close, not negotiated mid-incident.

• Boards should track separation progress against named exit criteria, and ask what unresolved risk remains at each TSA milestone.

The TSA is a services contract, not a risk transfer

Deal teams are rightly proud when the TSA covers everything: email, ERP, identity, endpoints, the SOC. But the TSA's purpose is continuity of service. It specifies what the seller will keep running, for how long, and at what cost. It rarely answers the questions an incident raises: who decides to isolate a system that serves both companies? Whose incident response plan runs? Who calls the regulator, the insurer, the customer?

The risk did not transfer with the equity. For the life of the TSA, the buyer's business sits behind controls the seller operates, under policies the buyer did not write, monitored by a team that now works for someone else. Meanwhile the seller carries a tenant it no longer owns inside its perimeter. Both sides have risk; the contract allocates services.

The responsibility map that should exist before close

The working artifact is a one-page responsibility map, agreed by both sides and reviewed by security leadership, not just counsel. Five columns do the work:

• Control owners. For each control the business depends on - identity, endpoint, monitoring, backup, vulnerability management - who operates it today, and on what authority?

• Access dependencies. Which of the buyer's people, systems, and data sit on seller infrastructure, and which seller systems still touch the divested business? List them; surprises live here.

• Incident duties. Detection, declaration, containment decisions on shared systems, notifications to each other, and external obligations. Who does what, in what order, within what time?

• Exit criteria. For each service, the specific conditions that end the dependency - not a date, a testable state: "buyer's IdP live, seller accounts deprovisioned, logs migrated."

• Unresolved gaps. The risks nobody owns yet. Every carve-out has them. The honest map names them with a decision owner and a deadline.

The questions that surface the gaps early

Directors and deal teams do not need to run the separation. They need to ask questions that reveal whether anyone is governing the window:

• Which security controls does the business depend on that we do not operate today?

• If we have an incident on seller-run infrastructure next month, who decides what - and is that written down anywhere besides the TSA?

• What access does the seller still have into our business, and what access do we still have into theirs?

• Which TSA services are past their planned exit, and what risk is carrying that delay?

• What is the named exit criterion for identity and email, and how far are we from it?

If the answers all point at the deal team and the TSA schedule, the security window is unmanaged. If they point at a responsibility map with owners and dates, someone is doing the work.

A worked example (fictional)

A manufacturer carves out its components division. The TSA runs twelve months: seller provides identity, email, ERP hosting, and SOC monitoring. At month four, the buyer's security lead - hired at close - finds a critical vulnerability in the ERP environment the business still runs on. Patching it is the seller's job under the TSA, but the seller's change window is six weeks out, and the buyer has no authority to patch a system it depends on but does not own.

The responsibility map, agreed before close, covers exactly this: emergency changes on shared systems require a joint decision within 48 hours, with a named executive on each side, and interim mitigations the buyer may apply to its own access. The patch lands in nine days instead of six weeks. Without the map, the same finding would have become an email thread between two legal departments while the exposure sat open.

Frequently asked questions

Who owns cyber risk during a carve-out transition services agreement?

Both parties, for different layers. The seller owns the operation of controls it still runs; the buyer owns the risk to its business outcomes and the decisions about its own exposure. The TSA allocates services, not accountability, so the two sides need a separate responsibility map covering control ownership, access dependencies, incident duties, and exit criteria.

Does the TSA cover cybersecurity responsibilities?

Rarely in full. TSAs specify services, service levels, and duration. They typically do not define who declares an incident, who may isolate shared systems, who notifies whom, or who can accept residual risk. Those duties must be agreed separately, ideally before close.

What is the biggest cyber risk in a carve-out?

Shared access and identity. The divested business runs on credentials, networks, and directories the seller operates, while the seller's environment still contains the buyer's people and data. Compromise on either side reaches both. Deprovisioning against named exit criteria - not calendar dates - is what actually ends the exposure.

When should the buyer's security team get involved?

Before close, ideally during diligence, and with authority from day one. A security leader who arrives at close with no seat in TSA design inherits dependencies they cannot see and cannot change. Early involvement is what turns the responsibility map from a wish into a signed artifact.

Closing

A carve-out does not end risk sharing; it formalizes it for a while. The TSA clock runs whether or not anyone is watching. The companies that separate cleanly are the ones that decided, before close, who could act while the wires were still shared - and wrote it down where an incident responder could find it.