How to Answer Security Questionnaires: Templates for the 40 Questions You Always Get

The fastest way to fail a security questionnaire is to give an answer that does not match your actual controls. Procurement teams follow up. They ask for evidence. They sometimes run an independent assessment. A confident-sounding answer that you cannot back up with documentation is worse than an honest 'we are working toward this'.

Three maturity tiers used throughout this guide:

• Startup: Pre-SOC 2, likely using managed tools (AWS, Okta, Google Workspace), controls are present but not formally documented and audited
• Growth: SOC 2 Type II achieved or in progress, controls documented, access reviews running, IR plan written
• Enterprise: Multiple framework certifications (SOC 2, ISO 27001, PCI DSS), dedicated security team, automated evidence collection, security embedded in engineering processes

Building your answer library:

Copy answers that match your posture into a shared document (Notion, Confluence, Google Docs). Tag each answer with the date it was reviewed and the name of the person responsible for it. Review and update quarterly. Once you have 40-60 answers documented, 80% of any questionnaire becomes a copy-paste exercise.

Questionnaire automation tools (if you are doing this at volume):

• Hypercomply, Steerlab, Conveyor, Vanta Trust Center -- AI-assisted response tools that auto-populate answers from your answer library and pull evidence from your tech stack
• Average ROI: 16 hours per questionnaire reduced to 2-3 hours after the first setup investment

Q: How do you encrypt data at rest?

Startup: "All customer data is stored in [AWS RDS / Aurora / S3] with encryption at rest enabled using AES-256. AWS manages the encryption keys using AWS-managed KMS keys. Database backups are encrypted using the same KMS key."

Growth: "Customer data at rest is encrypted using AES-256. We use AWS KMS with customer-managed keys (CMKs) for production data stores. Our key rotation policy requires annual rotation, enforced via AWS KMS key rotation configuration. Encryption at rest is audited as part of our SOC 2 Type II assessment."

Enterprise: "All data at rest is encrypted using AES-256. We maintain customer-managed KMS keys with defined rotation schedules per data classification tier. Encryption key management is audited annually as part of our SOC 2 Type II and ISO 27001 audits. We provide evidence of encryption configuration upon request under NDA."

Q: How do you encrypt data in transit?

Startup: "All data in transit between clients and our servers uses TLS 1.2 or 1.3. We enforce HTTPS-only access via HSTS headers. Internal service-to-service communication within our VPC uses TLS for all external-facing calls."

Growth: "Data in transit is encrypted using TLS 1.2 minimum, TLS 1.3 preferred. We disable TLS 1.0 and 1.1 across all endpoints. Our TLS configuration is tested via Qualys SSL Labs. Internal service mesh communication within the cluster uses mTLS enforced via [Istio / Linkerd / AWS App Mesh]."

Q: Do you use end-to-end encryption for customer data?

Note: most SaaS products do NOT use true E2E encryption because the application needs to process the data server-side. Be precise.

Growth: "We use transport layer encryption (TLS 1.3) and encryption at rest (AES-256). We do not implement end-to-end encryption in the cryptographic sense, as our application processes customer data server-side to deliver the service. For customers requiring application-layer encryption of specific sensitive fields, we offer column-level encryption as a feature on our [Enterprise / Professional] tier."

Q: How do you manage encryption keys?

Growth: "Encryption keys are managed via AWS Key Management Service (KMS). Application-layer secrets (API keys, database passwords, OAuth credentials) are stored in AWS Secrets Manager with automatic rotation enabled for supported secret types. No secrets are stored in source code or environment configuration files in version control. We use pre-commit secret scanning hooks and GitHub push protection to enforce this."

Enterprise: "We maintain a formal key management policy aligned to NIST SP 800-57. Encryption keys are stored in FIPS 140-2 validated key stores. Key access is governed by IAM least-privilege policies, logged via CloudTrail, and reviewed quarterly. Customer keys are isolated per-tenant and never co-mingled."

