The enterprise IT security review is a sales stage. Answer it first.

For a company selling AI software into an enterprise, the security review is not a formality at the end of the deal. It is the stage where deals die, and it dies quietly: the questionnaire arrives, engineering starts writing answers it does not have, legal starts negotiating around gaps, and a two-week close becomes a two-quarter close. The review is answerable in advance. Almost nobody does it in advance.

The reviewer is not trying to establish whether you are secure in the abstract. They are trying to establish whether they can sign, and their signature is personal. That reframes everything: the currency of the review is not assurance, it is evidence: a document, a log sample, a policy, a report with a date on it. “We follow best practice” fails. “Here is the report, dated March, with the findings and their remediation” passes.

On an enterprise conversational intelligence platform for an AI startup, 25 security controls across seven areas were built or scoped in advance, penetration testing and AI red-teaming included. The effect was commercial rather than technical: the IT review became a document exchange instead of an engineering project, and it stopped setting the pace of the contract.

The currency of a security review is not assurance. It is evidence with a date on it.

Every enterprise has its own questionnaire and its own grouping, so treat this as the shape rather than the list. In our experience the questions cluster like this:

• Data residency and flow. Where does our data physically sit, which third parties does it pass through, and can it be kept in one region or inside our own infrastructure.
• Tenant isolation. What stops another customer's data reaching us, and is that enforced at the data layer or in the application.
• Identity and access. Who on your side can see our data, under what role, approved by whom, and how quickly is access revoked when someone leaves.
• Audit and retention. What is logged, for how long, who can alter it, and can we get an export.
• Model and data usage. Is our content used for training, does it leave for a third-party API, and what happens to prompts and outputs after the call.
• Subprocessors. The full list, what each one receives, and how we are notified when it changes.
• Independent verification. Penetration test, AI red-teaming, and the remediation record behind both.

Most of these are answerable on day one of a build. Several of them are not answerable at all after month four, which is the real subject of this post.

Take tenant isolation. If the application filters by customer in the query layer (every read remembering to add the tenant clause), then the honest answer is that isolation depends on every developer having been careful, forever. There is no evidence to hand over, and the fix is not a document. It is row-level security, a schema change, a migration and a re-test of every read path in the product.

The alternative costs almost nothing when it is a design decision. On a cross-border trade platform, the trust rules were enforced structurally: counterparty contact details withheld until a deal is confirmed, and funds released only on explicit administrator authorisation, both implemented at the database and permissions layer rather than in the interface. Enforced there, they are beyond the reach of any later UI change, and the answer to the reviewer's question is a schema, not a promise.

1. Get a real questionnaire before you design. Ask a friendly prospect for the one their security team uses. It is the most valuable requirements document you will receive, and it is free.
2. Turn it into a control list with owners. Each control gets a named owner, a state, and (the field that matters) the evidence artefact it produces.
3. Build the evidence-producing systems into V1. Role-based access, audit logs, a subprocessor register, a data-flow diagram. Retrofitting all four is a quarter; including them is a fortnight.
4. Book the penetration test and the red-teaming before the deal, not after. A test with findings and remediation dates is stronger evidence than a clean test nobody has seen.
5. Keep the pack current. One folder, versioned, owned by a person. The second enterprise deal should cost a day of security work, not another quarter.

Handled this way, security stops being the thing that slows the deal and becomes the thing that shortens it, because you are the vendor whose answers arrive complete. That is most of what enterprise self-hosting work consists of (starting from the IT review rather than arriving at it), and it belongs in the same Productionize phase as the accuracy and cost controls.