The bill that arrives at the exit

Most outsourcing decisions get judged on what the service does while it runs: coverage hours, response times, alert quality. The liability builds somewhere else, in everything the provider learns and holds that the customer never takes back.

The big picture: Every month a provider runs part of your SOC, two things accumulate on its side of the line. The first is knowledge: which service accounts are noisy, which executive travels every quarter, which alerts the finance team triggers at month-end. The second is artifacts: tuned detections, suppression rules, baselines, playbooks, and case history, often stored in the provider's tenant and written in the provider's query language. Neither shows up on an invoice. Both determine whether you can change providers, bring work in-house, or survive the provider being acquired without losing coverage.

Why it matters: The first post in this series priced the three operating models. The second argued for renting the engineering and keeping the judgment. This post covers what happens when the line lands in the wrong place, and why the question is getting urgent. Gartner's 2026 MDR research says advances in AI SOC agents are increasing internal competition for traditional MDR services, and that more organizations will consider insourcing MDR functions as those tools mature, according to Intezer's summary of the note. A lot of security teams are about to test their exit for the first time.

By the numbers:

Gartner's guidance on contract exit terms says they matter more for SaaS, AI, and agentic AI services than for older software because those services integrate more deeply and rely more on proprietary data and models. It tells buyers to define IP and data ownership in the contract and to guarantee data extraction and deletion rights, per the public abstract of the research.
Detection logic migration consumes 40% to 60% of total engineering effort in a SIEM change, and around 70% of SIEM modernization projects underdeliver or fail outright, according to Abstract Security's analysis as summarized by NHIMG.
35% of organizations that evaluated a SIEM replacement stayed with their current vendor because migration risk was too high, according to IDC's 2024 Worldwide Views of SIEM Survey as cited by SenseOn.
In the SANS 2025 SOC Survey, only 28 of 438 respondents fully outsource incident response, compared with 183 of 433 who fully outsource penetration testing. That works out to about 6% versus 42%, our calculation from the published counts. Organizations keep the function where business context matters most.
The same survey found that 31% of SOC staff stay three to five years and only 4% stay 10 years or more. Knowledge of an environment walks out the door on a schedule even when every analyst is internal.
Only 37% of enterprise MDR customers say their provider's analysts consistently deliver high-quality analysis, per IDC's 2026 MarketScape for enterprise MDR. IDC tells buyers signing multiyear contracts to build in checkpoints, such as renewal terms and capability audits, so they are not locked into today's baseline for the life of the agreement.

Three ways outsourcing turns into a liability

1. The knowledge accrues to the provider

Every investigation teaches something about the environment it happened in. When a provider runs the investigation, the provider's analysts learn it. Command Zero CTO Dean De Beer describes the mechanism in The Recomposition of Security Work: the pattern recognition senior analysts rely on "cannot be compressed into documentation, transferred through training programs, or inherited from a vendor's playbook."

The provider side has its own problem. The feedback loop that turns exposure into expertise breaks when escalations cross company boundaries. De Beer notes that a provider's Tier 1 analyst rarely learns what happened to the case they handed off. So the knowledge forms on the provider's side, in a degraded form, and stays there. When the contract ends, the customer gets the tickets back. The reasoning behind them, the dead ends, and the "we've seen this before" stay with whoever worked them, and often that analyst has already moved to another account.

2. The artifacts live in someone else's tenant

The second form of lock-in is concrete enough to inventory. Detections tuned against your noise. Suppression lists that took a year to get right. Asset criticality tags, VIP lists, service account baselines. Case notes and dispositions that show how similar alerts were resolved in the past.

When an outsourced SOC owns those artifacts in its own environment, the customer loses direct control of the detection layer. NHIMG's analysis of Abstract Security's work calls this MSSP tenant lock-in: switching providers means recovering rule ownership, baselines, and operating knowledge from an environment that was never designed for an easy exit. Even raw log export doesn't solve it, because detection logic written in a vendor-specific query language has to be rebuilt and revalidated before it works anywhere else. A migration can look healthy, with logs flowing and dashboards populated, while detection fidelity quietly degrades underneath.

3. The contract decides what you can take with you

The third form is contractual, and it is where the first two either get fixed or get locked in. The questions that matter at exit are rarely the ones that get negotiated at signing:

