What Enterprise Buyers Require Before They'll Sign

A security questionnaire is a spreadsheet an enterprise sends before it will buy software — usually somewhere between forty and three hundred questions about how your product handles identity, access, data and failure.

It almost always arrives at the same moment: after a champion inside the company has decided they want your product, and before procurement will let them have it. Which means by the time you see it, the selling is done. What's left is proving you won't be the reason their security team gets called into a meeting.

This post is for the founder or engineering lead staring at the first one. It covers the eight things that come up on nearly every questionnaire, what each one actually means in code, and roughly what it costs to add later rather than now.

The questionnaire arrives after they've decided

That timing matters more than anything else here, because it changes what a gap costs you.

A missing feature during a sales demo costs you a feature request. The same gap on a security questionnaire costs you a deal that was already won, and it costs it slowly — the champion goes quiet, procurement asks for a timeline, and three months later someone else has the budget.

The good news is that the questions are remarkably consistent. Enterprises copy each other's questionnaires, and most are derived from the same handful of frameworks. Build for the common eight and you'll answer the majority of what any of them ask.

1 and 2. SSO and SCIM

What they're asking: can our employees sign in with our identity provider, and do accounts disappear when people leave?

These are two questions and they get treated as one, which is where teams get caught out. Single sign-on handles login. SCIM handles the lifecycle — creating, updating and deactivating accounts automatically from the customer's directory.

You can ship SSO and still fail the deprovisioning question, because an employee removed from Okta on Friday still has a live account in your product on Monday. The login is blocked. The account, its API tokens and anything it owns are not.

What it costs later: this is the single most expensive retrofit on the list, and the reason is tenancy rather than authentication. Enterprise SSO isn't one connection — it's one per customer, with configuration living in your database rather than your codebase. If your product was built assuming one login method and one user table, you aren't adding a feature. You're changing how identity works.

We've written the engineering version of this separately: SSO and SCIM covers tenant discovery, SAML versus OIDC, and the build-or-buy threshold.

3. Role-based access control

What they're asking: can we give different people different permissions, and can we prove who can do what?

Most products start with two roles — admin and user — because two roles are enough for a team of twelve. Enterprises aren't a team of twelve. They need a billing contact who can't see customer data, a read-only auditor, a team lead scoped to one department, and a security admin who can configure SSO without touching anything else.

The question behind the question is whether permissions are data or code. If adding a role means a deployment, you don't have role-based access control. You have hard-coded roles.

What it costs later: moderate on its own, severe in combination. Permissions touch every endpoint, so retrofitting means auditing every authorization check in the product — and the ones that were never written are invisible until someone goes looking. This is where the most dangerous class of multi-tenant bug lives, which we cover in multi-tenant SaaS architecture.

4. Audit logs their admins can read

What they're asking: if something goes wrong in our account, can we investigate it ourselves?

This is the most underestimated item on the list, and the misunderstanding is consistent. Teams answer "yes, we have logging" and mean application logs in a monitoring tool their DevOps team can query.

That is not what's being asked. The buyer wants their admins to see their tenant's activity, in your product, without filing a support ticket. Who logged in, who changed a permission, who exported data, who deleted a record, and when.

Three properties make an audit log usable to a customer rather than to you:

Tenant-scoped. Each customer sees their own events and nothing else. That sounds obvious and it's exactly the check that gets missed, because audit log queries are often written later, by someone assuming the filter happened upstream.

Immutable. An audit log that can be edited isn't evidence. Append-only, with no delete path exposed through the application.

Exportable. Large customers want events flowing into their own SIEM, which means an API or a scheduled export rather than a screen.

What it costs later: high, and for a reason that surprises people. Adding audit logging going forward is straightforward — you instrument the write paths and start recording. What you cannot do is produce history you never captured. The first time a customer asks "who changed this setting last March," the honest answer is that you don't know, and that answer is remembered.

5. SOC 2

What they're asking: has an independent auditor looked at how you run this?

