The security questionnaire evidence checklist for B2B SaaS

Use the checklist against a real buyer review

A security questionnaire asks your company to make claims about real systems, people, contracts, and practices. The safest preparation is therefore an evidence inventory, not a polished bank of sentences. A previous answer can reveal recurring questions, but it cannot prove that the answer remains correct.

Use this checklist with one active questionnaire. Mark the evidence you already have, the owner who can confirm it, the product scope it covers, and the date it was last reviewed. When a requested control is unsupported, create a visible gap rather than searching for persuasive wording.

The aim is a compact source of truth that becomes stronger after each customer review. It does not need to resemble an enterprise compliance repository on day one. Start with the evidence needed for the current deal, then preserve the reviewed claims and citations that will help with the next buyer.

If your company has not completed an independent report, use the companion process for answering a security questionnaire before SOC 2. It explains how to separate the certification answer from the operational control questions that can still be supported with current evidence.

Record four facts for every evidence item

A file name is not enough. Every item needs an owner, scope, observation or approval date, and disclosure decision. Without these facts, a reviewer may reuse old material for the wrong product or send an internal record to a buyer without checking whether it is suitable for disclosure.

Scope should identify the legal entity, product, environment, region, workforce population, and customer-data categories that the evidence covers. A policy may apply company-wide. A configuration record may apply only to one production account. A penetration test may exclude a newly released service.

The date should describe what happened. Use approved on for a policy, observed on for a system setting, tested on for a recovery exercise, and covered period for an independent report. Avoid a generic updated date that hides whether the control itself was rechecked.

The disclosure decision separates internal proof from buyer-facing material. Public evidence can appear in a trust centre. Gated evidence may be shared after a confidentiality check. Restricted evidence should be summarised by an approved claim or reviewed in a controlled session. Sensitive internal records remain private even when they support an external answer.

• Owner: who can confirm accuracy and approve reuse.
• Scope: which entity, product, system, people, data, and region are covered.
• Date and type: when the requirement was approved, activity performed, or state observed.
• Disclosure: whether the item can be public, gated, summarised, or kept internal.
• Refresh trigger: which event, expiry, or operating change makes the item stale.

Company, product, and data scope

Buyers cannot evaluate a control until they know what service is being assessed. Create a short company and product profile that can be reviewed whenever the architecture, provider list, or data use changes. This profile should support answers across the questionnaire rather than being rewritten in each section.

Include the legal entity that contracts with customers, the products and environments in scope, the hosting model, primary processing locations, and the categories of customer information handled. Describe the main data flows from collection through storage, support access, sharing, retention, deletion, and backup.

Keep a current architecture diagram and a written data-flow note. The diagram should name important system boundaries and external providers without exposing secrets or exploitable detail. The note should explain why information moves between those systems and which controls apply at each stage.

Record material exclusions. A mobile application, acquired product, regional environment, or experimental AI feature may follow a different path. Reviewers need to see those limits before they approve a claim that appears to cover the entire service.

• Legal entity, product names, service description, and accountable security contact.
• Architecture diagram, data-flow description, asset inventory, and environment boundaries.
• Customer-data categories, processing purposes, data subjects, locations, and retention periods.
• Hosting providers, subprocessors, integrations, and customer-managed components.
• Public privacy, security, availability, and support statements checked against current practice.
• Known exclusions, beta features, regional differences, and customer-specific configurations.

Governance, ownership, and risk evidence

The NIST CSF 2.0 resources for small businesses organise cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond, and Recover. You do not need to reproduce the framework inside every questionnaire. Use it as a completeness check for the responsibilities and operating evidence behind your answers.

Governance evidence shows who makes security decisions, how risks are recorded, and how policy exceptions are approved. A small company may assign several responsibilities to the same founder or engineering leader. That can be accurate, provided ownership is explicit and high-risk decisions receive appropriate review.

Maintain a current risk register with named treatment owners and review dates. Link questionnaire gaps to the same risk process when the missing proof represents a genuine control weakness. Do not create a separate fictional programme simply because a buyer asks for a maturity artefact.

