MSSP Due Diligence Checklist: 24 Questions and Evidence Requests

An MSSP due diligence exercise should tell you how the service will work when an alert is ambiguous, a data source fails, an incident crosses team boundaries, or the contract needs to end. A certification, sales presentation, and reference call can support that decision, but none of them proves the operating service on its own.

This checklist is for UK security and IT leaders selecting, renewing, or challenging a managed security service provider. It extends the baseline questions in the NCSC guidance for choosing a managed service provider into the day-to-day evidence expected from a security monitoring service.

Use it in two passes. First, answer from the documents and service records you already hold. Then ask the provider to close the evidence gaps. A confident answer without current evidence should remain an open item.

Before you start: define the decision

Due diligence becomes unfocused when every possible control is treated as equally important. Record the decision you are making, the systems and data in scope, the services the MSSP is expected to perform, and the risks that would make the relationship unacceptable.

• Selection: can this provider operate the service your environment needs?
• Renewal: is the current service delivering enough evidence and improvement to justify another term?
• Remediation: can known service gaps be fixed with clear owners and dates?
• Exit: can monitoring, data, knowledge, and responsibilities move without creating an unmanaged gap?

The ServiceSignal MSSP framework groups this review into six operational dimensions. The same structure is used below so the answers can feed directly into the free MSSP Reality Check.

1. Scope, onboarding, and accountability

1. What assets, identities, cloud services, networks, and business processes are in scope?

Request the current scope schedule and compare it with the systems the business considers critical. Look for exclusions that are described in technical language but create a material business blind spot.

2. Which required data sources are connected, healthy, and actually used?

Ask for a data-source inventory showing owner, purpose, ingestion status, expected volume, last validation date, and any accepted gaps. A list of licensed integrations is not the same as evidence that useful telemetry is arriving.

3. Who owns each decision during a suspected incident?

Request a responsibility matrix covering investigation, containment advice, endpoint isolation, account disablement, communications, evidence preservation, legal escalation, and closure. Ambiguous ownership is most expensive when time is already short.

4. Which subcontractors, platforms, and delivery locations support the service?

Understand where analysts, telemetry, case data, and support functions are located. Record any subprocessors and the controls that apply when access crosses organisational or geographic boundaries.

2. Detection coverage and validation

5. Can the provider show a current detection use-case catalogue?

The catalogue should identify the behaviour being detected, relevant assets or identities, data dependencies, severity, response path, owner, and status. Generic rule counts do not explain whether the coverage fits your environment.

6. How is important detection logic tested?

Ask for recent test records, expected and actual results, failed tests, remediation, and retest dates. The strongest evidence shows that a relevant signal travelled through the complete service, not only that a rule exists in a platform.

7. What has been tuned specifically for your organisation?

Request examples of client-specific thresholds, allow-lists, suppression decisions, threat scenarios, and changes made after incidents or false positives. Check that each change has an owner and an explanation.

8. How are coverage gaps recorded and accepted?

A gap register should state the missing telemetry or capability, affected risk, compensating control, accountable owner, target date, and formal acceptance where the gap will remain.

3. Triage, investigation, and escalation

9. Can the provider show anonymised investigation records?

Look for analyst reasoning: what was observed, what context was checked, which hypotheses were considered, why the case was escalated or closed, and what evidence supports the decision. A status change without reasoning is weak assurance.

10. What does 24/7 coverage mean in practice?

Ask about shift coverage, experience mix, handovers, escalation to senior analysts, language and location, holiday arrangements, and the response when demand exceeds normal capacity.

11. How are priority and severity assigned?

Confirm that business context, asset criticality, identity privilege, threat behaviour, and confidence can change priority. A fixed vendor severity may not represent the risk to your organisation.

12. How does customer feedback improve future decisions?

Request examples where an incorrect escalation, missed context, or slow response resulted in a documented tuning or process change. Feedback should alter the service, not disappear into meeting notes.

4. Reporting and continual improvement

13. Does reporting explain outcomes as well as activity?

A useful report distinguishes alerts from investigated cases, explains material decisions, shows coverage and data health, tracks false positives, and identifies risk that remains unresolved. Large event totals alone are not evidence of value.

