TL;DR:
- Incident response vendor due diligence involves risk tiering, security control verification, enforceable contracts, and ongoing monitoring. Critical vendors require thorough evaluation, including validated controls and detailed SLAs, before engagement; ongoing oversight ensures performance and security. Proper assessment prevents critical mistakes during breaches and ensures operational discipline across the vendor lifecycle.
Incident response vendor due diligence steps are the defined procedures cybersecurity professionals use to verify a vendor's ability to manage security incidents effectively and compliantly. The formal industry term is "third-party security assessment," and it covers everything from risk tiering and SOC 2 Type II review to contractual SLA enforcement and post-selection monitoring. Selecting the wrong incident response partner during a breach is not a recoverable mistake. This guide details each step of the vendor assessment process, with specific criteria, contract language, and validation methods that separate genuinely capable providers from those selling marketing promises.
What are the core incident response vendor due diligence steps?
Incident response vendor due diligence begins with scoping the assessment, not with sending a questionnaire. The depth of your evaluation must match the risk the vendor represents to your organisation. A provider with access to live production data, endpoint telemetry, or regulated personal data warrants a fundamentally different level of scrutiny than one handling only anonymised logs.
Risk tiering based on data sensitivity and blast radius determines the depth of due diligence required per vendor. That classification directly governs how many controls you verify, how many documents you request, and how frequently you reassess after contract signature.
The five core steps in any credible cybersecurity vendor due diligence process are: establish scope and risk tier, review security controls and documentation, evaluate contract terms and SLAs, validate vendor claims through testing, and monitor performance continuously post-selection. Each step builds on the last. Skipping risk tiering means your documentation review has no anchor. Skipping validation means your contract protects you on paper only.
How do you establish scope and risk tier?
The vendor assessment process starts by collecting three categories of information: data types the vendor will access or process, integration points with your internal systems, and any subprocessors the vendor relies upon. Each of these factors expands the blast radius of a potential incident.
Assigning risk tiers using a Critical, High, Medium, or Low classification gives your team a consistent framework for deciding assessment depth. The table below shows typical criteria for each tier.
| Risk tier | Data sensitivity | Integration depth | Due diligence scope |
|---|---|---|---|
| Critical | Regulated PII, financial records, health data | Direct production access, admin privileges | Full SOC 2 Type II, ISO 27001, pen test, on-site audit |
| High | Internal confidential data, IP | Read access to core systems | SOC 2 Type II, pen test summary, runbook review |
| Medium | Aggregated or pseudonymised data | API access, limited scope | SOC 2 Type I or equivalent, questionnaire, SLA review |
| Low | Public or non-sensitive data | No direct system access | Questionnaire only, annual review |
Critical-tier vendors require the most thorough incident response evaluation. That means reviewing certificates for scope and recency, not just confirming their existence. An ISO 27001 certificate issued three years ago and never renewed tells you more about a vendor's operational discipline than any sales deck.
Pro Tip: Ask the vendor to confirm which specific systems and data types fall within the scope of their SOC 2 or ISO 27001 certification. Certificates that exclude production environments are a significant gap.
What security controls and documents should you review?
Security documentation review is the technical core of any incident response partner checklist. The goal is not to collect paperwork. The goal is to identify gaps between what a vendor claims and what their controls actually deliver.
Review the following for every Critical or High-tier vendor:
- SOC 2 Type II and ISO 27001 certificates: Confirm the audit period covers the last 12 months and that the scope includes the systems relevant to your engagement. A Type I report only confirms controls exist at a point in time. Type II confirms they operated effectively over a period.
- Penetration test summaries: Request the executive summary and remediation status. Unresolved critical findings from a test conducted more than 12 months ago are a red flag.
- Incident response plans and runbooks: Real runbooks are precise, sequenced, and tested. Generic prose-heavy templates indicate a lack of hands-on experience. Ask for runbooks specific to your technology stack, not a generic template.
- Breach history and notification procedures: Vendors with a transparent breach history and documented notification timelines demonstrate operational maturity. Vendors who refuse to discuss past incidents do not.
- Questionnaire responses mapped to control frameworks: Map answers to NIST CSF, CIS Controls, or ISO 27001 Annex A. Responses that cannot be mapped to a specific control are unverifiable.
The incident response readiness assessment checklist published by Makkarisecurity provides a structured framework for this documentation review phase, including specific questions aligned to each control domain.
What contract terms protect you with an incident response vendor?
Contract language is where due diligence either holds or collapses. Vague SLA terms like "commercially reasonable efforts" are unenforceable. Every obligation must be measurable, and every failure must carry a defined consequence.
Enterprise incident response contracts require the first incident update within 60 minutes of detection, hourly updates thereafter, and a root cause analysis delivered within 5–10 business days. These are not aspirational targets. They are contractual minimums that trigger credits or escalation rights if missed.
Your contract must also address:
- Breach notification timelines: The vendor must notify you within a defined window, typically 24–72 hours, aligned with GDPR or NIS2 obligations depending on your jurisdiction.
- Data deletion and retention: Specify exactly when and how the vendor destroys your data post-engagement, with written confirmation.
- Subprocessor obligations: Any subprocessor the vendor uses must meet the same contractual security standards as the vendor itself. Require advance notice of subprocessor changes.
- Audit rights: You must retain the right to audit the vendor's controls, either directly or through a third party, at least annually.
- Escalation paths and financial remedies: Define who you contact at the vendor when SLAs are breached, and what credits or remedies apply.
Well-defined contract language reduces ambiguity and enhances enforcement when incidents occur. The Makkarisecurity guide on negotiating IR contracts covers specific clause structures for UK and European regulatory environments.
Pro Tip: Replace every instance of "commercially reasonable" in a draft contract with a specific time or measurable outcome. If the vendor resists, that resistance tells you something important about their accountability culture.
How do you validate vendor claims before going live?
Vendor claims require testing, not trust. The most common mistake in the steps for vendor selection is accepting a vendor's self-reported capabilities without independent verification.
- Request redacted incident reports. Ask for two or three real, redacted post-incident reports from the last 18 months. These reveal how the vendor communicates under pressure, how they identify root causes, and whether they track remediation to closure.
- Verify backup and restore test records. Ask for documented evidence of successful restore tests, including dates, systems tested, and recovery time achieved. Uptime percentages without restore test records are meaningless.
- Confirm named on-call engineers. Generic "24/7 support" claims are insufficient. Confirm the names and qualifications of the engineers who will respond to your incidents, and ask about staff turnover rates.
- Run a tabletop exercise during onboarding. Tabletop exercises during onboarding highlight gaps in runbooks and escalation paths before real incidents occur. They also reveal how the vendor's team communicates under simulated pressure.
- Commission a proof-of-value pilot. Proof-of-value pilots with seeded simulated attacks convert marketing claims into measurable outcomes. A vendor confident in their capabilities will welcome this. One who declines should be treated with caution.
- Review monthly performance reporting. Confirm the vendor provides structured monthly reports covering incident volumes, response times, and open remediation items. Ad hoc reporting is not sufficient for Critical-tier vendors.
Pro Tip: Seed a benign simulated alert into your environment during the pilot period without telling the vendor in advance. Their detection and response to that alert is the most honest capability test available.
How do you monitor vendors after selection?
Post-selection monitoring is where most organisations lose the discipline they applied during evaluation. Vendor performance degrades without structured oversight, and the risks you assessed at onboarding evolve as the vendor's own environment changes.
Set and track the following KPIs from day one:
- Mean time to acknowledge (MTTA): Measures how quickly the vendor confirms receipt of an incident alert. Target: under 15 minutes for Critical-tier incidents.
- Patch latency: Tracks the time between a vulnerability being disclosed and the vendor applying the relevant patch to systems within your scope.
- Backup restore success rate: Confirms that restore tests are being conducted and succeeding. Any failure rate above zero requires immediate explanation.
Monitoring KPIs such as mean time to acknowledge, patch latency, and backup restore success rates post go-live maintains incident response effectiveness over time. Continuous tracking identifies emerging risks before they become incidents.
Schedule a formal incident response plan test at least every six months. Require the vendor to provide evidence of the test, including any gaps identified and the remediation timeline. Manage subprocessor changes through a formal change notification process, and treat any material change to the vendor's ownership, staffing, or technology stack as a trigger for a partial reassessment.
Key takeaways
Rigorous incident response vendor due diligence requires risk tiering, verified security controls, enforceable contract terms, and continuous post-selection monitoring to protect your organisation during a breach.
| Point | Details |
|---|---|
| Risk tier first | Assign Critical, High, Medium, or Low before requesting any documentation. |
| Verify, do not accept | Request redacted incident reports and runbooks specific to your technology stack. |
| Enforce SLA timelines | Mandate the first update within 60 minutes and root cause analysis within 5–10 business days. |
| Test before go-live | Run a tabletop exercise and a proof-of-value pilot during onboarding. |
| Monitor continuously | Track MTTA, patch latency, and restore success rates from day one post-selection. |
What I have learned from incident response vendor assessments
The most consistent failure I see in vendor assessment processes is treating due diligence as a bureaucratic exercise rather than an evidence-gathering one. Teams send a 150-question questionnaire, receive polished answers, and file the responses without ever testing a single claim. That is not due diligence. That is documentation theatre.
The vendors worth trusting are the ones who push back on vague questions and ask for specificity. They want to know your technology stack, your regulatory obligations, and your incident history, because that information helps them give you accurate answers. Vendors who answer every question with equal confidence, regardless of complexity, are telling you something important.
Blameless post-incident review reports with tracked action closure rates reflect better operational discipline than uptime metrics alone. I weight PIR quality more heavily than any certificate. A vendor who learns from incidents and documents that learning is a vendor who will perform when it matters.
The other underrated factor is multidisciplinary involvement. Procurement teams negotiate price. Security teams evaluate controls. Legal teams review contract language. When those three functions work from the same risk tier classification and the same evaluation criteria, the assessment produces a coherent picture. When they work in silos, you get a contract that contradicts the security requirements and a price that does not reflect the actual scope.
— Makkari
Makkarisecurity's support for incident response vendor evaluation
Makkarisecurity works with cybersecurity teams across the UK, Gibraltar, and Europe who need more than a checklist. The team brings hands-on DFIR experience to vendor evaluation frameworks, contract review, and pilot project design.
Whether you are assessing a new incident response partner or reassessing an existing one, Makkarisecurity's incident response and forensics services provide the technical depth and contractual guidance to make that evaluation credible. The team's proprietary forensic engine and Eviction Pledge reflect the same standards of accountability they help clients demand from their own vendors. Speak to Makkarisecurity about structuring a vendor pilot or reviewing your current IR contract terms.
FAQ
What documents should I request from an incident response vendor?
Request SOC 2 Type II and ISO 27001 certificates, penetration test summaries with remediation status, redacted incident runbooks, and breach notification procedures. Certificates should cover the last 12 months and include the systems relevant to your engagement.
How do I set SLA terms in an incident response contract?
Mandate the first incident update within 60 minutes of detection, hourly updates thereafter, and a root cause analysis within 5–10 business days. Each obligation should carry a defined financial remedy or escalation right if missed.
What is a proof-of-value pilot in vendor due diligence?
A proof-of-value pilot is a controlled test where the vendor responds to seeded simulated incidents in your environment. It converts vendor capability claims into measurable outcomes before full contract commitment.
How often should I reassess an incident response vendor?
Reassess Critical-tier vendors at least annually, or immediately following any material change to the vendor's ownership, staffing, subprocessors, or technology stack. Run a formal incident response plan test every six months.
What risk tier criteria should I use for incident response vendors?
Classify vendors as Critical if they access regulated data or have direct production system access. Assign High for read access to core systems, Medium for limited API access, and Low for vendors with no direct system access. Tier determines the scope and frequency of your assessment.