A cybersecurity vendor's homepage will tell you they're "enterprise-grade" and "trusted by leading companies worldwide." None of that tells you what happens at 2 a.m. when their platform misses an intrusion, or how many hours pass before someone tells you about it. Evaluating a security vendor isn't the same exercise as evaluating a project-management tool: the product's entire job is to reduce your risk, so a weak clause here doesn't just create inconvenience — it becomes the risk. Here's the checklist procurement, IT and legal teams should run before any cybersecurity contract gets signed.
Why a generic vendor checklist isn't enough
Most procurement checklists cover the same four boxes: price, uptime, support tier, integration effort. Those still matter for a security vendor, but they're not sufficient — these tools usually get privileged access: log ingestion, network taps, endpoint agents with kernel-level permissions, read access to your identity provider. The evaluation needs one more layer: what's the vendor actually certified to protect, how fast do they detect and respond, what happens to your data at contract end, and who's liable if the tool fails at the moment it matters.
1. Certifications: what SOC 2 and ISO 27001 actually prove
A vendor listing "SOC 2 compliant" on a sales deck is not the same as a vendor handing over a current SOC 2 Type II report. Three distinctions matter:
- Type I vs Type II. Type I attests controls existed on a single date; Type II attests they operated effectively over 6-12 months. Always ask for Type II.
- Report age. Older than 12 months is stale by convention. Ask for the current cycle and calendar the renewal yourself.
- Scope, not just the logo. Both frameworks certify a defined scope — listed in the ISO Statement of Applicability or SOC 2 system description. A vendor can be certified for one product line while the module you're buying sits outside the audited boundary.
The AICPA's own guidance on SOC 2 is a useful reference if your team is new to reading these reports.
2. SLA terms that matter more than headline uptime
Uptime percentages are the easiest number to compare and the least informative for a security tool. What actually matters:
- Detection latency. Time from event to alert. A tool that's "up" but takes six hours to surface a critical alert isn't protecting you.
- MTTA / MTTR for the vendor's own support desk. A P1 ticket unacknowledged for four hours is the number that should worry you.
- Threat intel cadence. How often is the ruleset refreshed against new CVEs? Vendors who can't answer precisely usually update reactively.
- Credit mechanics. Most security SLAs cap credits at 10-25% of monthly fees — read what the cap actually covers.
The general mechanics of comparing SLA language across vendors — measurement windows, carve-outs, escalation paths — are in our SLA comparison checklist; the same terms apply here, with detection and response time added on top.
3. Incident response commitments to get in writing
This is the section most vendor MSAs leave vague, and it's the one that matters most. Push for specific, numbered commitments:
- Breach notification window. How many hours after discovery must the vendor notify you? "Commercially reasonable efforts" is not a number — push for a firm 24-48 hours.
- Post-incident report. Written root-cause analysis, remediation steps and timeline, delivered within a defined number of business days — not a verbal debrief.
- Right to audit. Annual right to the current SOC 2 / ISO 27001 report and a recent pen-test summary, without renegotiating each time.
- Sub-processor and law-enforcement notification. Advance notice before adding a sub-processor, and notice of any subpoena touching your data where legally permitted.
Under EU financial or critical-infrastructure regulation, these clauses aren't optional — DORA imposes specific ICT incident reporting timelines your vendor contracts need to mirror. Our DORA and NIS2 procurement checklist covers what regulators expect in the contract itself.
4. Data handling and sub-processor clauses
Security tools often collect more telemetry than any other vendor in your stack — logs, packet metadata, endpoint activity, sometimes credentials. Confirm in writing:
- Data residency — where telemetry and logs are stored, and whether that's restrictable to a specific region.
- Encryption specifics — algorithm and key length at rest and in transit, and whether customer-managed keys are offered.
- Retention and deletion — a contractual deletion timeline after termination. Thirty days is reasonable; "at our discretion" is not.
- Sub-processor list — a maintained list of who else touches your data, with each one's certification status.
Most vendors' standard MSAs address some of these and stay silent on others. Rather than sending every finalist the full 100+ question SIG or CAIQ, it's more effective to generate a shorter list targeted at what their contract doesn't cover — that's the logic behind our SIG/CAIQ/SOC 2 questionnaire generator, which surfaces only the real gaps.
Sample RFP questions to send finalists
Ten questions that get real answers instead of marketing copy:
- Provide your most recent SOC 2 Type II report, including audit period and defined scope.
- What is your committed breach notification window, in hours from discovery?
- What are your contractual MTTA and MTTR for P1 support tickets?
- Do you offer customer-managed encryption keys, and at what tier?
- What is your data deletion timeline post-termination, as a contract term?
- List all sub-processors with data access and your notification process for new ones.
- How often is your detection ruleset updated against newly disclosed CVEs?
- What is the maximum service credit under your SLA, and what excludes a claim?
- Will you share a summary of your most recent penetration test?
- What is your data residency commitment, and can it be restricted to a region?
Where red flags hide in the finalist round
By the time you're comparing finalist proposals, the risk isn't usually a missing certification — it's language that looks fine on a skim and breaks down under close reading. "Commercially reasonable efforts to notify" instead of a firm hour count. A SOC 2 scope statement that quietly excludes the module you're buying. A sub-processor clause with no advance-notice requirement. These are exactly the patterns automated red-flag detection is built to catch: it scans the uploaded MSA and SLA exhibits for undefined response windows and scope gaps, then flags each by severity with the verbatim clause cited alongside it, so nothing stays buried on page 40 of a 70-page document.
If your team has non-negotiables — SOC 2 Type II within 12 months, a 24-hour notification window, a named data residency region — encoding them once as required positions means every finalist gets checked against the same bar automatically.
The one-page recap
- SOC 2 Type II, dated within 12 months, scope confirmed against the product bought
- ISO 27001 Statement of Applicability reviewed, not just the certificate
- Detection latency and MTTA/MTTR on record, not just uptime
- Breach notification window as a firm hour count, not "commercially reasonable efforts"
- Written post-incident report with a defined delivery deadline
- Annual right to audit and pen-test summaries
- Sub-processor list with advance-notice before changes
- Data residency, encryption specifics, and a post-termination deletion timeline
- Service credit cap and claim process spelled out in writing