SOC 2 is the one that causes the most confusion, so it's worth being precise about what it is and isn't.

It is not a law, a certification you buy, or a checklist you pass. It is a report produced by a CPA firm, examining your controls against the AICPA's trust services criteria — security, availability, processing integrity, confidentiality and privacy. Security is the only one every report includes; the rest are scoped in if they're relevant to what you do.

The distinction that affects your timeline:

Enterprises generally want Type 2, and Type 2 cannot be rushed, because the observation period is the point. You cannot buy your way to a shorter one.

What this means for engineering. Most of what an auditor looks for is built, not purchased: access control and least privilege, logging and monitoring, encryption in transit and at rest, a change management process with code review, dependency and vulnerability management, and backup and recovery you've actually tested. Compliance tooling can automate the evidence collection. It cannot create controls that don't exist.

What it costs later: the controls themselves are ordinary engineering if designed in. Retrofitting them is expensive mostly in calendar time — the Type 2 observation window starts when the controls start working, not when you decide you need a report.

One thing worth saying plainly: no vendor and no tool makes you SOC 2 compliant. Any company telling you otherwise is selling something. We build to what the criteria require and we'll tell you where an auditor will want evidence, but the report is between you and your auditor.

6. Data residency

What they're asking: where, physically, does our data live?

This one is binary in a way the others aren't. Either you can keep a customer's data in a specific region or you can't, and no amount of process documentation substitutes.

It comes up most with European customers, public sector buyers, healthcare, and financial services — and increasingly from US enterprises with European subsidiaries, who inherit the requirement.

The engineering reality is that residency is a tenancy decision wearing a compliance hat. A single shared database in one region can serve every customer right up until one of them needs their data somewhere else. At that point you need either region-aware routing with per-region data stores, or the ability to run a dedicated deployment for that customer — and which of those is feasible was decided when tenancy was designed.

Watch the edges too. Residency applies to backups, replicas, logs, analytics, and any third-party service you forward data to. A product hosted in Frankfurt that ships events to a US analytics vendor has not met the requirement.

What it costs later: the highest on this list, because it's the only one that can require a second deployment of your entire system.

7. A data processing agreement

What they're asking: will you sign a contract about how you handle our data, and who else touches it?

The DPA itself is a legal document, and your lawyer writes it. Two parts of it are engineering's problem.

The subprocessor list. Every third party your product sends customer data to — hosting, email, analytics, error tracking, AI providers, support tooling — has to be named, and customers expect notice before you add one. Teams routinely discover during this exercise that they have more subprocessors than they thought, because adding one takes about four minutes and no approval.

Deletion that actually deletes. The DPA will commit you to deleting customer data on termination, within a stated window. That means every system it reached: primary store, replicas, backups, search indexes, caches, analytics, and each subprocessor above. On a data model with soft deletes nobody mapped, that's a project rather than a setting.

What it costs later: low if your data flows are documented, genuinely painful if they aren't — and the way you find out is by trying to write the list.

8. An exit path

What they're asking: if we leave, can we take our data with us?

Nobody asks this during the honeymoon. Procurement asks it every time, because procurement's job is to avoid lock-in.

The direction of regulation is reinforcing it. The EU's Data Act, applicable since 12 September 2025, gives customers of data processing services a right to switch providers, obliges the provider to assist within a transitional period that the customer can extend and the provider must justify extending, and phases out switching charges entirely three years after the Regulation entered into force. If you sell into the EU, export stops being a goodwill feature and becomes an obligation.

What satisfies a buyer is narrower than it sounds. Not a migration service — a documented, self-serve export of their data in a structured format, covering the records that matter rather than a database dump nobody can read.

What it costs later: low to moderate, and it's the one item here worth building early for a selfish reason. A working export is also your backup verification, your customer-facing reporting feature, and the thing that makes a difficult renewal conversation less difficult.

Uptime, and what an SLA actually commits you to

Enterprises ask for an availability commitment with financial consequences. Before you sign one, three things are worth understanding.

