What Should an MDR Acceptance Test Include?

A managed detection and response (MDR) acceptance test should trace telemetry through investigation, escalation, and authorized response. National Institute of Standards and Technology (NIST) guidance recommends coordinated exercises and clear provider responsibilities (NIST SP 800-61 Rev. 3). Separately verify technical deployment and operational readiness, using safe events and documented acceptance criteria.

An installed agent and a connected portal do not answer the buyer’s most important question: what happens when something needs a response? NIST Special Publication 800-61 Revision 3 integrates preparation, third-party coordination, testing, and improvement into incident response (NIST SP 800-61 Rev. 3). Our proposed acceptance process makes those responsibilities observable before steady-state service begins.

What are the key takeaways?

• Define the covered systems and required log sources before testing.
• Trace a benign event through collection, analysis, escalation, and closure.
• NIST recommends documenting provider authority and restrictions (NIST SP 800-61 Rev. 3).
• Record failed tests and coverage exceptions as owned actions, not invisible assumptions.

What should be agreed before onboarding starts?

Agree the service boundary, responsibilities, and acceptance evidence before installation. NIST describes incident-response provider arrangements as shared responsibilities that should be clearly defined in the contract (NIST SP 800-61 Rev. 3). A provider cannot demonstrate coverage against an inventory the parties have never reconciled.

Our recommended acceptance plan lists included systems, identities, cloud services, network controls, and required telemetry. State what is excluded and who monitors those exclusions. Separate the provider’s collection responsibility from the customer’s responsibility to grant access, maintain licensing, or configure a source.

Also agree how a test is approved and when it must stop. Use benign, controlled events rather than live malware or unapproved production disruption. Name the customer observer and provider lead, the expected evidence, and the person authorized to accept the service or require corrective work.

How do you prove that telemetry is usable?

Prove that records arrive with the fields needed to investigate the agreed scenario. NIST recommends generating logs and making them available for continuous monitoring, and maintaining current inventories and communication information (NIST SP 800-61 Rev. 3). A connector showing green is not the same as a useful record.

Choose representative sources from the signed scope. Generate or identify an approved benign event, then have the provider locate it and explain the timestamp, identity, asset, action, and relevant context. Confirm that the provider can distinguish collection delay from the time the underlying event occurred.

Document any missing fields, excluded event types, intermittent collection, or inaccessible historical records. If the service depends on another team fixing a source, record that dependency and its owner. Avoid declaring full coverage while describing important blind spots only in an informal handoff call.

How should detection be tested without unsafe activity?

Use a scenario approved by the application owner and the provider, with known expected telemetry and no unauthorized exploitation. NIST recommends security tests and exercises coordinated with suppliers and other relevant third parties (NIST SP 800-61 Rev. 3). The test should measure the service, not surprise operational teams with avoidable risk.

An illustrative identity scenario might use a designated test account and an approved administrative change. An endpoint scenario might use a vendor-supported benign test mechanism. The exact method must fit the deployed products and written authorization; this article does not prescribe a universal attack simulation.

Decide whether the provider will know the precise test time. A cooperative walkthrough is useful for debugging collection; a later controlled exercise can evaluate operational handling. Label the mode clearly in the results so a rehearsed demonstration is not represented as an unannounced detection success.

What should the escalation test measure?

Measure whether a qualified person receives enough information to make the required decision. NIST recommends established coordination procedures specifying what must be reported, to whom, and when (NIST SP 800-61 Rev. 3). Sending a message to an unmonitored address is not a completed operational handoff.

Our suggested timeline distinguishes event generation, source collection, provider receipt, analyst decision, notification, customer acknowledgement, and authorized action. Do not collapse those into one attractive response-time number. Agree which interval the contract measures and which intervals depend on the customer.

Exercise an unavailable-primary-contact scenario without creating a real emergency. Confirm the backup contact, escalation authority, and instructions when nobody responds. Review whether the provider can act within its agreed authority or must wait, and whether the service owner understands the resulting exposure.

How should response authority be demonstrated?

Test a safe action that falls within the signed authority matrix, then verify its result and reversal. NIST says organizations should understand a provider’s authority to act and restrictions on actions such as deactivating services (NIST SP 800-61 Rev. 3). A response feature in a product console does not itself grant permission to use it.

Our recommended matrix identifies the action, affected asset class, preconditions, approver, emergency exception if any, and rollback owner. For sensitive systems, the permitted action may be investigation and escalation rather than automatic isolation. That can be a valid design if the customer accepts and staffs the responsibility.

Record what the analyst did and the result observed by the customer. If the provider lacked a permission, the test should fail that step even if an internal administrator completed the action manually. Correct the responsibility or technical-access gap and repeat the relevant portion.

When should you accept steady-state service?

Accept when the agreed tests pass and residual exceptions have explicit owners and decisions. NIST recommends using evaluations, exercises, and operational lessons to identify improvements (NIST SP 800-61 Rev. 3). Acceptance is a documented operational decision, not merely the end of a project calendar.

We recommend separating blocking defects from accepted limitations and planned enhancements. A missing critical source or unusable escalation path may block acceptance; a lower-priority improvement may have a documented delivery date. Use criteria agreed before testing rather than negotiating the meaning of “ready” after a failure.

Our U.S.-based security operations center (SOC) would want the customer to see both the evidence and the remaining limitations. Compare MDR service responsibilities, the emergency-access exercise guide, and the SOC pricing guide before assigning monitoring, containment, and follow-up work.

What else should buyers and operators know?

Does an installed agent mean onboarding is complete?

Our recommendation is no. Require evidence that agreed telemetry, analysis, escalation, and response workflows operate as contracted.

Should acceptance tests use live malware?

Use approved benign methods and controlled exercises. NIST supports coordinated tests and exercises, not uncontrolled disruption (NIST SP 800-61 Rev. 3).

Who owns customer response delays?

Agree the responsibility split and timing definitions in the contract. NIST recommends clear provider roles, authority, information flows, and restrictions (NIST SP 800-61 Rev. 3).

What happens when a test fails?

Record the failed step, corrective owner, and retest criterion. Accept residual limitations only through an explicit decision by the appropriate service owner.

What is the next step for your organization?

Bring your scope, current evidence, and unresolved responsibilities to a focused discussion. Schedule a security review or Call 833-92-CYBER to clarify the next practical actions.