14. Is there a prioritised improvement backlog?

Review the backlog for actions, owners, dependencies, due dates, expected outcomes, and closure evidence. Check whether old items are repeatedly carried forward without a decision.

15. Are service-review decisions recorded and followed through?

Minutes should capture decisions, accepted risks, requested evidence, and accountable owners. The next meeting should start by resolving those actions rather than presenting the same dashboard again.

16. Do incidents and near misses change the service?

Ask for examples of lessons that changed detection logic, escalation criteria, runbooks, data collection, or customer responsibilities. Improvement should be visible in controlled service records.

5. Resilience, continuity, and exit

17. How does the MSSP continue operating through its own disruption?

Request the service continuity approach for platform failure, site loss, supplier outage, staff shortage, and cyber incident. Confirm when the customer is notified and what degraded operation looks like.

18. How is knowledge retained when key people leave?

Look for current runbooks, environment notes, decision records, handover controls, and named deputies. A service that depends on one analyst or account manager carries hidden continuity risk.

19. Can you retrieve the service data and records you may need?

Confirm access to relevant logs, cases, reports, detection content, audit records, and configuration data during normal operation and after termination. Test a representative export before an urgent need arises.

20. Is there a workable transition and termination plan?

Check notice periods, transition assistance, data formats, deletion evidence, knowledge transfer, continued monitoring during handover, additional charges, and the point at which each responsibility changes hands.

6. Commercial alignment and governance

21. Do service levels measure meaningful service behaviour?

Response-time targets matter, but they should be paired with investigation quality, data health, escalation accuracy, coverage maintenance, action closure, and communication obligations. The guide to MSSP SLAs versus security outcomes sets out a practical scorecard.

22. What happens when the service misses an obligation?

Understand notification, root-cause analysis, remediation, repeat-failure escalation, service credits, and termination rights. A remedy that depends on the customer discovering and claiming every failure is difficult to rely on.

23. How are scope and price changes controlled?

Request the change-control process and examples. New systems, data volumes, acquisitions, regulations, and service requests should not create silent coverage gaps or unexpected invoices.

24. Are data ownership, retention, and deletion terms explicit?

Confirm who owns customer data and provider-created records, how long each class is retained, who can access it, how it is returned, and how deletion is evidenced. Align these terms with your legal, regulatory, insurance, and investigation needs.

How to score the answers

Do not reduce due diligence to a document count. Score whether the evidence is current, specific to your service, controlled, and used to make decisions.

• Strong: current evidence exists, ownership is clear, and the process can be traced through a real example.
• Partial: the process exists but evidence is generic, incomplete, old, or inconsistently followed.
• Weak: the answer relies on assurance, future intent, or a document that does not show operation.
• Red flag: a key control is absent, contradicted by evidence, or cannot be explained by an accountable owner.

ServiceSignal publishes its scoring methodology and limitations. The result is an indicative decision aid, not a certification or substitute for contractual, legal, or technical review.

When should MSSP due diligence be repeated?

Run the full review before selection and renewal, then revisit affected areas after material change: an incident, acquisition, major platform migration, service failure, scope expansion, key-person change, or new regulatory obligation. Use monthly service reviews to keep the evidence current rather than rebuilding it just before contract expiry.

Frequently asked questions

Is an ISO 27001 certificate enough for MSSP due diligence?

No. A relevant certification can support confidence in the provider's management system, but it does not by itself show that your detection coverage, data sources, investigations, escalations, and service actions are effective.

Should the MSSP complete the checklist?

The customer should own the conclusion. Ask the provider for evidence and clarification, but compare that evidence with internal incident records, service experience, contract obligations, and the risks the business needs managed.

What if evidence is commercially sensitive?

Agree a proportionate way to demonstrate the control, such as a redacted record, supervised walkthrough, summary with traceable references, or independent assurance report. Sensitivity may change how evidence is shared; it should not turn the answer into an unsupported claim.

The NCSC also publishes broader supply-chain security principles. Use those principles alongside this operational checklist when the provider has access to critical systems, sensitive data, or important downstream suppliers.