Policies should describe requirements the company actually intends to follow. Record approval, owner, audience, review schedule, and exceptions. A document copied from a template but unknown to the team is weak evidence and may create commitments that operations do not meet.

• Security ownership, reporting line, responsibilities, and decision authority.
• Risk assessment method, current risk register, treatment decisions, and accepted exceptions.
• Approved security, privacy, access, development, incident, resilience, and supplier policies.
• Security awareness material and completion records for the relevant workforce population.
• Policy approval, acknowledgement, exception, and periodic-review records.
• Leadership review evidence appropriate to the company's size and governance model.

Identity, access, and personnel evidence

Access questions often contain several claims: unique accounts, least privilege, multi-factor authentication, joiner and leaver handling, periodic review, privileged access, and support access to customer data. One identity-provider screenshot rarely supports all of them.

Keep the approved access policy beside current operating records. Useful records include an account inventory, role definitions, a sampled access request, a completed leaver workflow, the latest privileged-access review, and point-in-time observations of authentication settings. Remove or redact personal information before any external disclosure.

Distinguish workforce access from customer authentication. A statement about employee single sign-on does not support a statement about end-user authentication. Distinguish the main production platform from support, source-control, monitoring, and administrative providers as well.

If contractors or service providers can access systems, document the approval, authentication, confidentiality, and removal process that applies to them. Do not describe a control as universal when one population follows a separate procedure.

• Access-control and authentication policy with current role definitions.
• User and privileged-account inventories for systems in scope.
• Joiner, mover, leaver, access-request, and emergency-access records.
• Most recent user-access and privileged-access review with exceptions tracked to closure.
• Point-in-time evidence of multi-factor authentication and central identity settings.
• Screening, confidentiality, training, and contractor controls where applicable and lawful.

Secure development and technical operations evidence

Buyers commonly ask how code changes reach production, how vulnerabilities are found, whether systems are logged, and how encryption is configured. Answer these questions with both documented requirements and samples of operation.

For change management, retain repository settings, review requirements, protected-branch observations, a representative approved pull request, deployment records, and the process for urgent changes. State the systems and repositories covered. A setting observed in one repository should not be presented as company-wide proof.

For vulnerability management, record the tools or processes used, the assets covered, scan or test dates, severity rules, remediation owners, and exceptions. A penetration test and an automated dependency scan provide different evidence. Preserve the scope of each rather than combining them into a generic testing claim.

The FTC's business security guidance stresses sensible access, protection of sensitive information through its lifecycle, secure product development, service-provider oversight, and keeping controls current. Those themes are also recurring buyer-review domains, but the answer still needs evidence from your own systems.

• Secure-development and change-management requirements, code-review rules, and deployment approvals.
• Repository and pipeline observations covering branch protection, review, testing, secrets, and release history.
• Vulnerability scanning, dependency review, penetration-test scope, findings, remediation, and exceptions.
• Encryption design and point-in-time configuration evidence for data in transit, at rest, and in backups.
• Logging, monitoring, alert ownership, retention, and a sample of tested detection or escalation.
• Endpoint, network, cloud, and production-hardening evidence appropriate to the actual architecture.

Incident response, resilience, and recovery evidence

A policy can show that response and recovery responsibilities are documented. Buyers may also ask whether those plans have been exercised and whether backups can be restored. Keep the plan and the latest operating evidence together.

Incident material is sensitive. A buyer usually needs the approved process, notification position, exercise date, lessons tracked, and relevant service commitments. Raw incident records, internal communications, credentials, personal data, and exploitable detail should remain restricted unless a specific controlled review is approved.

For backups, record the data and systems covered, schedule, retention, access controls, encryption, restoration method, and latest successful test. A dashboard showing completed backup jobs does not prove that the service can be recovered within a stated objective.

Business continuity evidence should connect dependencies, recovery priorities, owners, communication paths, and test results. If recovery objectives have not been measured, do not turn internal aspirations into contractual promises.

