Your first enterprise security review: what to prepare before it starts

Your first enterprise prospect likes the product. Then someone from their procurement or security team joins the thread and asks for a few things: a security questionnaire, your policies, maybe a SOC 2 report. The deal now waits on you.

Most small SaaS teams meet this moment unprepared, and lose a week or two finding documents and agreeing on answers. You can do most of that work before the request arrives. This guide covers what to prepare, in order, and what to do when you don't have something yet.

What the reviewer actually needs

The person reviewing you is rarely trying to find a perfect vendor. They need to record that they understood the risk of sending their company's data to you, and that the risk is acceptable or has a plan. Clear, honest, consistent answers help them do that. Polished but vague answers make their job harder.

So the goal of preparation is not to look bigger than you are. It is to be able to say what you do, show where it is written down, and say plainly what you don't do yet. Our guide to vendor security assessments explains the review process from the buyer's side.

1. Write a one-page company security summary

Start with the facts every questionnaire asks for, in one place:

• Where customer data is hosted (provider and region)
• What data you store, and what you don't
• Encryption in transit and at rest
• How customers' data is kept separate from each other
• Who on your team can access production, and how that access is controlled
• The third-party services that process customer data (your subprocessors)
• A named security contact and an email address that someone actually reads

This page alone answers a surprising share of a typical questionnaire. Keep it factual and dated, and update it when something changes.

2. Put your core policies in writing

Reviewers ask whether a policy exists, then often ask for a copy. A small company does not need a binder. It needs short documents that describe what you really do. The ones that come up in almost every review:

• Information security policy: the overall approach and who owns security
• Access control: how accounts are created and removed, multi-factor sign-in, least privilege
• Incident response: who does what when something goes wrong, and how customers are told
• Data retention and deletion: how long you keep data, and how a customer gets it deleted
• Vendor management: how you choose and review the services you depend on
• Secure development: code review, dependency updates, how changes reach production

Write them to match reality. A policy that promises quarterly access reviews you never do is worse than no policy, because the next question asks for evidence. For incident response, NIST's guide (Special Publication 800-61) is a free, widely recognised reference to shape yours.

3. Collect evidence for the controls you claim

Questionnaires increasingly ask for proof, not just a Yes. Before a review starts, know where you would find:

• A screenshot or export showing multi-factor sign-in is required for your admin accounts
• Your list of people with production access
• Your dependency or vulnerability scanning settings
• Your backup settings, if you claim backups
• Your most recent penetration test summary, if you have one

If you can't produce evidence for something, treat it as a gap and answer accordingly. Our guide to the penetration test question shows how to answer honestly when you haven't had one.

4. Decide how you'll answer the hard questions

A few questions decide how a small vendor's review goes. Agree on the answers once, before you are under deadline pressure:

• Do you have a SOC 2 report or ISO 27001 certificate? If not, say so and describe what you do instead. See the SOC 2 question.
• Have you had an independent penetration test?
• Do you use AI on customer data, and is it used to train models?
• Do you carry cyber insurance?
• How quickly will you tell customers about a breach?

For each, write the answer down with its source, and get the person who owns that area to agree with it. Consistency matters: the same question will come back from the next prospect, worded differently.

5. Publish the basics where buyers can find them

A short public security page saves time on both sides. It can cover hosting, encryption, data separation, subprocessors and how to report a vulnerability. Many companies also publish a security.txt file, a small standard file (RFC 9116) that tells researchers where to report security issues.

Only publish what is true today. Security reviewers read these pages closely, and they will ask about anything that doesn't match your questionnaire answers.

6. Start an answer library from day one

When the first questionnaire arrives, save every approved answer with its source. The second questionnaire will repeat most of the first one in different words, and you will start from checked answers instead of a blank cell. Our guide to building a security answer library covers how to set one up.

If you don't have everything yet

You will almost certainly have gaps. That is normal for a small company, and reviewers expect it. What matters is how you handle them:

• Say exactly what you have and don't have. Never round a “partly” up to a “yes”.
• Describe what you do instead, with specifics.
• If something is planned, only give dates you can stand behind. Answers can end up in contracts.
• Offer a call with the person who runs your engineering. A 30-minute conversation often settles what ten follow-up emails can't.

Our list of answers that invite follow-up questions shows the wording that tends to slow reviews down.

A one-week preparation plan

1. Day 1: write the one-page security summary.
2. Days 2 and 3: write or update the six core policies.
3. Day 4: collect evidence for each control you claim, and list your gaps.
4. Day 5: agree on answers to the hard questions, with their sources.
5. Later: publish a security page, and save every approved answer once the first questionnaire arrives.

When the questionnaire does arrive, our step-by-step guide to answering a security questionnaire takes it from there. If it comes as an Excel or CSV file, Rendro can draft the answers from the documents you prepared here, with a source for each, and mark anything they don't support for review.