Q: How do you control access to customer data?

Growth: "Access to production systems containing customer data is restricted to authorized engineering and operations staff. Access is provisioned via our IAM process and requires manager approval. All production access requires MFA. We conduct quarterly access reviews to validate that access remains appropriate, with revocation completed within 5 business days for any access identified as excessive or for departed employees."

Q: Do you enforce multi-factor authentication?

Startup: "MFA is required for all accounts with access to production systems, enforced via [Okta / Google Workspace / AWS IAM identity center]. We use authenticator app-based TOTP. MFA bypass is not permitted for production access."

Growth: "MFA is enforced for all employees via Okta with phishing-resistant MFA (FIDO2/WebAuthn) required for access to production and administrative systems. SMS-based MFA is disabled. MFA enforcement is verified quarterly as part of our access review process and documented in our SOC 2 Type II report."

Q: How long does it take to revoke access when an employee leaves?

Growth: "Our offboarding process is triggered by HR notification on the final day of employment. We target same-day deprovisioning of all system access, with a formal SLA of within 24 hours for production system access. Okta is our identity provider; deactivating the Okta account propagates to SSO-connected applications automatically. Access review evidence is maintained and reviewed by auditors as part of our SOC 2 Type II report."

Q: Do you use role-based access control (RBAC)?

Growth: "Yes. System access follows a least-privilege RBAC model. Roles are defined by job function and reviewed when responsibilities change. Application-level access uses defined role sets; administrative access requires separate privileged credentials managed through [CyberArk / BeyondTrust / Teleport] with session logging for all privileged sessions."

Q: How do you handle privileged access?

Growth: "Privileged access (database administrator, cloud infrastructure administrator, production server access) is managed separately from standard user access. Privileged credentials require MFA, are issued on a just-in-time basis where technically supported, and all privileged sessions are logged. Standing privileged access is minimized; we use AWS IAM assume-role patterns to avoid long-lived privileged credentials."

Q: Do you conduct access reviews?

Growth: "User access to production systems and sensitive data stores is reviewed quarterly by each system owner. The access review process is documented, approvals are tracked in [Jira / ServiceNow], and any identified excessive access is revoked within 5 business days. Access review completion is verified as a control point in our SOC 2 Type II audit."

Q: Do you have an incident response plan?

Startup: "Yes. We maintain a documented incident response plan that covers detection, triage, containment, eradication, and recovery phases. The plan defines escalation paths, communication procedures, and roles and responsibilities. We conduct a tabletop exercise annually to validate the plan."

Growth: "Our incident response plan is documented, reviewed annually, and tested via tabletop exercises. It covers the full incident lifecycle per NIST SP 800-61. Our IR plan is referenced in our SOC 2 Type II report under the CC7 controls. We maintain relationships with an external IR retainer firm for forensic support in the event of a major incident."

Q: How quickly will you notify us of a security breach affecting our data?

Growth: "Our DPA and Master Services Agreement commit to notifying affected customers within 72 hours of confirming that their data was involved in a security incident. Notification includes: the nature of the incident, categories and approximate volume of data affected, likely consequences, and measures taken or proposed to address the incident. We maintain a designated security contact for customer incident notification."

Q: Have you had a data breach in the last 3 years?

This question requires an honest, factual answer. If you have had a confirmed breach:

Example with prior incident: "[Company] experienced a [brief description of incident type] in [year]. Upon detection, we [summarize response: contained, notified, remediated]. Affected customers were notified within [timeframe]. We conducted a full post-incident review and implemented the following controls to prevent recurrence: [list controls]. A summary of the incident and remediation is available under NDA upon request."

If no breach:

Growth: "[Company] has not experienced a confirmed data breach affecting customer data in the prior 36 months. We maintain a security incident register of all security events; no event during this period resulted in unauthorized access to customer data."

Q: What is your mean time to detect (MTTD) and mean time to respond (MTTR) for security incidents?

