Keel

How should a small SaaS answer an enterprise security questionnaire?

By the Keel team · Last checked · 4 min read

Short answer

Answer an enterprise security questionnaire with short, true statements backed by evidence: describe the controls you actually run, attach proof such as access policies and restore test results, and say plainly where something is planned rather than done. Many small SaaS companies win early enterprise deals this way before they have SOC 2. AWS's own SOC 2 report covers AWS's controls, not yours.

Why do enterprise customers send security questionnaires?

Enterprise buyers send security questionnaires because they are responsible for the data they give to suppliers, including you.

The questionnaire is how their security team checks that you protect that data well enough, and it is often the step that decides whether a deal closes this quarter or stalls.

Questionnaires vary in length, from a few dozen questions to several hundred, but they keep asking about the same areas.

What do enterprise security questionnaires usually ask?

Security questionnaires usually ask about access control, encryption, backups and recovery, change management, patching, incident response, subprocessors and written policies.

Common questionnaire areas and the evidence that answers them
AreaWhat they want to knowEvidence that helps
Access controlWho can reach production and customer dataIAM policy summary, MFA enforced, access review log
EncryptionData encrypted in transit and at restTLS settings, RDS and S3 encryption settings
Backups and recoveryCan you recover, and how fastBackup schedule, latest restore test result, RPO and RTO
Change managementHow code reaches productionPull request reviews, CI checks, deploy logs
Vulnerability managementHow you patchDependabot or scanner reports, patch cadence
Incident responseWhat happens when something goes wrongA written incident process and contacts
SubprocessorsWho else touches the dataList of providers and their locations
PoliciesDo you have them written downInformation security policy, acceptable use, data retention

How should a small SaaS answer a security questionnaire?

Being small is not a reason to fail a questionnaire. Being vague is. Security reviewers mostly look for honesty, consistency and evidence.

  1. Keep a master answer document and reuse it, so every questionnaire says the same thing.
  2. Answer each question in one or two plain sentences. Do not paste marketing copy.
  3. Attach evidence where you can, such as a screenshot of MFA enforcement or a restore test report.
  4. Mark anything not yet in place as planned, with a date. Reviewers prefer that to a stretched yes.
  5. Point to your cloud provider's reports for physical and infrastructure controls, and explain what you own on top.
  6. Offer a call with your CTO for the questions that need context.

Two pieces of evidence carry unusual weight for small teams: proof that backups actually restore, and proof that every production change is reviewed. Both are cheap to produce if your pipeline and backups are set up properly.

Do we need SOC 2, or is a security questionnaire enough?

Many small SaaS companies close their first enterprise customers with a well-answered security questionnaire and no SOC 2 report.

A questionnaire is enough when

  • Your buyers accept a questionnaire and a call with your CTO.
  • You have only a handful of enterprise deals a year.
  • Your controls are real but not yet audited.

Starting SOC 2 is worth it when

  • Buyers list SOC 2 as a hard procurement requirement.
  • Answering questionnaires one by one takes more time than an audit would.
  • You are entering markets where an attestation is expected.

SOC 2 becomes necessary when buyers make it a hard requirement in procurement, or when answering questionnaires one by one takes more time than an audit would. If most of your prospects are UK organisations, ask whether Cyber Essentials is expected too.

SOC 2 is an attestation report produced by an independent auditor under the AICPA's framework, and it takes preparation and an observation period, so it is worth starting before it blocks a deal rather than after.

Does AWS's SOC 2 report cover our company?

No. AWS's SOC 2 report covers the controls AWS runs, such as its data centres, hardware and the services it operates.

It does not cover how you configure AWS or run your application. Under the AWS shared responsibility model, AWS is responsible for security of the cloud, and you are responsible for security in the cloud.

You can download AWS's SOC reports through AWS Artifact and reference them in your answers for the infrastructure layer. For everything above that, such as IAM, encryption settings, backups and application security, the questionnaire is asking about your controls.

How do you make the next security questionnaire faster?

Make the next questionnaire faster by keeping infrastructure in code, saving restore test reports, reviewing every change, enforcing MFA and keeping one living answers document.

  • Keep infrastructure in code, so you can show exactly how things are configured.
  • Run restore tests on a schedule and keep the reports.
  • Require pull request review for every production change, including infrastructure.
  • Enforce MFA and review access every quarter.
  • Keep a living answers document, owned by one person.

Each of these is good practice anyway. Done once, they turn a week of questionnaire work into an afternoon.

Is your small SaaS ready for an enterprise security review?

Tick each item you could show a reviewer today.

  • MFA is enforced on AWS and GitHub.
  • A restore test report from the last 90 days.
  • Every production change goes through a reviewed pull request.
  • A written incident response process with contacts.
  • A list of subprocessors and where they process data.
  • One master answers document that someone owns.

Decision point: Five or six ticks: most questionnaires take an afternoon. Four or fewer: close those gaps before the next big deal reaches security review.

Sources

  1. AWS, SOC compliance FAQs (checked October 2026)
  2. AWS, Shared Responsibility Model (checked October 2026)
  3. AWS Artifact (checked October 2026)
  4. AICPA, SOC 2 reporting on controls at a service organization (checked October 2026)
  5. NCSC, Cyber Essentials (checked October 2026)

Keep reading

Keel is an AWS release and recovery operations service for SaaS teams of 3 to 15 developers, provided by Bargainn Services Ltd, a UK company registered at Companies House (16497746). Registered office: 3rd Floor, 86-90 Paul Street, London, EC2A 4NE, United Kingdom.