The security work that unblocks an enterprise SaaS deal

The deal is agreed. Then it goes to security review and stops. Weeks pass, a spreadsheet arrives with four hundred rows, and an engineer who should be shipping is answering questions about cryptographic key rotation. The review is a documentation problem sitting on top of a real engineering problem, and the two need separating before either can be fixed.

The short version

An enterprise security review is trying to establish whether your failure becomes their incident. Everything on the questionnaire is a proxy for that. The work divides cleanly into things that are genuinely engineering — isolation, access separation, logging — and things that are genuinely writing: describing what you built so a stranger can assess it. Both are real. Doing the second without the first is the failure mode that ends careers.

Tenant isolation

Tenant isolation is the question an enterprise reviewer digs into, because it is the one where a failure exposes them to another customer’s incident, and the answer they want names the mechanism rather than asserting the outcome. “Customer data is logically separated” is not an answer. The answer names where the separation is enforced and what would have to go wrong for it to fail.

The strong version is enforcement at the lowest layer that can do it: a tenant predicate applied in the data access layer so that no query can be written without it, or row-level security in the database so that a missing predicate fails closed rather than returning everything. The weaker version — a filter applied in each handler by a developer who remembered — is the one that produces the access-control findings that sit at the top of the OWASP Top 10:2025.

Three follow-up questions a good reviewer asks, and you should ask yourself first: what stops a background job from crossing tenants; what stops an export or reporting path from crossing tenants, since those are usually written separately; and what does your test suite do if somebody removes the predicate. The last one has a satisfying answer available — a test that fails — and almost nobody has written it.

Administrative access and separation

Your staff can see customer data. Every reviewer knows this and what they want is the shape of the controls around it: who can, under what process, with what approval, and what record exists afterwards.

The credible position is narrow standing access, elevation for a reason with a time limit, and a log of elevation that somebody reads. The position that fails review is an engineering team where everyone holds production credentials because that is how the company started. Fixing it is neither expensive nor quick, which is why it belongs in the roadmap early.

The related question is support access: whether your support staff can impersonate a customer user, whether the customer can tell when they did, and whether the customer can switch it off.

Logging, and the customer’s forensic question

At some point a customer will have an incident of their own and ask you what happened in their tenant. Being able to answer that — who logged in, from where, what they changed, what was exported — turns a frightening conversation into an ordinary one.

Two design points make the difference. Logs need a tenant identifier on every event, or you cannot answer a question about one customer without reading everybody’s. And retention needs to be long enough to cover the gap between an incident happening and somebody noticing, which is measured in months rather than days.

Enterprise buyers increasingly ask for their own log export as a feature. Building it is the difference between answering the question once and answering it for every customer forever.

Sub-processors and where the data goes

Your suppliers are part of what the reviewer is buying. Maintain a list — each one, what it processes, where, and why — and publish it if you can. A maintained sub-processor list answers a dozen questionnaire rows on its own and signals that somebody is in control of the estate.

Two rows cause trouble more than the others. Data residency, when a customer requires processing in a named country and one of your suppliers does not commit to it. And model providers, when a feature sends customer content to a third party that the sub-processor list does not mention.

The evidence set

Four documents answer most of a review, and all four are writing rather than building.

An architecture description. What the system is, where data lives, what the trust boundaries are, and how tenants are separated. Two to four pages with a diagram.
Policies that describe what you do. Access control, change management, incident response, supplier management, and how personal data is handled. Short and true beats long and aspirational.
A test summary. When you last had a penetration test, what its scope was, and what remains open. What a finding looks like written up properly is the standard to ask your supplier for.
A dated roadmap. What is not in place yet and when it will be, with owners.

Assembled together these are the evidence pack, and the point of building it once is that the fortieth review costs an hour rather than a fortnight.

Answering the questionnaire

Every answer needs something behind it: a document, a configuration, a screenshot, a named owner. Keep the backing reference next to the answer in whatever you use to track them, because the follow-up question is always “can you show us”, and reassembling the evidence six weeks later is where the time goes.

Answer it honestly, say what compensates for it today, and give a date. A reviewer who catches an overstated answer discounts every other answer on the form, which costs far more than the single “no” would have. Reviewers are not looking for a perfect score; they are looking for a supplier who knows their own posture. An answer of “not yet, here is what we do instead today, here is the date” is read as competence. A “yes” that unravels under one follow-up question is read as something else.

When a formal artifact becomes unavoidable

Two situations. The buyer’s procurement policy requires one and the individual reviewer cannot waive it. Or you are answering the same review so often that producing the artifact is cheaper than answering the questions.

Until then, name the issuers accurately and say where you are. System and Organization Controls reporting is “a suite of service offerings CPAs may provide”; an ISO/IEC 27001 certificate comes from an independent body holding accreditation. Neither is something a supplier or a consultancy can produce for you, and the preparation that shortens the path is readiness. The two artifacts are compared in SOC 2 vs ISO 27001.

Not usually for the first one. A first enterprise deal is far more often unblocked by a clear architecture description, an honest questionnaire and a dated roadmap than by a report that will not exist for a year.

The AI section

Almost every enterprise questionnaire now has one, and it is usually the section answered worst, because it is answered by whoever is nearest rather than by whoever built the feature.

What is being asked, underneath the wording: does customer content leave your boundary, and to whom; is it used for training, by you or by a provider; what can the model reach on a user’s behalf; what stops one tenant’s content surfacing in another tenant’s answers; and what a wrong answer can cause. The reference list is the OWASP Top 10 for LLM Applications 2025, and how to answer the section properly is set out in answering the AI security questionnaire.

The sub-processor list is where most AI answers are quietly contradicted. If a feature calls a model provider, that provider belongs on the list, and a reviewer who finds it missing will re-read everything else.

Sequencing against a deal timeline

Working backwards from a signature rather than forwards from a framework: fix anything that would be a false answer, because that is the only category with no workaround. Write the architecture description, which unblocks the most rows for the least effort. Assemble the evidence pack. Answer the questionnaire with references. Then start the longer work, with a dated roadmap attached to the answer.

The engineering that most often has to happen first is isolation and administrative separation, because those are the two a reviewer will not accept a roadmap for. Getting the boundaries right before the deal is architecture work; keeping the whole programme moving between deals is what a named security owner is for.

A penetration test report can normally be shared with a prospect in redacted form under a non-disclosure agreement — scope, methodology, summary and remediation status, without the reproduction steps. Agree that permission with your testing supplier when you scope the engagement, not when the prospect asks.

How the work is bounded

The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.

SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.

Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.

Questions we are asked

Do we need SOC 2 before our first enterprise deal?

Can we share a penetration test report with a prospect?

What if we fail a question on the questionnaire?

What do enterprise reviewers ask about first?

Unblocking the review you are in

Send the questionnaire and a sentence about your architecture. The reply says which rows are engineering, which are writing, and which order they go in. More of our writing is indexed at writing.

Discuss a scope