The response-time SLA: what the number actually promises
Every retainer is sold on a number. The number is the least informative part of the commitment, because a response-time target is a sentence with a missing verb: it says when, and almost never says what. This guide reconstructs the missing half.
What the market actually publishes
Four providers, checked on 13 September 2026. Arctic Wolf publishes a one-hour response time. Mandiant publishes a two-hour response time in the event of a breach. Palo Alto Networks publishes that Unit 42 response SLAs “range from 24 hours to two hours, based on your selected retainer and service level”. CrowdStrike publishes 24/7/365 availability and experts who “deploy globally within hours”, without attaching a number.
Two conclusions follow. First, the published range across the market is one hour to one business day. Second, and more useful, the Unit 42 wording states out loud what the others imply: the target is a function of the tier you buy, not a property of the provider. Nobody is faster or slower in the abstract. You are choosing a price point.
What none of those four pages states is what has to have happened when the target expires. That is the term you have to extract yourself.
The verb problem
Consider four commitments, all of which could honestly be advertised as a one-hour response time.
- Within one hour, the provider acknowledges your call.
- Within one hour, a named incident lead is assigned and has read your declaration.
- Within one hour, a responder is on a bridge working with your team.
- Within one hour, the provider has begun pre-authorised containment actions on your systems.
The first is an auto-reply with a human attached. The fourth requires credentials, an access method, a written authority to act and a tested runbook, all arranged months earlier. Between them lies most of the price difference in the market, and buyers routinely compare the first against the fourth as though they were the same.
NIST gives you language for the second and third. In SP 800-61r3, subcategory RS.MA-02 covers triage and validation, recommending that an organisation “perform a preliminary review of a new incident report to verify that a cybersecurity incident has occurred, then estimate the severity of the incident and the level of urgency needed to respond to it”. That is a defensible definition of a triage commitment. Borrow it, and write it into the contract as the thing that must be complete by the target.
What starts the clock
The second missing term is the trigger. There are three candidates, and only one of them is acceptable.
| Trigger | Who controls it | Verdict |
|---|---|---|
| You declare on the agreed channel | You | The only trigger worth signing. Name the channel in the contract and test it. |
| The provider acknowledges the declaration | The provider | The provider controls its own clock. The target measures its answering speed, not its response speed. |
| The provider agrees the event qualifies | The provider | Worse still: the qualification decision is itself the work you are waiting for. |
Two related terms travel with the trigger. The first is the channel: one number or address, monitored continuously, whose use constitutes a declaration. The UK NCSC recommends that an incident response plan include “at least one conference number” that is always available for urgent incident calls, and that recommendation applies just as much to the provider side of the relationship.
The second is the fallback. If the incident has taken out your email and telephony, the declaration channel has to be reachable another way. NCSC advises considering “secure or alternative communications in event of a sensitive incident, or where normal channels are unavailable due to network/email/phone system outage”. That fallback has to be agreed and tested, because discovering it does not work is the sort of thing that happens at 04:00.
Triage or containment
This is the single largest scope decision inside the SLA, and it is worth stating plainly what each option costs you in preparation.
A triage commitment
The provider will, by the target, have reviewed what you sent, formed a view on whether this is an incident, estimated severity and told you what to do next. It requires nothing from you except the ability to describe what you are seeing. It is the cheaper commitment and, for many organisations, the correct one: an informed second opinion inside two hours is worth a great deal when your own team is unsure whether the alert is real.
A containment commitment
The provider will, by the target, be taking action on your systems. That requires, in advance: an access method that exists and has been tested; credentials or a break-glass process; a written statement of which actions the provider may take without asking; and a named person on your side whose absence does not block them.
NIST is explicit that these limits belong in writing. Third-party responsibilities “should be clearly defined in a contract”, including “information flows, coordination, and authority to act on behalf of the organization”, and the same passage names the restrictions worth recording, such as “making and implementing operational decisions (e.g., immediately deactivating certain services to contain an incident)”.
A containment target bought without that preparation is a target the provider cannot meet through no fault of its own, and you will have paid the premium for it anyway.
Coverage, calendar and the severity gate
Three smaller terms decide whether the target survives contact with reality.
- Coverage. Does the same numeric target apply at 03:00 on 1 January as at 10:00 on a Tuesday? Providers advertise 24/7 availability freely; the numeric commitment does not always follow it into the small hours.
- Calendar and timezone. Whose public holidays, and which timezone is the clock kept in? For an organisation operating across several countries this is not pedantry: it decides who is awake.
- The severity gate. Below which severity does the target not apply at all? This is the term most likely to be discovered during the incident rather than before it.
The severity gate has a regulatory analogue worth borrowing. Commission Implementing Regulation (EU) 2024/2690, which sets the technical requirements behind the NIS2 incident handling duty for the entity types it covers, requires assessment to be carried out “based on predefined criteria laid down in advance, and on a triage to determine prioritisation of incident containment and eradication”. Predefined and in advance are the operative words. If your duty manager cannot apply the severity definition at three in the morning without convening a meeting, it is not a definition.
The remedy, and why regulated buyers cannot skip it
A target with no consequence for missing it is a marketing claim. The usual remedies are a service credit, an escalation right, and a written miss report. The report matters more than the credit: a pattern of misses is a renewal argument, and only exists if each one produced a document.
For DORA financial entities this stops being a preference. Article 30(3)(a) requires that contractual arrangements for ICT services supporting critical or important functions include “full service level descriptions, including updates and revisions thereof with precise quantitative and qualitative performance targets within the agreed service levels to allow effective monitoring by the financial entity of ICT services and enable appropriate corrective actions to be taken, without undue delay, when agreed service levels are not met”.
Read that clause against a typical retainer SLA and two things follow. A commitment to use “commercially reasonable efforts” is not a quantitative target. And a target with no defined corrective action does not let you take one without undue delay. Both are contract defects before they are commercial ones.
Capacity: the term nobody writes down
Every published response time is implicitly a promise about the provider’s queue on a normal day. Mass-exploitation events against widely deployed products do not produce normal days. When one lands, a large share of a provider’s customer base declares within the same few hours, and the arithmetic of a fixed responder pool takes over.
ENISA describes the underlying prioritisation honestly from the responder’s side: in its worked example, contracted customers with a service level agreement receive priority one service, while the rest of the constituency receives a good-effort service with special care for the most severe cases. That is how a queue is actually managed, and it is the reason a retainer is worth having. It is also the reason to ask what happens when the priority-one queue itself is full.
Three questions get you an answer. Does my tier guarantee a position relative to other retained customers? What surge capacity exists, and is it the same people? Will you tell me within the target that you cannot start, rather than letting the target pass in silence? The third is the one that protects you, because a provider that reports a miss immediately leaves you time to call somebody else.
Pointing the target at the right clock
Choose the target from your statutory position rather than from the vendor’s tier list, because the deadlines are fixed and the tiers are negotiable.
| Regime | Deadline | Measured from |
|---|---|---|
| DORA, initial notification | Four hours | Classification of the incident as major, and in any case no later than 24 hours from becoming aware of it |
| NIS2, early warning | 24 hours | Becoming aware of a significant incident |
| NIS2, incident notification | 72 hours | Becoming aware of a significant incident |
| GDPR, Article 33 | 72 hours | Becoming aware of a personal data breach, where feasible |
The DORA line is the demanding one, because the clock starts at classification and classification is an analytic act performed on incomplete information. Four hours from that moment is survivable only if the criteria, the evidence needed and the person authorised to apply them were all settled in advance. A next-business-day response target and a four-hour notification duty are not compatible.
The NIS2 early warning is less tight but more specific about content: within 24 hours it must indicate, where applicable, whether the significant incident “is suspected of being caused by unlawful or malicious acts or could have a cross-border impact”. Both of those are triage findings. Somebody competent has to produce them on day one.
The checklist
- The verb: what must be complete by the target.
- The trigger: your declaration, on a named channel, with a tested out-of-band fallback.
- Triage or containment, and if containment, the access and authority that make it possible.
- Coverage: the same figure at 03:00 on a public holiday, in a named timezone.
- The severity gate, written so it can be applied without a meeting.
- The remedy: a credit, an escalation right and a written miss report.
- Capacity: your position when the provider’s queue is full, and a duty to tell you early.
- For DORA entities, precise quantitative and qualitative targets, because Article 30(3)(a) requires them.
The scoping tool assembles those into draft wording from five answers about your organisation, and the cost guide explains why the tier you choose to meet them is the largest single lever on the fee.
Sources
- NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management Section 2.2 on contracted third parties, authority to act and restrictions; subcategory RS.MA-02 on triage and validation; RS.MA-04 on escalation and elevation.
- Regulation (EU) 2022/2554 (DORA), Article 30 Article 30(3)(a) requires precise quantitative and qualitative performance targets enabling corrective action without undue delay.
- Commission Delegated Regulation (EU) 2025/301 Time limits for the initial notification, intermediate report and final report on major ICT-related incidents.
- Directive (EU) 2022/2555 (NIS2), Article 23 The 24-hour early warning, its required content, the 72-hour notification and the one-month final report.
- Commission Implementing Regulation (EU) 2024/2690, Annex point 3 Point 3.4.2(a) requires assessment against predefined criteria laid down in advance and a triage determining the priority of containment and eradication.
- Cyber incident response processes An always-available conference number, escalation criteria, and alternative communications when normal channels are unavailable.
- Good Practice Guide for Incident Management Prioritisation matrix in which SLA customers receive priority one service and the wider constituency receives best effort.
- Unit 42 Incident Response Response SLAs range from 24 hours to two hours by retainer and service level. Checked 13 September 2026.
- Mandiant Incident Response Services Two-hour response time in the event of a breach. Checked 13 September 2026.
- Incident Response One-hour response time. Checked 13 September 2026.
Follow-up
Questions this raises
Is a one-hour SLA better than a two-hour SLA?
Can we get containment inside an hour?
What if we have operational technology in scope?
Should the SLA cover regulatory notification drafting?
What is a reasonable remedy for a missed target?
Keep reading
More from the file
-
What is an incident response retainer?
The definition, the six components that recur across real agreements, the three commercial models, and the honest list of things a retainer does not do for you.
Read the guide -
What does an incident response retainer cost?
Nobody publishes a price. What can be established is the structure: three models, the variables that move each one, and the single number worth extracting from a quote.
Read the guide -
NIS2, DORA and the incident response retainer
Neither instrument requires a retainer. Both require a capability, both run clocks a retainer has to feed, and one of them regulates the retainer contract itself, clause by clause.
Read the guide