Ownership of derived work. Detections, tuning, and playbooks built for your environment during the engagement. Are they yours, the provider's, or licensed content you lose at termination?
Return format and timing. A data return clause that delivers logs in a proprietary format, or deletes them 30 days after termination, protects the provider more than it protects you.
Derived data and model training. For AI-driven services, whether your telemetry and analyst feedback can be used to improve the provider's models, and whether those improvements leave with you or stay with them. This is the gap Gartner's exit-terms guidance points at.
Change of control. MDR is consolidating. IDC's MarketScape notes that Accenture expanded its delivery footprint through its March 2026 acquisition of CyberCX. When a provider changes owners mid-contract, its tooling, staffing, and terms can change with it.
Transition assistance. Whether the outgoing provider is obligated to run in parallel, hand over content, and answer questions during a cutover, and at what cost.

What you should own when the contract ends

The test of a healthy outsourcing arrangement is whether you could end it in 90 days without losing detection coverage. This table is a starting inventory.

Asset	Where it usually lives	Lock-in risk	What to require
Raw telemetry and logs	Provider SIEM or data lake, or your own	High if stored only in the provider's tenant	Customer-owned storage or guaranteed export in an open format, with retention you control
Detection rules and tuning	Provider tenant, provider query language	High; rebuilding is most of the migration effort	Export rights, detections stored as code in a portable format, version history
Suppressions, allowlists, baselines	Provider platform, often undocumented	High and easy to miss	Documented export of every suppression with its reason and owner
Case history and dispositions	Provider ticketing or portal	Medium to high	Full case export including evidence, reasoning, and verdict
Playbooks and custom investigative logic	Provider runbooks	Medium	Ownership of logic built for your environment, delivered in readable form
Environment context (asset criticality, VIPs, service accounts)	Provider analysts' heads and notes	High and invisible	A shared, customer-owned context store the provider writes to
Feedback used to train AI models	Provider models	Unclear in most contracts	Explicit terms on derived data, opt-outs, and what persists after exit

Two rows in that table are the expensive ones. Detections and tuning are expensive because rebuilding them is labor. Environment context is expensive because nobody wrote it down. A provider can hand back every rule it ever wrote and still leave with the knowledge of why each one exists.

Run the exit test before you need it

The cheapest time to find lock-in is while the relationship is healthy and the provider still wants to renew. A practical version of the test:

Tabletop the exit. Assume the contract ends in 90 days. List what you would lose, who would rebuild it, and how long detection coverage would be degraded. If nobody internal can answer, that is the finding.
Request a full export now. Ask for every detection, suppression, playbook, and a sample of closed cases with full evidence. See what format they arrive in and how long it takes. The answer during a renewal conversation is the best answer you will ever get.
Spot-check the reasoning. Pick ten closed cases and see whether your team can follow how each verdict was reached from the evidence provided. If the record is a verdict and a paragraph, the reasoning stayed with the provider.
Keep one internal owner per critical domain. Identity, endpoint, email, cloud. Someone on your payroll should understand each domain well enough to evaluate the provider's work in it, which is the only way to notice when quality drifts.
Write context down where you own it. Asset criticality, known-good behavior, executive travel patterns, business process exceptions. The provider can read and write to it. It stays when the provider goes.

This connects to the four-column test at the end of the hybrid models post: who does the work, who can see the reasoning, who decides, and who could take it over tomorrow. The exit test is how you find out whether the fourth column is true.

The same rules apply to AI SOC platforms

None of this is unique to human-staffed MDR. An AI SOC platform can create the same lock-in faster, because it can absorb more of the investigative work. If the platform stores your data in its own lake, encodes your detections in a format only it reads, and returns verdicts without the reasoning behind them, you have recreated MSSP tenant lock-in with better response times.

De Beer's research names the long-run version of this risk directly: organizations that automate their expertise become dependent on the vendors whose agents replaced it. When those agents fail against a novel attack, nobody internal can recognize the failure, diagnose it, or fix it.

The questions for an AI platform are the same ones in the table above, plus three more. Does it query data where it already lives, or does it require moving your data into its storage first? Can your team write and own the investigative logic the platform runs, and take it with you? Does every verdict come with the evidence and reasoning a human can audit? Command Zero built its platform around those three answers, querying customer data in place and letting teams bring their own questions and logic. That is also why we think buyers should ask every vendor, including us, to prove them.

What industry experts are saying