The number is less important than the definition. What counts as downtime? Is a degraded response time an outage? Does scheduled maintenance count? Who measures it — you, them, or a third party? Two vendors offering "99.9%" can mean very different things.

Service credits are the usual remedy, and they're capped at a percentage of fees. That's standard and defensible.

You cannot commit to more availability than your architecture supports. If you run in one region with a single database and no tested failover, a four-nines commitment is a promise you'll break — and breaking it in writing is worse than not making it. Work out what you can actually hold, commit to that, and improve the architecture if the deal needs a better number. That's back-end architecture work with a contract attached.

The retrofit multiplier

Here's the framing worth taking away, because it turns a compliance list into a budgeting document.

Each of these items has two prices: what it costs to build while you're building everything else, and what it costs to add to a system that's already in production with customers on it. The second number is consistently several times the first, and the gap isn't the feature — it's everything the feature touches.

Which leads to the practical advice, and it isn't "build all eight."

Build the two that are structural: tenancy and identity. Everything in the high and highest rows traces back to those two decisions. A product where tenant is a first-class concept and identity configuration lives in data can add the rest incrementally, under deal pressure, without a rewrite.

Document the rest and answer honestly. "Not yet, and here's when" loses fewer deals than people fear. What loses deals is a yes that turns out to mean something narrower, discovered during implementation by the person who vouched for you.

If you're evaluating a development partner to build this, the same honesty test applies to them — the longer version is in 21 questions to ask a software development company.

Frequently asked questions

What is a security questionnaire, and why did we just get one?

It's a document an enterprise sends before purchasing software, asking how you handle identity, access, data and failure — typically forty to three hundred questions. You got one because someone inside that company wants to buy your product and procurement won't approve it until security signs off. The selling is mostly done; what's left is proving you won't create a problem for them.

Do we need SOC 2 to close an enterprise deal?

Often, but not always, and not always before signing. Some buyers accept a Type 1 report plus a committed date for Type 2, and some accept a completed questionnaire with evidence where a report would otherwise go. What's rarely accepted is having no answer. If SOC 2 keeps appearing in your pipeline, start the controls now — the Type 2 observation period begins when the controls start operating, not when you decide you need the report.

What's the difference between SOC 2 Type 1 and Type 2?

Type 1 examines whether your controls are suitably designed at a single point in time. Type 2 examines whether they actually operated effectively across a period of months. Type 2 is what most enterprises want, and it cannot be accelerated, because the observation window is the substance of the report rather than a delay in producing it.

What should an audit log contain, and who should be able to see it?

Who did what, to which record, when, and from where — covering logins, permission changes, data exports, and deletions at minimum. The part teams miss is the audience: the customer's own admins should read their own tenant's log inside your product, without asking you. Application logs in your monitoring tool answer a different question. The log also needs to be tenant-scoped, append-only, and exportable to the customer's own security tooling.

What is a DPA, and what does it require us to build?

A data processing agreement is the contract governing how you handle customer data. Your lawyer writes it; two parts land on engineering. You need an accurate list of every third party that receives customer data, with a process for notifying customers before you add one. And you need deletion that reaches every system the data touched — replicas, backups, search indexes, caches, analytics and each of those third parties. Most teams discover during this exercise that their subprocessor list is longer than they assumed.

What does data residency actually require us to build?

Either region-aware routing with separate data stores per region, or the ability to run a dedicated deployment for that customer. Which one is feasible was effectively decided when your tenancy model was designed. Note that residency covers backups, replicas, logs, analytics and any third-party service you forward data to — a system hosted in-region that sends events to an out-of-region vendor has not met the requirement.

Should we agree to an uptime SLA with service credits?

Credits capped at a percentage of fees are standard and reasonable. The number matters less than the definitions around it — what counts as downtime, whether degraded performance counts, how maintenance windows are treated, and who measures. The real constraint is architectural: don't commit to availability your current deployment can't deliver. Commit to what you can hold, and change the architecture if a deal needs a better figure.