Use this cybersecurity vendor due diligence checklist to evaluate security controls, data handling, compliance evidence, incident response, subcontractors, pricing risk, and contract terms before signing. Record the answer, evidence, owner, and review date for every question so the assessment remains useful after procurement.
Overview
A vendor questionnaire is only valuable when it supports a decision. The goal is not to collect the longest possible set of answers; it is to determine whether a provider’s controls match your data, operational dependence, regulatory obligations, and tolerance for disruption.
Start by defining the service boundary. Identify what the vendor will access, store, process, transmit, or influence. A provider hosting production workloads requires a different review from an identity platform used by administrators, while an MDR provider may require access to logs, endpoints, and incident workflows. For specialized reviews, see our guides to comparing MSSPs by coverage and escalation model, privileged access management vendors, and SSO vendors.
Use the questions below in three stages:
- Screen: remove vendors that cannot meet non-negotiable requirements.
- Verify: request evidence rather than relying on a marketing statement or a completed questionnaire.
- Contract: convert important answers into measurable obligations, rights, and remedies.
Keep an evidence register with these columns: question, vendor response, evidence received, reviewer, risk rating, follow-up action, decision, and next review date. Mark answers as verified, partially verified, unverified, or not applicable. This makes the checklist reusable for renewals, vendor comparisons, and changes to the service.
Checklist by scenario
The following 40 questions form a practical security vendor questionnaire. Adapt the wording to the product and your risk profile.
Business, scope, and accountability
- What exact services, environments, and support functions are included in the proposed scope?
- What types of data will the vendor access, store, process, or transmit?
- Which internal team owns the vendor relationship and accepts residual risk?
- Can the vendor provide a current description of its security governance, policies, and control ownership?
- How are security responsibilities divided between the vendor, the customer, and any cloud or infrastructure providers?
Security controls and access
- How are administrative accounts protected, including multifactor authentication, privileged access, and access reviews?
- How does the vendor provision, modify, and remove employee or contractor access?
- Are production, development, test, and customer environments separated where appropriate?
- How are systems hardened, monitored, and patched, and how are exceptions documented?
- What vulnerability assessment and penetration testing activities are performed, and how are material findings tracked to closure?
- How is customer data encrypted in transit and at rest?
- Who controls encryption keys, and what key rotation, recovery, and access procedures apply?
- What controls protect APIs, service accounts, integrations, and automated data transfers?
- How are logs generated, protected from alteration, retained, and made available to customers?
- What security controls are available to customers, and which require a higher service tier or separate configuration?
For infrastructure-specific purchases, add questions about DNS, certificates, edge controls, backups, and network isolation. Our guides to cloud WAF providers, CDN security and performance, and domain registrar security provide useful comparison categories.
Data handling, privacy, and resilience
- Where is customer data stored and processed, and can the vendor identify the relevant regions?
- How is data classified, segregated, and protected from access by other customers?
- Does the vendor use customer data for analytics, product improvement, artificial intelligence training, advertising, or other secondary purposes?
- What data retention periods apply to production systems, backups, logs, and support tickets?
- How can a customer retrieve and securely delete its data at the end of the relationship?
- What backup strategy, restoration process, and recovery objectives apply to the service?
- How often are disaster recovery and business continuity plans tested?
- What dependencies could interrupt the service, including cloud platforms, telecommunications providers, or critical subcontractors?
If ransomware recovery is material to the purchase, evaluate backup isolation, restoration testing, endpoint controls, and recovery ownership separately. Use the ransomware protection comparison as a framework for those questions.
Incident response and compliance evidence
- What events qualify as a security incident, and how are incidents classified by severity?
- How will the vendor notify customers of incidents that affect their data, service, or access?
- What customer contacts, escalation paths, and response times apply during an incident?
- Does the vendor preserve relevant evidence and support investigation, containment, and recovery activities?
- How are security incidents, near misses, corrective actions, and lessons learned documented?
- Which independent assessments, certifications, or attestations apply to the service being purchased?
- Can the vendor provide the relevant report, scope, period covered, exceptions, and management response under appropriate confidentiality terms?
- How does the vendor handle customer requests for audit evidence, control testing, or compliance support?
A compliance label is not a substitute for evidence. When a vendor claims to be a SOC 2 compliant vendor, confirm the report type, covered service, reporting period, and any exceptions. The SOC 2 evidence guide explains what to check.
Subcontractors, commercial risk, and exit
- Which subprocessors, hosting providers, support partners, or other subcontractors can access customer data?
- How will the vendor notify customers of material changes to its subcontractor list?
- Can the customer object to a new subprocessor or terminate if the risk cannot be resolved?
- What service levels, support coverage, maintenance windows, and escalation commitments are included?
- Which security features, logs, retention periods, or response services create additional charges?
- What happens to security protections, data access, and support during a billing dispute or service suspension?
- What assistance, format, timing, and cost apply when migrating data or configurations to another provider?
- Do the agreement, data processing terms, security addendum, and acceptable-use terms clearly define security obligations and precedence?
- What liability, indemnity, insurance, confidentiality, and notification terms apply to a security incident?
What to double-check
Some answers sound reassuring but are incomplete without context. Ask for evidence that matches the exact product, environment, and contract.
- “We are certified.” Check the certification or attestation’s scope, expiration or reporting period, locations, and exclusions. A corporate certification may not cover every service.
- “Encryption is supported.” Confirm which data is encrypted, which protocols and key-management options are used, and whether encryption applies to backups and exports.
- “We perform regular testing.” Ask what is tested, how findings are prioritized, whether testing includes the purchased service, and whether summaries or remediation evidence are available.
- “We notify customers promptly.” Define the triggering event, notification method, required information, update cadence, and customer cooperation obligations.
- “The platform is highly available.” Review the actual service-level terms, exclusions, maintenance provisions, credits, and dependencies rather than relying on an availability statement.
- “Data is deleted when you leave.” Confirm deletion timelines for live systems, replicas, archives, support systems, and backups, along with the format for return.
For each material control, capture a source: contract language, security addendum, independent report, architecture document, test summary, product configuration, or written clarification from an accountable vendor representative. Assign an owner to unresolved items and do not treat “planned” controls as implemented controls.
Common mistakes
- Using the same questionnaire for every vendor. Tailor the review to access, data sensitivity, outage impact, integration depth, and regulatory needs.
- Confusing a completed questionnaire with verification. A vendor’s answer is a starting point. Request evidence for high-risk claims.
- Reviewing security but ignoring exit risk. Data export, configuration portability, deletion, and transition assistance should be assessed before purchase.
- Failing to include operational teams. Security, engineering, privacy, legal, procurement, and business owners may each identify different dependencies.
- Accepting vague incident language. Define notification triggers and contacts before an event occurs.
- Overweighting a logo or ranking. A directory listing or industry recognition does not replace product-specific due diligence.
- Ignoring purchased-tier limitations. Confirm that the controls evaluated are included in the proposed plan and contract.
- Leaving exceptions undocumented. Record the gap, affected asset, compensating control, owner, acceptance authority, and expiration date.
When to revisit
Vendor due diligence is a lifecycle activity, not a one-time procurement form. Revisit the assessment before seasonal planning cycles, annual renewals, major architecture changes, and changes to workflows or tools. Also trigger a review when the vendor changes ownership, service scope, hosting location, subprocessors, authentication model, incident history, pricing structure, or compliance evidence.
At minimum, schedule a periodic review that matches the vendor’s risk. High-impact providers may need more frequent evidence checks than low-impact tools. Reassess immediately after a material security incident, a significant control exception, or a change in the data handled by the service.
Before the next review, update the evidence table rather than starting from zero. Confirm that each prior answer still applies, close expired exceptions, request new reports or attestations, and compare actual service use with the original scope. If your identity or remote-access architecture changes, revisit related ZTNA vendors and access-control requirements. If hosting or domain workflows change, repeat the relevant infrastructure and account-protection checks.
Practical next step: copy the 40 questions into your procurement or risk system, add the evidence-tracking columns, mark five to ten non-negotiable requirements for the service, and assign an owner to every open item. Approve the vendor only after decision-makers can see which controls are verified, which risks are accepted, and what will be reviewed next.