Growth: "Our security monitoring generates alerts routed to our on-call rotation 24/7. For critical alerts, our target response time is 15 minutes. Our SIEM correlation rules are tuned to minimize false positives. We report MTTD and MTTR as metrics in our quarterly security program review; our current MTTD for high-severity alerts is [X hours] and MTTR is [Y hours] based on the trailing 12 months."

Q: Do you conduct penetration testing?

Startup: "Yes. We conduct an annual external penetration test performed by an independent third-party firm. The scope covers our production web application, API endpoints, and cloud infrastructure. A summary of findings and remediation status is available under NDA upon request."

Growth: "We conduct annual full-scope penetration tests performed by an independent third-party firm. We also perform application security testing for major feature releases. Critical and high findings are remediated within 30 days and 90 days respectively. Penetration test executive summaries are available under NDA; our SOC 2 Type II report references our penetration testing program as a CC7 control."

Q: How do you manage vulnerabilities?

Growth: "We operate a formal vulnerability management program. Automated vulnerability scanning runs on all production infrastructure on a [weekly / biweekly] cadence. Findings are triaged and assigned remediation SLAs by severity: Critical = 14 days, High = 30 days, Medium = 90 days. SLA compliance is tracked as a security KPI reported to leadership monthly. Our vulnerability management program is audited as part of our SOC 2 Type II assessment."

Q: How do you handle vulnerabilities in third-party dependencies?

Growth: "We use [Snyk / Dependabot / GitHub Advanced Security] to continuously scan application dependencies for known CVEs. New critical vulnerabilities in dependencies are flagged within [timeframe] and evaluated for exploitability in our environment. Our CI/CD pipeline fails builds that introduce new critical dependency vulnerabilities, preventing them from reaching production."

Q: Do you have a bug bounty or responsible disclosure program?

Growth: "We maintain a responsible disclosure policy published at [URL]. Security researchers who discover vulnerabilities may report them via [email/platform]. We commit to acknowledging submissions within [48 hours] and providing status updates throughout the remediation process. We do not pursue legal action against researchers acting in good faith."

Q: Do you have SOC 2 Type II?

Startup (pre-SOC 2): "We are currently in the process of achieving SOC 2 Type II certification. Our observation period began [date], and we expect to receive our first Type II report in [quarter/year]. We are using [Vanta / Drata / Secureframe] to manage control evidence. In the interim, we are happy to complete this security questionnaire and/or provide a self-assessment against the AICPA Trust Service Criteria."

Growth (SOC 2 achieved): "Yes. [Company] has achieved SOC 2 Type II certification under the AICPA Trust Service Criteria for Security and Availability. Our most recent report covers the 12-month period ending [date] and was audited by [auditor firm]. We are happy to share the report under a mutual NDA."

Q: What compliance frameworks do you adhere to?

Growth: "We are certified under SOC 2 Type II (Security and Availability criteria). We align our controls to the NIST Cybersecurity Framework 2.0 and CIS Controls v8. [If applicable: We are also HIPAA compliant / PCI DSS Level 2 compliant / ISO 27001 certified.] Documentation is available under NDA upon request."

Q: How do you vet your sub-processors and third-party vendors?

Growth: "We maintain a vendor risk management program. All vendors with access to customer data or production systems are assessed before onboarding using our standard vendor security questionnaire. Vendors are tiered by risk (Critical / High / Medium / Low) and reviewed on a cadence aligned to their tier. Our list of sub-processors is published at [URL / available upon request] and is updated when sub-processors are added or removed. We notify customers of material sub-processor changes per our DPA."

Q: How do you handle security in your software development lifecycle?

Growth: "Security is integrated throughout our SDLC. We conduct threat modeling for major features, require code review by a second engineer for all production changes, run SAST scanning (Snyk / GitHub Advanced Security / Semgrep) in CI/CD, and conduct application security testing prior to major releases. Security training is required annually for all engineers. Our secure SDLC controls are audited as part of our SOC 2 Type II CC8 assessment."