De Beer frames the outsourcing waves of the last 15 years as a warning for the AI wave. "The pipeline fragmented rather than vanished," he writes in The Recomposition of Security Work. "But from the perspective of the enterprise that outsourced, the developmental benefit moved to the vendor and the expertise gap remained with the organization." He extends that to procurement: executives who lack the capacity to verify autonomous systems "will make resource allocation decisions that look rational in the short term and catastrophic in hindsight."

Command Zero cofounder and CPO Alfred Huger makes the point that building in-house carries its own version of the liability. In Yes, Build Your Own AI SOC, he warns that teams have to survive the departure of the people who built the system: "When the two or three people who built the thing leave, an unmaintained AI SOC becomes a liability faster than almost any system you run." Lock-in can be to a provider, or to a handful of employees. Either way, the fix is the same: knowledge that lives in a system you own and can read.

IDC's 2026 MarketScape for enterprise MDR pushes buyers in the same direction on governance. It recommends a formal RACI that spells out which actions a provider takes on its own, which need customer authorization, and which the internal team keeps, along with shared investigation workbenches where both sides work the same case. A shared workbench is also an exit asset. Cases worked in a system you can see are cases you keep.

SANS survey author Christopher Crowley flags a related pressure that makes third-party arrangements harder to leave unexamined. In the SANS 2025 SOC Survey, he writes that SOCs should expect tough questions about third-party monitoring and data residency, and that these "aren't just technical issues."

The limits of the argument

Between the lines: Outsourcing is still the right call for many organizations. A team of three cannot staff a 24x7 seat, and a provider that delivers good coverage with clean exit terms is worth more than an internal SOC that exists only on paper. The liability described here is manageable when it is negotiated up front. It becomes a crisis only when nobody looks until the exit.

The data has limits too. The SIEM migration figures come from vendors that sell migration alternatives, relayed secondhand, and should be read as directional. The IDC SIEM survey figure also arrives secondhand through a vendor blog. The Gartner findings come from a public abstract and a vendor summary of the full note. The SANS percentages are our arithmetic on published counts. No independent study has measured the cost of exiting an MDR contract directly, so the argument rests on the structure of the arrangement and on practitioner experience more than on measured outcomes.

Command Zero has a stake here. We sell a platform that sits on the rented side of the line from part two, and a post about lock-in from a vendor deserves the same skepticism as any other. The exit test above applies to us as much as anyone.

The bottom line: Outsourcing becomes a liability when the provider ends up holding the two things you cannot buy back: your knowledge of what normal looks like and the detection logic built on top of it. Contracts can fix the second. Only an internal team that stays close to the work can fix the first. Before you sign or renew, find out what you would walk away with if the relationship ended in 90 days. If the answer is a pile of tickets and a log export nobody can read, you have already paid for the lock-in. You just haven't been billed yet.

Terms in this post

Terms defined in Command Zero's glossary are linked below. Terms without a glossary entry yet are defined here.

What is vendor lock-in in security operations?

Vendor lock-in in security operations is a dependency in which changing providers or platforms would cost so much time, money, or detection coverage that the organization effectively cannot leave, usually because data, detection logic, or operational knowledge lives with the vendor.

What is MSSP tenant lock-in?

MSSP tenant lock-in is a dependency in which an outsourced provider stores the customer's detection rules, baselines, and tuning inside the provider's own environment, so switching providers requires recovering or rebuilding that content.

What is detection portability?

Detection portability is the ability to move detection logic from one platform or provider to another while keeping its intent, tuning, and accuracy, typically by storing detections as version-controlled code in a vendor-neutral format.

What is detection-as-code?

Detection-as-code is the practice of writing, testing, and versioning detection rules the way software teams manage code, which makes them reviewable, testable, and easier to move between tools.

What is tacit knowledge in a SOC?

Tacit knowledge is the understanding analysts build through experience, such as knowing which alerts are routine for a given team or system, that is rarely written down and is easily lost when people or providers change.

What is a data return clause?

A data return clause is a contract provision that defines how, when, and in what format a provider must return a customer's data at the end of the relationship, and when the provider must delete its copies.

What is transition assistance?

Transition assistance is a contract obligation requiring an outgoing provider to support a handover to a new provider or internal team, which can include parallel running, content export, and answering questions during cutover.

Build vs. Buy vs. Co-Manage: When Outsourcing Becomes a Liability