Choosing a Managed SOC Provider: Where the SLA Clock Starts

The short answer

A managed SOC provider's response-time number tells you less than the three definitions behind it: which event starts the clock, what counts as a "response," and what the provider is allowed to do without your sign-off. Compare providers on those, because two contracts quoting an identical figure can promise very different outcomes during a real incident.

Who this is for

This is written for the CISO, head of security, or technology lead at a casino, crypto exchange, or fintech who has two or three managed SOC proposals on the table and finds the SLA tables look alike. It assumes you've already settled the model question; if not, SOC vs MDR vs SIEM covers that choice, and 24/7 SOC coverage models for a crypto exchange covers staffing.

Clause 1: which event starts the clock

An SLA is a duration, and a duration needs a start. Proposals use at least four different starting points, and they are not interchangeable:

Clock starts when...	What it ignores
The malicious activity happened	Nothing: this is the only start that measures real exposure
The data reached the provider's platform	Any delay in your log forwarding
The detection rule fired and created an alert	The time before a rule matched, which is where most of the real delay sits
A human analyst picked up the ticket	Queue time, so a backlog never counts against the SLA

Most commercial SLAs start at the third or fourth row. That is not dishonest, since providers can only measure what their platform sees. But it means the SLA covers the provider's handling time and says nothing about detection delay. If a rule is too narrow to match an attack for hours, the clock has not started yet.

Ask which start each metric uses, in writing. Then ask what the provider does to measure and report the gap between event time and alert time, because that gap is where the money is lost.

Clause 2: what "response" means

"Response within N minutes" can be satisfied by four different things:

1. Acknowledge. An automated message or ticket exists. No human judgment needed.
2. Triage. An analyst has decided whether the alert is real and assigned a severity.
3. Notify. A named person on your side has been told, through a channel that reaches them at 3 a.m.
4. Contain. The attacker's access has been restricted.

Only the last one reduces damage, and it is the one least often covered by a headline SLA. Ask for the SLA broken out by severity and by these four stages. A P1 with acknowledgement in minutes and no committed containment time is a promise to tell you about the problem quickly.

For casinos and exchanges the distinction is concrete. A suspicious withdrawal or a hijacked player account is an event where the cashier or withdrawal pipeline is the thing to contain, and that takes someone who can act on it, not only someone who can see it.

Clause 3: authority without a phone call

Containment needs authority, and authority has to be granted before the incident. The practical test is a short list you can read aloud:

• Pre-authorized: isolate a single endpoint, disable a single user account, block an indicator at the edge. Reversible and low-regret.
• Approval required: anything that can interrupt payments, trading, or customer sessions at scale.
• Never delegated: legal notifications and regulator contact, which stay with you.

If the contract has no such list, the provider's default is to notify and wait, and the clock you were promised ends at the notification. The reverse failure also exists: broad "may take any action" language with no limits is a liability on your side when an analyst isolates a payment server on a false positive. Specific beats generous in both directions.

This is also where the SOC hands off to incident response. A confirmed P1 should name an escalation path into an Incident Response team with forensic and legal authority; see what has to be signed on the IR side before that handoff happens.

Clause 4: what happens when a log source goes quiet

A SOC detects on data it receives. If a firewall's log forwarder fails or a cloud account's audit trail is switched off, detection in that area drops to zero, and every dashboard the provider sends you can still look healthy because nothing is firing.

Contracts rarely say who owns this. Ask for three things:

1. Silence from an expected source is itself an alert, with a defined maximum quiet period per source.
2. A named owner on each side for restoring the feed.
3. A scheduled coverage review that lists what is onboarded against what you run, rather than what was onboarded at kickoff. Defining log sources and boundaries before onboarding is the part of the engagement that decides this.

Clause 5: the reporting you can actually audit

The final test is whether the provider's evidence would hold up if you had to explain an incident to a regulator or a board. Ask to see, with client details removed:

• A sample escalation ticket, showing who was contacted and when.
• A sample monthly report, to see whether it shows detection gaps or only alert counts.
• A recent incident timeline with each timestamp labeled by the clock definitions above.

A provider who can produce these has already done the work this article describes. A provider who answers with a brochure is telling you something too.

Limitations

This is a guide to reading contracts, not a ranking of providers, and it does not claim any provider's actual response times. It does not replace legal review of the agreement, and the right authority list depends on your own architecture and risk appetite. A well-written SLA does not make detection good; it only makes the provider's obligations legible. Detection quality is tested by exercise, not by clause.

What to do next

If you have proposals in hand, run each one through the clauses above and put the answers in a side-by-side table; the differences usually show up in minutes. If you want a second reader on what a given scope will and won't cover for your stack, request a coverage review and bring the draft SLA.

Frequently asked questions

What should I compare when choosing a managed SOC provider? Compare what the contract lets the provider count as done, not the headline response number. Four clauses decide it: which event starts the clock, what "response" means (acknowledge, triage, or contain), what the provider is authorized to do without calling you, and how the contract treats log sources that stop sending data.

What is the difference between time to acknowledge and time to contain? Time to acknowledge is how long until someone confirms the alert exists, which an automated ticket can satisfy. Time to contain is how long until the attacker's access is actually restricted, which requires someone with authority and a runbook.

Should a managed SOC be allowed to take containment actions on its own? For a defined short list, yes: reversible, low-regret actions such as isolating one endpoint or disabling one account. Anything that could interrupt payments or trading should need your approval.

Who is responsible if a log source silently stops sending data? The contract decides, and many leave it unstated. Ask for a clause that makes a silent source an alertable event with a named owner on both sides.

Can I verify a SOC provider's claims before signing? Partly. Ask for a sample escalation ticket, a sample monthly report, and a walkthrough of a recent incident timeline. Detection claims can be tested with an authorized exercise against your own environment.

Sources and review

This article is a contract-reading framework drawn from AnySec Engineering's own practice; it cites no external statistics and no AnySec-original numbers, case results, or SLA figures. Author: AnySec Engineering. Published 2026-10-01; last reviewed 2026-10-01.

---

Related reading

• SOC vs MDR vs SIEM for iGaming — the operating-model decision that comes before comparing providers' SLAs.
• 24/7 SOC coverage models for a crypto exchange — how the staffing model behind a provider changes who actually answers at 3 a.m.
• Managed SOC for iGaming — the onboarding checklist that fixes log sources and response boundaries before the first incident.
• Incident response retainers for online casinos — what the escalation path out of the SOC has to contain.