Transitional Service Agreements: Security After a Sale

After a business is sold, a transitional service agreement (TSA) keeps it running on the seller's systems for months, and during that time two separate companies share email, ERP, networks and support teams with no security terms beyond what the deal lawyers remembered to write down. A TSA is the contract under which the seller (or sometimes the buyer) provides IT and business services to the divested business for a fixed period after closing, until it can stand on its own. Security is usually a short clause in a long commercial schedule, which leaves incident notification, patching, logging, audit and exit undefined. This guide sets out how to govern security across the life of a TSA: what to put in the security schedule, how to split responsibilities, how to run and monitor the shared services, and how to exit cleanly. It is for CISOs, security governance leads and separation managers on both sides. Access controls for TSA users are covered in the Identity separation in divestitures guide.

Key takeaways

Treat the TSA as a supplier relationship from day one. The two companies now have different owners, risk appetites and regulators, so normal third-party risk controls apply, even if the same people run the systems.
Write a security schedule, not a clause. List each service, the security obligations attached to it, the notification times and the evidence each side can ask for.
Settle the data protection roles early. Where the seller processes the divested business's personal data, it usually acts as a processor and needs Article 28 terms under UK and EU GDPR.
Incident notification runs both ways. Either side can be the source of an incident that hits the other, and public companies may have their own disclosure clocks, so agree hours, contacts and information sharing.
Every service has an exit date and an exit test. Extensions are common and costly; tie each service's end to evidence that access, data and interconnects have been removed.

What a TSA covers and why security gets lost

A TSA typically lists services in schedules, each with a description, a service owner, a duration and a price. IT services commonly covered include email and collaboration, ERP and finance, HR and payroll systems, the service desk, end-user device support, network and data centre hosting, and security operations. A reverse TSA runs the other way, where the divested business provides services back to the seller.

Security tends to fall through the gaps for predictable reasons:

Deal timing: TSAs are negotiated quickly before closing by commercial and legal teams, often with a single generic clause requiring "the same standard of care as before closing".
"Same as before" is not a standard: before closing, both businesses accepted one risk owner. After closing, the provider has little incentive to improve controls for a departing customer, and the recipient has little visibility.
Shared people: the same administrators serve both companies, so access and confidentiality depend on individuals rather than design.
Extensions: services planned for six months run for eighteen, and controls designed as temporary become permanent.

The security schedule

Attach a security schedule to the TSA that applies to every service, with service-specific additions. The table lists what it should define; the example terms are NHI Mgmt Group recommendations to negotiate, not market norms.

Topic	What to define	Example term
Baseline controls	The control standard the provider maintains for in-scope services	Provider keeps its documented policies and controls in force and gives notice of any material reduction
Logical separation	How each side's users, data and administration are separated in shared systems	Recipient data held in separate tenants, databases, sites or folders; recipient staff see only recipient data
Access	Who can access what, approval, review frequency and removal	Named groups per service; access reviewed monthly; leaver removal within an agreed time
Vulnerability and patching	Provider's patching commitments for in-scope systems	Critical patches applied within the provider's own policy timescales; exceptions reported to the recipient
Logging and monitoring	Which logs are kept, who monitors them, and what the recipient can receive	Security-relevant logs for recipient users and data retained and provided on request or by feed
Incident notification	Definition of a security incident, notification time, contacts, information to share, cooperation	Notify within an agreed number of hours of becoming aware; share indicators and timelines; joint calls for incidents touching both sides
Change control	Notice of changes that affect security of the services	Advance notice of changes to authentication, logging or data location
Assurance and audit	Evidence the recipient may request and audit rights	Existing certifications and reports, completion of a questionnaire, targeted audit for cause
Subcontractors	Use of third parties to deliver services	Existing subcontractors listed; new ones notified with a right to object for those handling recipient data
Data protection	Roles, Article 28 terms where the provider is a processor, international transfers	Data processing terms annexed to the TSA
Exit	Data return or deletion, access removal, interconnect removal, evidence	Per-service exit plan; deletion confirmed in writing within an agreed period after exit

Use a responsibility matrix per service so there is no doubt who owns each control. The Shared Responsibility Matrix Template works well for this, and the Shared Responsibility Models Guide explains the approach.

Data protection roles and Article 28

When the seller runs systems that hold the divested business's personal data and processes it on the divested business's behalf, the seller is usually a processor and the divested business a controller. The ICO's guidance on Article 28(3) of the UK GDPR lists what the controller-processor contract must include. For a TSA, the terms that matter most for security are:

