Managed SOC Statement of Work: The Response Authority Clause Nobody Writes Down
A managed SOC statement of work should name in writing what the provider may do when an alert fires: which actions it can take in your environment without a call, which require your approval, who may authorize them, and what to do at 3 a.m. when no one answers. Without those clauses, you have bought monitoring, not response.
The onboarding call usually covers everything a buyer can see. Coverage hours, rule counts, which integrations connect, what the monthly report looks like, where the logs are hosted. In our onboarding reviews, the question that almost never comes up is the one that decides everything after 10 p.m.: when an alert fires and no one is at the desk, who is allowed to do anything about it? A managed SOC statement of work is where that decision gets written down, and in most of the contracts we see, it does not get written down at all.
The stakes are current. CISA added a chain of four Plex Media Server vulnerabilities to its Known Exploited Vulnerabilities catalog on October 20, 2026, including a server-side request forgery an attacker can steer at their own destination, with a federal due date as close as October 23, 2026 [1]. The catalog now holds 1,754 entries, and CISA's own guidance is that it should feed prioritization directly [1]. IBM's 2026 Cost of a Data Breach report puts the mean time from detection to containment at 247 days [4]. And on the detection side, Picus's Blue Report 2026 found that 58 percent of simulated attacker actions were logged while only 14 percent generated an alert [8]. A contract that does not say who may act, and when, will spend all of that time waiting for a phone call.
Clone Systems' position: a managed SOC contract that does not put response authority in writing is a monitoring service, not a response service. The SOW must name the actions the provider may take without a call, the actions that require approval, the people who may approve, and what happens when nobody answers. Every clause in this post exists to force that sentence into the document before the signature.
What Does a Managed SOC Statement of Work Actually Need to Say?
It needs to map every phase of the incident lifecycle to a named actor and a written limit on what that actor may do. NIST SP 800-61 Rev 3, the current Computer Security Incident Handling Guide, organizes incident handling into preparation, detection and analysis, containment, eradication and recovery, and post-incident activity [2]. An SOW that prices only the detection and analysis phase has sold a monitoring product and labeled it a response service.
The six decision areas the SOW must settle:
| Decision area | What the SOW should say | What "not written" looks like |
|---|---|---|
| Pre-authorized actions | A written list: isolate a host, block an IP or domain, disable an account, reset a credential | "Incident response included," with no list |
| Approval-required actions | Which actions need your sign-off, plus a timeout for the approval | The provider calls, and waits |
| Authorizers | Named roles with backups on both sides, not job titles alone | "Our security lead" and "your IT manager" |
| Escalation | Who gets paged, in what order, and what happens at the third no-answer | A phone tree that lives in one email |
| Prohibited actions | What the provider may not touch: production data, business-critical systems, deletion | Nothing assumed, everything improvised |
| Evidence and handoff | What is logged, in what format, and what the post-incident package contains | A report the next vendor cannot use |
Each row is a question you can ask on a sales call. If the answer is "it depends on the situation," the situation has already happened, and it is not documented.
Why Do Most Managed SOC Contracts Leave Response Authority Blank?
Because they are written by procurement, not by the operators who will be making the calls. The vendor's deck sells "24/7 incident response," the buyer's template has a line for it, and nobody on either side translates the phrase into a sentence that says who may isolate a host at 3 a.m.
The vendor has an incentive to stay vague. Broad authority creates liability; narrow authority keeps the incident bill small. The buyer has the mirror image: they want the provider to act, but asking for written pre-authorization feels like asking for a waiver of responsibility, so the request never gets made. The result is a contract where both sides assume the other side will handle the 3 a.m. call.
In onboarding reviews, we consistently find the same pattern: the first serious question about response authority arrives after the first incident, not before the signature. By then the SOW is signed, the price is locked, and the fix has become a scope change. That gap has a cost curve. IBM's 2026 report puts the mean time from detection to containment at 247 days [4], and CISA's KEV due dates, now as short as three days for an actively exploited flaw [1], assume someone with authority can act inside that window. If the authority is not written down, the window belongs to the attacker.
What Are the Six Decisions a Managed SOC SOW Must Settle?
This is the part to put in the RFP before any vendor demo. The Clone Systems 6-Point SOC Response Authority Check:
- A written list of pre-authorized actions. Isolate, block, disable, reset, contain: each one named, each one limited to the systems it may apply to. "Any action necessary" is not a list, and it will not be your friend at 3 a.m.
- An approval timeout with a default. If an action needs your approval and no one answers within a written window, 60 minutes is a reasonable number to propose, the SOW says what happens next: escalate, hold, or proceed on the pre-authorized list only.
- Named authorizers with backups. A role on each side plus a named backup. A contract that says "our security lead" has no answer when the security lead is on vacation, which is exactly when the incident arrives.
- An escalation path with consequences. Who gets paged, in what order, what happens at the third no-answer, and who makes the call to pull in leadership. Escalation is either a path with timestamps or it is a phone tree in someone's head.
- A written list of prohibited actions. What the provider may not do without explicit instruction: touch production data, shut down business-critical systems, delete anything, or make changes outside the incident. The prohibition list protects the customer, not the vendor.
- An evidence and offboarding clause. What gets logged for every action taken, in what format, and what the post-incident package contains. And the line nobody writes: the detection rules, tuning, and coverage map the provider built for your environment return to you if you leave. When a managed SOC offboards, the detection library leaves with the vendor. The logs come back; the detection does not, and coverage takes months to rebuild.
Read your own SOW right now. Find the sentence that names who may isolate a host. If you cannot find it in two minutes, it is not in the document, and the decision will be made live, under pressure, by whoever answers the phone first.
How Is Managed SOC Response Authority Different From MDR or EDR?
The difference is what the contract assumes you are buying. An EDR contract sells agents and a console: the actions are yours to take, and the vendor's job is to show you the evidence. An MDR contract typically sells triage and alerting, with containment and response often an add-on, a higher service tier, or a call that starts the clock. A managed SOC contract sells the whole loop, detection through response through reporting, but only if the authority for the response half is written down.
That is why the comparison that matters in an RFP is not "MDR versus managed SOC." It is "what does your statement of work authorize at 3 a.m.?" The service pages say everyone responds. The statements of work are where the answers differ. Clone Systems runs its model with the authority explicit by design: no action is taken in a customer environment until an incident is confirmed, containment is initiated from the console once it is confirmed, and AI-drafted response steps are previewed and need a human to approve them before anything runs [5]. A design statement only works because the matching limits are written into the engagement instead of left to habit.
If you are evaluating providers on the coverage side as well, the seven-question rubric in how to choose a managed SOC provider [7] is the first half of the same evaluation, and SIEM alert tuning: what your SOC turned off [9] covers the detection-coverage half.
If the 3 a.m. question is the one keeping you up, start with a scoping call. Clone Systems' Managed SOC + SIEM runs the loop with the response authority written into the engagement, and the managed SOC pricing page shows what the full service covers before you ask for a quote.
What Do the Standards Say About the Authority Gap?
More than your contract says. NIST SP 800-61 Rev 3 expects an organization to be able to contain, eradicate, and recover from incidents, which for a managed customer means the chain of authority from detection to action has to cross the vendor boundary without breaking [2]. CISA's KEV catalog is explicit that organizations should use it as an input to vulnerability management prioritization, and BOD 26-04 ties mitigation deadlines to the risk of the vulnerability rather than to any patch cycle [1][3]. For a managed customer, the translation is contractual: if the SOW cannot show which actions are pre-authorized against a KEV-matched alert, the deadline lands on you whether the contract says so or not.
For customers carrying a PCI DSS obligation, the standard is a baseline of technical and operational requirements for protecting payment account data [6]. It does not write your vendor contract, and an assessor will not read it either. The expectation that response authority exists is yours to enforce in writing, because nothing else will.
How Clone Systems Can Help
- The response authority clause, written. We put the pre-authorization list, the approval timeout, the named authorizers, and the prohibited-actions list into the engagement before go-live, not after the first incident. Managed SOC + SIEM.
- Containment that is explicit by design. No action before confirmation, containment from the console, and AI-drafted steps previewed for a human before they run [5].
- Detection that stays with you. The offboarding handoff, detection rules, tuning, and the coverage map, is a contract line, and the same standard applies across the managed SIEM + EDR stack.
- The 6-Point Check on your current contract. Bring us the SOW and we will run the check line by line. Talk to our team.
Frequently Asked Questions
What should a managed SOC contract include? It should name the coverage in writing, and then settle the response authority: which actions the provider may take without approval, which require yours, who may approve, and what happens when no one answers. The sales deck sells the capability; the statement of work is where the authority lives.
What is the difference between a managed SOC and MDR? An MDR service typically sells triage and alerting, with containment often an add-on tier, while a managed SOC sells detection through response as one service. The practical test is the contract: read what each one authorizes the provider to do at 3 a.m.
Can a managed SOC isolate a host without calling us first? Only if the statement of work pre-authorizes it in writing, and most statements of work do not. The answer you want is a named list of pre-authorized actions, not a default of calling and waiting.
How fast should a managed SOC respond to a critical alert? The SOW should state response and containment targets in minutes for critical alerts, and the numbers should be tested, not just promised. A vendor who will not write a number down will not hit one.
What happens when a managed SOC provider leaves? By default, the logs come back and the detection library does not, so coverage drops until it is rebuilt. An offboarding clause should name the return of detection rules, tuning, and the coverage map before you sign.
Conclusion
The onboarding call will cover hours, rules, integrations, and reports. The clause that decides the outcome of every incident after 10 p.m. is the one that never gets discussed, because it sounds like legal detail and works like a life-support system. Put the six decisions in writing before the signature: the pre-authorized actions, the approval timeout, the named authorizers, the escalation path, the prohibited actions, and the offboarding handoff.
If your current contract cannot answer who may act at 3 a.m., the fix is a page, not a platform. Contact Clone Systems and we will run the 6-Point SOC Response Authority Check on your statement of work before the next incident finds the gap.
References
[1] CISA, Known Exploited Vulnerabilities (KEV) Catalog, accessed October 22, 2026. Catalog listed 1,754 entries; additions of October 20, 2026 include the chained Plex Media Server flaws (CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, CVE-2026-96656, with due dates of October 23 and November 3, 2026) and CVE-2026-110936 (Siemens Software Center, due November 3, 2026). https://www.cisa.gov/known-exploited-vulnerabilities-catalog [2] NIST, SP 800-61 Rev 3, Computer Security Incident Handling Guide (April 2025), superseding Rev 2 (withdrawn April 3, 2025). https://csrc.nist.gov/pubs/sp/800/61/r3/final [3] CISA, BOD 26-04: Prioritizing Security Updates Based on Risk. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk [4] IBM, The Cost of a Data Breach Report 2026 (publisher landing page; full report is a PDF, 247-day mean time to detect and contain from the report summary). https://www.ibm.com/reports/data-breach [5] Clone Systems, Managed SOC + SIEM with AI (service page, retrieved October 22, 2026). https://www.clone-systems.com/managed-soc-service [6] PCI Security Standards Council, PCI DSS standard overview, retrieved October 22, 2026. https://www.pcisecuritystandards.org/standards/pci-dss/ [7] Clone Systems, How to Choose a Managed SOC Provider: The 7 Questions That Separate Coverage From Capability. https://www.clone-systems.com/blog/how-to-choose-a-managed-soc-provider [8] Picus Security, Blue Report 2026 (figures as cited in the Clone Systems post "SIEM Alert Tuning: What Did Your SOC Actually Turn Off?", published 2026-10-12). [9] Clone Systems, SIEM Alert Tuning: What Did Your SOC Actually Turn Off? https://www.clone-systems.com/blog/siem-alert-tuning-what-your-soc-turned-off