• Incident-response plan, roles, contact process, severity model, and approved notification language.
• Latest tabletop or practical exercise with actions, owners, due dates, and closure evidence.
• Backup configuration, protected copies, retention, monitoring, and latest restoration result.
• Business-impact analysis or equivalent service-priority record appropriate to company size.
• Business-continuity and disaster-recovery plans with tested dependencies and communication routes.
• Documented recovery objectives, actual test results, exceptions, and remediation decisions.

Privacy, suppliers, and AI data-use evidence

Privacy answers should be grounded in current data flows, notices, contracts, product settings, and operating records. Gather the purposes for processing, lawful basis where relevant, data-subject handling, retention and deletion procedures, cross-border arrangements, and the providers that receive customer information.

Maintain a subprocessor register that names the service, purpose, data categories, locations, and review owner. Link each provider to its risk review and contractual safeguards. A vendor list without data-flow context does not answer how customer information is protected.

CISA's vendor risk template for smaller businesses is a useful source for the types of governance, security, resilience, and supplier questions that recur in assessments. Use it to check coverage, not as evidence that your own controls operate.

AI features require a specific data-use record. Identify each model or AI provider, the inputs supplied, outputs retained, training or improvement settings, geographic processing, human access, safety checks, deletion behaviour, and contractual terms. Confirm the current product configuration instead of relying on a provider's general marketing page.

Route statements about training, intellectual property, privacy, incident notification, and model use to the appropriate product, privacy, legal, and engineering owners. These answers can create commitments beyond ordinary technical descriptions.

• Privacy notice, processing inventory, retention schedule, deletion procedure, and request-handling evidence.
• Data-processing terms, transfer safeguards, confidentiality controls, and customer commitments.
• Subprocessor register, supplier reviews, contracts, monitoring, and offboarding records.
• AI system and provider inventory with purpose, data inputs, outputs, retention, locations, and owners.
• Verified AI training and product-improvement settings plus approved customer-facing wording.
• Model-change, prompt-change, human-review, testing, and incident processes appropriate to the feature.

Independent reports and assurance boundaries

Independent reports, certificates, and test results can be valuable evidence, but only within their stated scope and period. Record the assessor, report type, covered system, criteria, dates, exceptions, complementary customer responsibilities, and distribution restrictions.

Do not describe a penetration test as certification. Do not present a readiness assessment as an issued audit report. Do not apply a parent company's report to an uncovered subsidiary or a provider's report to your own controls. When the report excludes a feature or environment, carry that exclusion into the buyer answer.

The distinction between a document and stronger observation is explained in document-supported and system-verified evidence. Keeping those assurance methods separate prevents polished documents from being treated as proof of continuous operation.

Store gated reports privately and share them through an approved route. Keep a record of the version and recipient. A public summary can state the report type and covered period only after the wording and disclosure have been approved.

Convert the inventory into reusable approved claims

Once the inventory exists, do not copy whole documents into an answer bank. Extract small claims that a reviewer can assess. Each claim should contain one clear statement, exact source location, evidence version, scope, assurance method, owner, approval state, review date, and known limitations.

The practical model is to reuse approved evidence across security reviews while rechecking buyer context. Product, geography, contract wording, requested period, and evidence freshness can change whether a previously approved claim applies.

When two active sources disagree, stop reuse and resolve the contradiction. When evidence expires, block or downgrade dependent claims. When a reviewer changes a draft, record whether the reason was scope, stale proof, ambiguity, legal commitment, or simple wording. Those corrections reveal where the evidence library needs work.

Measure the library by useful outcomes: the share of buyer requirements supported by current approved evidence, the number of gaps found before export, reviewer correction reasons, time to resolve proof gaps, and the percentage of new questions satisfied by existing claims. Word count and raw article traffic do not measure whether the security-review process is becoming safer.

A governed security questionnaire automation process can retrieve these claims, assemble citations, and route exceptions. It should leave final approval with the person accountable for the statement and the buyer context.

A good checklist ends as an operating system, not a folder. Each buyer question should lead to an approved claim and evidence, a request for clarification, or an owned gap. That structure lets a lean team answer faster while keeping the final decision with an accountable person.