Security of processing: the processor must take the measures required by Article 32.
Sub-processors: the processor needs the controller's prior written authorisation, specific or general, before engaging another processor, and must pass on equivalent obligations.
Breach assistance: the processor must help the controller meet its duties to report personal data breaches to the regulator and to affected individuals.
Deletion or return at the end: at the controller's choice, the processor deletes or returns all the personal data when the service ends and deletes existing copies unless the law requires retention.
Audit: the processor provides the information needed to show compliance and allows audits or inspections by the controller or its appointed auditor.

Some data, such as shared historical records in an ERP, may remain with the seller as a controller in its own right. Map which data sets fall under which role during separation planning; the ICO's mergers and acquisitions guidance in its data sharing code also asks for appropriate security while systems are being integrated. Financial entities in the EU should check whether TSA services count as ICT services under DORA, which sets its own contractual requirements; see the DORA Article 30 Contract Provisions Guide.

Incident notification and disclosure

A TSA links two incident response programmes. An intrusion in the seller's shared email platform exposes the divested business's mail; a compromised laptop in the divested business can reach seller systems through the interconnect. Agree:

A shared definition: what counts as a security incident affecting the other party, including suspected incidents.
Notification time and channel: a fixed number of hours from awareness, named 24x7 contacts on both sides, and an out-of-band channel in case email is affected.
Information to share: affected systems and data, indicators of compromise, timeline, containment actions, and later the root cause.
Containment rights: who may cut the interconnect or suspend accounts, and on whose decision, so containment is not delayed by contract arguments.
Regulatory clocks: each party's own notification duties. US public companies must file Form 8-K Item 1.05 for a cybersecurity incident they determine to be material, generally within four business days of that determination, so both sides need facts quickly. See the SEC Cybersecurity Disclosure Rules Guide.

Write the joint process into both incident response plans and test it with a tabletop exercise in the first month. The Third-Party Incident Notification Clauses Guide and the Third-Party Incident Response Playbook give wording and steps.

Running the TSA securely

Once the TSA starts, govern it like any important supplier, with a cadence and evidence.

Control area	Provider (usually seller)	Recipient (usually divested business)
Access	Provision recipient users into scoped groups; remove leavers; report privileged access to recipient systems	Send joiner and leaver changes promptly; review access lists each month
Interconnects	Keep a register of every link to the recipient; restrict to agreed services and ports	Validate the register against its own flow data
Logging	Retain and deliver agreed logs for recipient users and data	Ingest logs into its own monitoring; investigate its own alerts
Vulnerabilities	Patch shared systems; report overdue critical items affecting recipient services	Patch its own endpoints and systems that connect in
Endpoints	Support devices under the agreed service; keep security agents current	Plan migration of devices to its own management
Governance	Report monthly on security metrics and incidents	Track exit progress per service; escalate gaps

Separate administration: where possible, have provider administrators who serve the recipient work through a dedicated privileged access path with session logging, so their actions on recipient systems are attributable.
Machine credentials: service accounts, API keys and integration credentials shared across the boundary should be listed in a register with an owner on each side and a rotation date at exit. See the Third-Party Credential Register Template.
Confidentiality: shared staff may see both companies' commercial information. Agree confidentiality obligations and, where needed, limit which staff serve the recipient.

Exit and extensions

Exit is where most TSA security risk is created or removed. Plan it per service from the start, under the same principle as NIST CSF 2.0 GV.SC-10, which expects supply chain plans to cover activities after a service agreement ends.

Agree an exit plan per service at signing: target date, migration approach, data to return, data to delete, access and interconnects to remove, and the evidence each side will provide.
Run a readiness check before each exit: the recipient's replacement service is live, monitored and tested; data has migrated and been validated.
Freeze, then cut: set the provider's copy to read-only for a short agreed period rather than running both live, so issues can be fixed without two systems of record.
Remove access and links: disable recipient accounts on provider systems, remove trusts and cross-tenant settings, close firewall rules and VPNs, and rotate any shared credentials.
Delete or return data: carry out the agreed deletion and record it, in line with the Article 28 end-of-contract terms where they apply.
Confirm in writing: both sides sign off that the service is exited, with the evidence attached.

