Governance and ownership
Executive accountability, applicable obligations, risk exceptions, service risk assessment, and shared responsibility.
Free editable CSV
50 evidence-first questions
Ask vendors for evidence before asking for reassurance.
This product-neutral security questionnaire turns 50 common technology due-diligence questions into an evidence collection worksheet. Use it to compare what a vendor says, what the service actually supports, what the contract commits to, and which gaps your organization would still own.
No email gate. Do not place passwords, secrets, protected records, personal data, security-sensitive architecture details, or confidential vendor material into public or unapproved systems while completing the worksheet.
- Evidence over adjectives“Enterprise-grade” is not a control description.
- Scope every answerA strong control outside the purchased service does not reduce your risk.
- Separate feature from contractA demo capability is not necessarily an enforceable commitment.
- Preserve exit optionsSecurity includes the ability to recover data and leave safely.
Due diligence method
Turn a questionnaire into a decision record.
The worksheet is designed for procurement, security review, architecture review, renewals, and material service changes. It is not a pass/fail certification. The goal is to expose what you know, what the vendor can prove, what remains uncertain, and who owns the residual risk.
- 01
Define the service boundary.
Document the exact product, edition, hosting model, data categories, integrations, privileged workflows, user populations, and intended use. A vendor may have excellent controls that do not apply to the service you are actually buying.
- 02
Ask the same core questions.
Use a common baseline so competing vendors are not evaluated through completely different evidence. Add organization-specific requirements rather than replacing the baseline with ad hoc sales questions.
- 03
Request inspectable evidence.
For material controls, ask for the policy, architecture, test result, assurance report, configuration guide, sample log, contract clause, or other artifact that supports the answer. Sensitive evidence can be reviewed through appropriate protected channels.
- 04
Record limitations.
Capture exclusions, pricing-tier dependencies, customer configuration duties, compensating controls, unresolved findings, and roadmap promises. A qualified “partially” can be more useful than an unsupported “yes.”
- 05
Make residual risk explicit.
Assign gaps to a named owner and decide whether the response requires remediation, contract language, a compensating control, an exception, or rejection. Do not let a completed spreadsheet become automatic approval.
50 security questions
Ten review areas that connect product security to operational risk.
The downloadable CSV contains five questions in each area. Every row includes why the question matters, evidence to request, a suggested internal owner, a risk prompt, and editable status and notes fields.
Identity and access
SSO, MFA, vendor privileged access, least-privilege roles, dormant users, service accounts, and credential lifecycle.
Data protection and privacy
Data inventory, encryption, key governance, retention, deletion, backups, residency, and cross-border processing.
Secure development
Secure SDLC, threat modeling, security testing, CI/CD secrets, production changes, and rollback.
Infrastructure and cloud
Architecture, segmentation, administrative paths, infrastructure as code, hardening, and tenant isolation.
Logging and detection
User and admin events, customer audit access, privileged vendor actions, tamper resistance, retention, and alerting.
Vulnerability management
Discovery coverage, remediation timelines, dependency monitoring, penetration testing, and vulnerability disclosure.
Incident response and resilience
Incident plans, customer notification, RTO/RPO, backup isolation, restore tests, and forensic preservation.
Third parties and supply chain
Subprocessors, supplier risk, dependency provenance, subprocessor changes, and contractual flow-down controls.
Assurance, evidence, and exit
Independent reports, due-diligence packages, export capability, termination deletion, and contractual security commitments.
Evidence model
Not all “yes” answers are equivalent.
Use evidence strength to decide how much confidence an answer deserves. The worksheet deliberately asks for artifacts because the same sentence can describe very different control maturity.
- 0
- Unsupported. The vendor provides a marketing statement or verbal assurance with no usable description or evidence.
- 1
- Documented. A current policy, architecture, configuration guide, or control description supports the answer, but operating effectiveness is not independently demonstrated.
- 2
- Demonstrated. The vendor can show implementation evidence such as configuration, logs, test output, restore results, or operating records relevant to the service.
- 3
- Independently assured. Appropriate independent testing or assurance covers the relevant control and service scope, with exceptions and dates available for review.
- C
- Contractually committed. The requirement is enforceable through the contract, DPA, security addendum, SLA, or other binding term where contractual treatment is appropriate.
Review red flags
Pay attention when the answer is technically true but operationally incomplete.
Security reviews often fail at the boundary between a general corporate control and the exact service a customer will depend on. These patterns deserve follow-up rather than automatic rejection or acceptance.
- Certification without scope. A logo or certification name is provided, but the vendor cannot show whether the report covers the product, environment, period, and controls relevant to the purchase.
- Roadmap as control. A missing capability is described as planned, but there is no current compensating control, date, contract commitment, or decision about the gap.
- Feature-tier ambiguity. Security functionality demonstrated during evaluation requires an edition, add-on, or configuration that is not included in the commercial proposal.
- Customer-responsibility silence. The vendor says a control is supported but does not explain the settings, monitoring, key management, identity lifecycle, or operational work the customer must perform.
- Backups without restore proof. Backup frequency is documented, but there is no evidence that the complete service state can be restored within the promised recovery objective.
- Export without usability. The vendor offers a data export but cannot preserve attachments, relationships, metadata, audit history, or a usable schema needed for safe migration.
Primary references
Map the worksheet to the obligations that actually apply to you.
This resource is intentionally framework-neutral. The questions are informed by recurring control themes across established security guidance, but your organization should map them to its own laws, contracts, risk model, architecture, and assurance requirements.
NIST Cybersecurity Framework 2.0
Use CSF 2.0 to connect vendor review findings to governance, identification, protection, detection, response, and recovery outcomes.
Open NIST CSF 2.0NIST Secure Software Development Framework
NIST SP 800-218 provides a primary reference for secure development practices and software-producing organization responsibilities.
Open NIST SP 800-218CISA Secure by Design
Use CISA's Secure by Design guidance when evaluating whether a vendor shifts avoidable security burden to customers or treats safe defaults as premium extras.
Open CISA Secure by DesignOWASP ASVS
For application-focused reviews, OWASP ASVS can help teams translate high-level vendor answers into more testable application security requirements.
Open OWASP ASVS
Continue the evaluation
Security evidence is one part of a defensible software decision.
Use the questionnaire to expose security gaps, then carry the findings into the broader software evaluation scorecard, RFP requirements, migration readiness review, and decision brief. A vendor with strong security controls can still be the wrong operational fit—and a good workflow fit does not erase a material security failure.