By HAWK Network Defense
A managed detection and response agreement should help your team answer a practical question: what can we rely on when an incident interrupts the business?
A fast response commitment is useful only when both parties understand what starts the clock, what action meets the commitment, and what happens next. A notification, an investigation and a verified containment result describe different events.
The service-level agreement, statement of work and operating procedures should tell a consistent story. Buyers should be able to trace each important promise to an owner, a measurable event and the evidence that demonstrates delivery. Here are the questions worth resolving before the service becomes part of your response plan.
Define the service boundary
Start with the environment the provider will actually cover. Identify the enrolled endpoints, identity services, cloud environments, telemetry sources and supported response actions. Record which systems remain outside the service and how changes enter scope.
Then distinguish monitoring, investigation, notification, containment and recovery responsibilities. Does the provider investigate suspicious activity, recommend an action, execute an authorized action, or support your team while it acts? Those commitments should be explicit.
The NCSC's guidance for choosing a managed service provider recommends clear contracts covering responsibilities, response times and third parties. It also emphasizes understanding how incidents will be handled and communicated.[1] Although that guidance addresses MSPs broadly, its contracting questions are useful when evaluating the specific MDR service being purchased.
Make every response clock understandable
For each timing commitment, ask for a defined start event, stop event, severity level and measurement method. Does the clock begin when activity occurs, when telemetry reaches the provider, when an alert is created, or when the provider classifies an incident?
Ask the same question about completion. Acknowledging an alert might satisfy one commitment. Starting an investigation might satisfy another. Neither should be presented as proof that malicious activity has stopped.
Have the provider walk through a sample timeline with your team. Record detection, investigation, customer notification, authorization, action and verification separately. This is a practical way to expose differences in interpretation before they become an argument during an incident.
Agree on severity and clock exceptions
Severity should reflect business consequence as well as technical indicators. A suspicious action affecting a critical business service may need different handling from a similar event on a low-impact test system. Define who can change severity and how disagreements are escalated.
Document any conditions that pause or exclude a measurement. Examples could include unavailable telemetry, a disconnected response tool, missing customer authorization or an unreachable contact. Specify who records the condition and how the customer is informed.
Keep total elapsed time visible alongside any adjusted service measurement. A valid pause may explain a provider's performance calculation while the business is still exposed. Both views are useful, and neither should disappear from the incident record.
Set response authority before the incident
Define which actions the provider may execute under preapproved procedures and which require customer approval. Include the systems affected, conditions for action, limits, escalation route and authority to stop or reverse an action where reversal is possible.
Consider a hypothetical compromised laptop. The provider might be authorized to isolate it immediately. A similar action against a production server could require a different decision path because of its business dependencies. The agreement should connect those distinctions to tested operating procedures.
Review the after-hours path as carefully as the daytime path. If nobody answers the primary contact, who receives the escalation? What is the provider permitted to do while waiting? Avoid leaving that decision to an assumption shared by neither party.
Specify the evidence you will receive
Require enough information to understand the finding, the decision and the outcome. A useful incident record can identify affected assets and identities, supporting observations, the investigation timeline, actions attempted, approvals and the evidence used to assess the result.
Ask how failed actions and uncertain outcomes are reported. A command returning successfully may show that an operation was accepted. Further evidence may be needed to establish whether the intended restriction took effect and whether additional malicious activity remains.
NIST SP 800-61r3 addresses supplier requirements for cybersecurity performance and incident information sharing, and includes relevant suppliers in incident planning, response and recovery.[2] Translate those principles into specific deliverables, access arrangements and retention expectations appropriate to your environment.
Plan for missing inputs and service disruption
The agreement should explain how your team learns that a critical telemetry source has stopped reporting or a response integration is unavailable. Identify who investigates the interruption, who restores the connection and what temporary operating approach applies.
Also ask what happens if the provider experiences its own disruption. Establish alternate communications, access to incident information and a workable handoff to your internal team or another authorized responder.
These are service design questions, not promises that every disruption can be eliminated. Making dependencies visible lets leadership decide whether the proposed service meets the business's needs and where additional arrangements are necessary.
Review performance with records you can inspect
Ask for a sample service report before agreeing to its format. It should explain the measured population, severity categories, missed commitments, exclusions and unresolved incidents. An average response time without those definitions can be difficult to interpret.
Review individual exceptions as well as aggregate measures. Determine whether a delay arose from provider work, customer approval, missing evidence or an unavailable tool, then assign the improvement to someone who can deliver it.
Commercial remedies and dispute procedures belong in the appropriate agreement and review process. They should accompany an operational improvement path. The objective is to understand what failed, reduce the chance of recurrence and verify that the service can perform as intended.
Test the agreement against an incident scenario
Before relying on the service, run a joint walkthrough using a plausible incident. Give the participants the service documents, contact list and available evidence. Ask them to identify the next action, decision owner, applicable clock and required record at each stage.
Include an unavailable approver or failed response connection. If the documents leave participants guessing, resolve the ambiguity and repeat the affected part of the exercise.
When evaluating an MDR service, ask for commitments that connect scope, time, authority and evidence. HAWK's managed detection and response overview and security operations automation overview provide further context for discussing investigation, authorized response and outcome verification.[3][4] Specific service commitments should always be established for the customer's environment.
A useful SLA gives both teams a shared basis for action and a record they can examine afterward. That is the standard to bring to the conversation before signing.
Sources and references
[1] NCSC, Choosing a managed service provider (MSP)
[2] NIST SP 800-61r3, final, April 2025
