A TSA period needs a governance operating system, not a standing status meeting. The buyer, seller, and business may share a service temporarily, but they do not share incentives. The seller wants a controlled workload and clean exit. The buyer needs continuity, access, data, and a tested path to independence. The business needs decisions that protect revenue, cash, employees, customers, and control.
If those interests are not separated, routine service issues consume executive attention while exit decisions wait. Scope expands, risk acceptance has no expiry, the service is green while the exit path is red, and extension cost appears after the value plan assumes independence.
The rule is simple: assign each decision to the party that controls the action and make the party bearing the consequence visible. Service delivery, changes, risk acceptance, commercial commitments, and exit gates need different forums and owners.
A TSA contains four different decision systems
Separate four systems:
Service operations keeps the current service inside its boundary: incidents, requests, service levels, access, maintenance, and defects. The seller executes; the buyer owns business adequacy and threats to Day-1 or exit.
Change control decides whether the service, interfaces, or assumptions should change. A small request can affect cost, security, data, or the exit date, so its requester should not approve its consequences alone.
Risk and exception acceptance decides what the parties tolerate when a service or control cannot be delivered. The risk owner accepts residual exposure, names a compensating control, and sets an expiry. The TSA manager records the decision but does not accept buyer risk.
Transition and exit decides whether a replacement is ready, a service can be reduced, or a failed gate needs a fallback. An exit date belongs here, not in service review; a stable service can still lack data, support, vendor rights, or control.
Share information across these systems, not accountability. The service forum can recommend a change; it should not approve commercial or risk consequences. The exit forum can report a threatened schedule; it should not rewrite scope.
Build a decision-rights register before the first review
The core artifact is a decision-rights register. For each recurring or reserved decision, record who recommends, decides, executes, must be consulted, and informed. Add evidence and an escalation clock.
| Decision | Accountable owner | Evidence | Route if unresolved |
|---|---|---|---|
| Keep service within baseline | Buyer service owner | Scorecard, incidents, capacity | Service forum, then steering if continuity is at risk |
| Approve an in-baseline change | Buyer service owner | Service, security, data, cost, exit impact | Change queue with a dated decision |
| Approve an exception | Affected business or control-risk owner | Residual risk, control, cost, expiry | Risk forum or steering |
| Accept extension or scope increase | Buyer executive with budget and value accountability | Exit evidence, options, cost, value timing | Steering before notice or commitment |
| Approve an exit gate | Buyer transition owner with business and control sign-off | Tests, reconciliations, support rehearsal, fallback | Transition forum; never the calendar alone |
| Resolve a commercial dispute | Buyer contract owner | Clause, invoice, service evidence, cash impact | Contract clock, then steering |
The register should identify decisions requiring both parties. The seller may control a production change, but the buyer approves when it alters a critical interface, data retention, or exit capacity. The buyer may control target-state design, but the seller confirms it stays within service obligations.
Do not write “jointly owned” as the final answer. Name one accountable owner; list the other party’s consent, veto, or consultation right only where required.
Reserve the decisions that move cost, control, or value
Reserve any operational decision that changes transaction economics. Include these topics in the charter and agreement.
Service boundary. Adding an entity, site, user group, interface, environment, data set, or support activity changes the service unit. Show whether it is temporary, an exit dependency, or permanent. Buyer service and finance owners approve budget; the seller confirms capacity and impact.
Access and control. Administrative access, service accounts, certificates, logs, privileged roles, and security tooling determine who can operate and evidence the service. Neither party should alter a required path without the control owner and an approved change plan.
Data use and extraction. A report request can become a data-transfer decision. Define request and approval owners, fields, reconciliation, and end of access. Historical data required for reporting, audit, customer service, or migration belongs in an exit decision, not an unpriced request.
Risk acceptance. A workaround needs a business owner who understands the consequence, a compensating control, and an end condition. Privacy, cyber, financial reporting, payroll, customer, and regulatory exceptions need the relevant control owner.
Exit and value timing. A change that consumes seller capacity, delays a migration test, or moves the TSA end date can move when a benefit is counted. Finance joins when cash, run-rate cost, stranded cost, or a value-gate date changes. Transition owns evidence; finance owns the model consequence.
Make change control a decision filter
Change control fails when every request uses the same path. A password reset should not receive the same treatment as a new interface, and a new interface should not hide in an “enhancement” queue. Use three classes:
- Standard changes stay inside the boundary, use an approved procedure, and do not alter security, data, service levels, cost, or exit evidence. The service owner authorizes.
- Exception changes alter scope, access, data, support effort, cost, risk, or an exit dependency. They need an impact note, approver, funding, test plan, and updated decision or risk record.
- Emergency changes protect continuity, security, or legal obligations when normal approval would increase harm. The executing owner acts under procedure, then records and reviews the change.
Every exception request should answer six questions: required outcome; baseline change; executor; failure mode; payer; and exit impact. Without the last two answers, it is not ready for approval.
The change log should distinguish approval from implementation. Record test completion, production date, incident impact, updated documentation, and any altered exit gate. Approval is not evidence that the new service works.
Make risk acceptance expire
Every accepted TSA risk should contain:
- the affected service, process, data, or control
- the failure mode, business consequence, safeguards, and residual exposure
- the accountable risk owner and action that reduces or removes exposure
- the review date or event that ends acceptance
- the fallback if the action or exit gate fails
The risk owner can accept the consequence, unlike the person who maintains the register. For payroll, it is the HR or finance control owner; for privileged access, the security executive; for exit delay, the buyer executive who can fund or move the value date.
Use a hard rule: if an accepted risk passes its review date without new evidence, it returns to the decision queue. Silence is not renewal. If the parties disagree on severity, record both assessments and escalate according to consequence, not an average score.
Use escalation clocks that preserve service continuity
An escalation clock states when an issue changes forum. It prevents a decision from waiting behind routine administration.
Use impact-based rules. A failure affecting a critical transaction, payroll, security control, or close process enters the urgent route with named buyer and seller incident leads. An issue without a recovery path moves to service review. If it threatens an exit gate, notify transition at once, even when the SLA remains green.
For decisions, set clocks in the charter:
- the request owner acknowledges the request within one business day
- the forum decides or names missing evidence within its review window
- a decision that can move cost, risk, or the exit date reaches steering before a notice or milestone is missed
- a dispute unresolved after the contract period follows the executive route while the parties maintain the last safe instruction
A commercial disagreement should not become an outage. Define the instruction that remains in force, the emergency authority, and how incremental work is logged. Neither party should use a dispute to create unilateral scope or suspend a critical service.
Move information at decision speed
Governance quality depends on decision-ready information before the meeting. Keep one controlled set of records:
Service scorecard. Show volume, service levels, incidents, aged requests, capacity constraints, security events, invoices, and dependencies. Include the decision requested for each miss.
Change and exception log. Show class, approver, implementation date, test evidence, cost, and exit impact. Approved changes stay visible.
Decision log. Record the decision, alternatives, owner, conditions, actions, and review or expiry date. Link it to the service and contract schedule.
Risk and dependency ledger. Connect each risk to a service, owner, control, exit gate, and fallback. A risk without an action is an observation.
Cost and value bridge. Reconcile invoices and variable work to baseline. Show buyer run cost, exit work, extension exposure, and dependent value gates. Finance signs changes.
Publish the pack before the forum and mark decision items. The meeting should not be the first notice of a scope request or exit failure. Record disputed facts and evidence.
Design meetings around decisions
Use the fewest forums that cover distinct accountabilities. Each needs a purpose, threshold, and output.
| Forum | Purpose | Core participants | Output |
|---|---|---|---|
| Service operations review | Keep services stable and visible | Buyer/seller service owners, operations, TSA manager | Actions, incident decisions, exceptions |
| Transition and exit review | Prove replacement readiness | Transition, technology, business, security, finance | Exit gates, wave changes, fallbacks |
| Change and risk review | Approve non-standard changes and exposure | Change, control, finance, service owners | Change decision, risk acceptance, expiry |
| Executive steering | Decide trade-offs affecting scope, cash, risk, value, or contract | Buyer/seller executives, deal lead, finance, legal as needed | Binding decision or revised posture |
The TSA manager coordinates forums, prepares the pack, maintains the decision log, and checks that actions close. It should not approve scope, accept cyber risk, move a value date, and authorize extensions; that would make a coordinator an unreviewed executive authority.
Keep attendance proportional to the decision. Invite legal for contract interpretation or a change in rights, and business owners when continuity or value is at stake. Prepared decisions beat large calls with no authority.
Keep cost and value ownership visible
Cost ownership is ambiguous when the seller controls delivery and the business requests changes. Assign it by consequence:
- the seller service owner owns delivery effort, performance, and evidence of work
- the buyer service owner owns process adequacy and whether requested work is necessary
- finance owns baseline reconciliation, funding, and the model effect of extensions or changed value dates
- the transition owner owns exit evidence and critical-path status; the executive sponsor owns trade-offs among continuity, cash, risk, and speed
This prevents treating an extension as administrative. If a service cannot exit, compare continuation, accelerated build, alternative provider, narrower scope, manual fallback, and delayed value. The service forum supplies facts; executives choose.
Plan governance exit from the start
Temporary governance survives the TSA when nobody defines how it ends. That creates duplicate approvals and a permanent escalation habit.
Define governance exit conditions alongside service exit conditions. A forum can close when the replacement owner accepts the service, support and incident routes operate under the buyer’s model, data transfers, risks have business-as-usual owners, invoices reconcile, and disputes have a contract route. The calendar date alone is not enough.
Close forums as services exit. Transfer decisions, risks, dependencies, and exceptions to receiving owners. Preserve the audit trail, but remove TSA-only approvals once the buyer has control. Keep one route for residual commercial issues if needed.
The charter should state what happens if exit fails. Transition recommends the fallback, finance updates value timing and cost, executives approve the posture, and service operations follows the new instruction. This keeps an exit failure from becoming an unowned gap.
Decision triggers for the governance team
- If the seller can change a service but the buyer bears its cost, risk, or value impact, reserve the decision or require buyer approval.
- If a service is within SLA but an exit gate is failing, move the item to the transition forum immediately; service performance is not exit readiness.
- If a change alters data use, privileged access, control evidence, or the critical path, classify it as an exception even if the technical effort is small.
- If an accepted risk has no accountable owner or expiry event, return it to the risk decision queue.
- If a dispute approaches a contractual notice or exit milestone, escalate before the date and preserve the last safe instruction.
- If the cost bridge changes without a decision log entry, or a forum repeatedly reports actions without deciding, stop the review, identify the named owner, and escalate the missing authority.
- If the buyer cannot identify the receiving owner for an exiting service, the service is not ready to leave and the governance plan must fund or assign that capability.
Install the governance operating system
The buyer TSA owner should convene transition, buyer and seller service owners, finance, security, business owners, procurement, and legal. Produce five artifacts:
- a governance charter with forums, thresholds, quorum, escalation clocks, and the last-safe-instruction rule
- a decision-rights register covering service, change, risk, commercial, data, and exit decisions
- a baseline scorecard plus change, exception, risk, and decision logs with owners and expiry fields
- a cost-and-value bridge showing TSA consumption, buyer run cost, extension exposure, and value gates
- a governance-exit checklist linked to each service exit wave
Then run one tabletop decision. Pick a change affecting a critical service or exit date and identify evidence, owner, consents, funding, fallback, and escalation deadline. If the group needs a new meeting to decide, the rights register is incomplete.
TSA governance works when it reduces ambiguity every week. The seller knows what it must deliver, the buyer what it owns, the business which trade-offs it can accept, and finance when cost or value moves. Governance then becomes the mechanism that gets the business safely out of the TSA.