What SLA should you expect from a managed SOC?
Coverage hours, triage and alerting times, incident response mobilisation, reporting and exit terms: the commitments a managed SOC SLA should put in writing.
A managed SOC SLA usefully covers measurable timings and resources: coverage hours, time to triage an alert, time to notify the client, time to mobilise incident responders, reporting frequency and exit terms. Each timing should be defined per severity level. No regulation sets standard values, so these are yours to negotiate.
This article expands on one of the criteria in our guide How to choose a SOC provider.
Why a SOC SLA differs from a standard managed services SLA
Managed services SLAs usually measure service availability or ticket resolution time. A SOC does not “resolve” an attack the way you replace a failed disk. Its work happens in stages: detect, triage, alert, contain, support remediation. Each stage needs its own commitment. Otherwise a single overall figure hides what matters most: how long it takes between the first signal and someone taking action.
Seven commitments to ask for
| Commitment | What it measures | Question to ask |
|---|---|---|
| Coverage hours | When analysts are actually watching | At night and at weekends, who looks at alerts? |
| Time to acknowledge | Time from alert to start of human analysis | Does it vary by severity? |
| Time to triage | Time to decide whether an alert is a real incident | How is severity defined? |
| Time to notify the client | Time to reach the right contact through the right channel | Who do you call, and what if they do not answer? |
| Containment actions | What the SOC can do alone (isolate a device, disable an account) | Which actions are pre-approved? |
| Incident response mobilisation | Time to engage a response team | Is it included, or quoted separately? |
| Reporting and reviews | How often you get reports, and what they contain | Which metrics will you show me each month? |
Timings per severity level
One timing for every alert makes little sense. A critical alert (compromised admin account, encryption in progress) needs an immediate reaction; a low-severity alert can wait for the next review. Ask for a written grid: three or four levels, a definition for each and a timing for each stage. In France, ANSSI’s PDIS framework for qualifying detection providers is a useful reference for structuring this discussion. See Should you require a PDIS-qualified detection provider?.
Pre-approved actions
A fast alert is worthless if the SOC must wait for approval to isolate a laptop at 3am. The SLA, or its operational annex, usually lists what the SOC may do without prior sign-off and what needs the client’s or the MSP’s approval. See How to build a SOC escalation procedure.
What an SLA cannot promise
No SOC offer can promise that no attack will ever get through. A serious SLA covers vigilance, responsiveness and quality of analysis, not outcomes. Be wary of very short timings quoted without a definition: a response time expressed in minutes may refer to an automated acknowledgement, not human analysis. Always ask what exactly the figure measures.
Clauses around the SLA
- Measurement and evidence: how are timings timestamped, and can you check them in the console or reports?
- Regular reviews: a recurring meeting on metrics, incidents and tuned detection rules.
- Data retention: how long logs are kept and where they are hosted.
- Reversibility: return of data and configurations when the contract ends.
- Onboarding: time to go live and the false positive tuning period.
How it ties in with regulatory deadlines
For entities in scope of NIS2, Article 23 of the directive provides for an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report within one month. The text addresses the regulated entity, not its SOC provider. But they are only achievable if the SOC detects quickly and supplies the facts fast. Check that the SLA’s notification timing leaves your client real room to report. See Does a managed SOC help with NIS2?.
How Cyna approaches it
Cyna’s SOC runs 24/7 from France with in-house teams, with a human analyst on every alert, and works with Cyna’s CERT. Service levels and terms (scope, licences) are set out in the contract signed with the partner MSP. The incident response on-call team is available 24/7 from the Report an incident page. Monthly activity and vulnerability reports can be exported under the MSP’s own brand, so MSPs can track their own commitments to their clients.
Talk to an expert
Drafting requirements or a contract for a managed SOC? If you already work with a Cyna partner, they are your first point of contact for building the right commitments. Otherwise, get in touch.
Frequently asked questions
Is there a standard response time for a SOC?
No. No regulation sets a universal response time for a commercial SOC. Timings are negotiated by severity and client context. The regulatory deadlines that do exist apply to the regulated entity's incident reporting, such as the NIS2 24-hour early warning.
Can a SOC guarantee that no attack will succeed?
No, and an offer that promises this should raise concern. A SOC SLA covers means and timings: monitor, triage, alert, contain. See Red flags in a managed SOC offer.
What if the provider misses its commitments?
Contracts generally address how timings are measured, how often metrics are reviewed and what follows a shortfall: an action plan, possible service credits, exit with data returned. Drafting those clauses is a matter for your legal adviser.
Who signs the SLA when an MSP is involved?
In an MSP distribution model, the MSP generally holds the contract with its client, building on the terms agreed with its partner SOC.
This article provides general information for guidance only. It is neither legal advice nor a contractual commitment from Cyna: service terms are those of the contract agreed through your partner MSP. For any regulatory question, consult your legal adviser.