Extensions are common. When one is requested, treat it as a new decision: reconfirm the security schedule, check whether temporary controls are still adequate for a longer period, and set a new exit date with a named owner. An open-ended TSA is effectively a permanent shared dependency and should move to a formal long-term service agreement with full supplier terms.

Decision guidance

The guidance below is NHI Mgmt Group practitioner judgement, not legal advice.

Short TSA or full supplier terms: for services under a few months with little sensitive data, a security schedule with notification and exit terms is usually enough. For long durations, regulated data or critical services, apply your full third-party security terms and assessment.
Logical separation or early migration: if a shared system cannot separate the two businesses' data and administration, migrating that service early may cost less than the controls needed to share it safely.
Seller perspective: limit the recipient's access to listed services only, treat its network as untrusted, and make sure TSA obligations do not stop you patching or changing your own systems.
Buyer or recipient perspective: insist on log access and incident notification, because you are accountable for your data while having no control over the systems that hold it.
Small carve-out: a short TSA covering email and a few SaaS applications may need only a one-page schedule. A large carve-out with ERP, data centres and security operations needs a security governance forum that meets weekly.

Detection and measurement

Each side should monitor the boundary:

Traffic outside the agreed services across the interconnect, from flow and firewall logs.
Access to data outside scope: recipient users reaching seller data, or provider administrators reaching recipient data without a ticket.
Use of shared credentials from unexpected sources, and any use after their planned rotation date.
Exit slippage: services past their exit date without an approved extension.

Metrics for the TSA governance forum:

Services with a signed security schedule and exit plan (target 100%).
Mean time from incident awareness to notification of the other party, against the agreed hours.
Access review completion per month and leaver removal times.
Services exited on time, and the number of extensions.
Interconnects and shared credentials still open, trending to zero.

Common failure patterns

"Same standard as before closing": a single clause with no list of controls, notification times or evidence rights, which nobody can enforce.
No data protection terms: the seller processes the divested business's personal data for a year without Article 28 terms, leaving both sides exposed.
One-way notification: the TSA obliges the provider to report incidents but not the recipient, even though the recipient's endpoints connect into the provider's network.
Shared administrators without attribution: the same admin accounts serve both companies, so nobody can tell whose data an action touched.
Exit without evidence: services are "turned off" commercially while accounts, VPN tunnels and shared keys stay live. The Cloudflare breach shows how a small number of credentials left unrotated after a supplier incident can open a path weeks later.
Endless extension: temporary controls become permanent and are never reassessed.

Framework mapping

TSA activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Responsibility matrix per service	GV.SC-02	SA-9 External System Services
Security schedule and contract terms	GV.SC-05	SA-4 Acquisition Process, SA-9 External System Services
Ongoing monitoring and assurance	GV.SC-07, GV.SC-09	SR-6 Supplier Assessments and Reviews, AU-6 Audit Record Review, Analysis, and Reporting
Joint incident process	GV.SC-08	IR-6 Incident Reporting
Interconnect register and limits	GV.SC-05	CA-3 Information Exchange, SA-9(2) Identification of Functions, Ports, Protocols, and Services
Shared staff and administrators	GV.SC-02	PS-7 External Personnel Security, AC-20 Use of External Systems
Exit and post-agreement activities	GV.SC-10	SA-9 External System Services

The main threat is MITRE ATT&CK T1199 Trusted Relationship: an attacker who compromises one party uses the TSA link to reach the other. NIST SP 800-161 Rev. 1 and the NCSC's 12 supply chain security principles, grouped as understand the risks, establish control, check your arrangements and continuous improvement, give a fuller supplier risk method that fits a TSA.

Practitioner checklist

Attach a security schedule to the TSA covering controls, separation, access, patching, logging, notification, change, audit, subcontractors, data protection and exit.
Build a responsibility matrix for every TSA service.
Map data protection roles and annex Article 28 terms where the provider processes the recipient's personal data.
Agree two-way incident notification with hours, 24x7 contacts and an out-of-band channel, and test it in the first month.
Keep a register of interconnects and shared credentials, each with an owner and an exit action.
Route provider administrators who serve the recipient through an attributable privileged access path.
Run a monthly governance meeting with security metrics and exit progress.
Agree a per-service exit plan at signing and require written evidence at each exit.
Treat every extension as a new decision with a reassessment and a new date.
Move any service expected to last indefinitely to a long-term agreement with full supplier security terms.

Transitional Service Agreements: Governing Security of Shared Systems After a Sale