Field Notes · Security Leadership August 21, 2026 · 6 min read

The security program changes when enterprise customers start asking questions.

The first serious enterprise security review changes what security is inside a company. Until then it is an engineering concern; afterward it is a revenue dependency and a stream of contractual representations. Most companies respond transactionally, answering each questionnaire as it arrives. That works at low volume and then fails in a specific, compounding way. This note describes the category change, the evidence that it has happened to you, why per-deal answering breaks, and the capability to build instead.

The category change

Enterprise procurement treats a vendor's security as a risk to be evaluated before money moves. The instruments are standardized enough to recognize on sight: security questionnaires, often derived from industry-standard sets such as the Shared Assessments SIG or the Cloud Security Alliance's CAIQ, requests for a SOC 2 report or ISO 27001 certificate, security addenda to the contract, breach notification clauses with defined clocks, audit rights, and insurance requirements.

Each instrument converts a security question into a commercial one. A questionnaire answer becomes part of the record the customer relied on. A security addendum becomes a contractual obligation with remedies attached. A breach notification clause becomes a deadline the company must be operationally able to meet. Before enterprise customers, a security weakness was an engineering risk. After, the same weakness may also be a misrepresentation, a breach of contract, or a lost renewal.

This is the category change: security stops being only a property of your systems and becomes part of what the company sells and promises. It happens on the customer's schedule, not yours, and it is usually well underway before anyone inside the company names it.

Evidence it has already happened to you

• Deals now include a security review stage, and the sales team treats its duration and outcome as unpredictable.
• Questionnaires are answered by whoever is available: an engineer, a founder, sometimes sales with engineering spot-checks. Nobody reads the full set of past answers.
• The same question receives different answers across customers, because each answer was written under deal pressure with the information at hand.
• Customer contracts carry security exhibits that legal negotiated individually, and no single document lists what the company has now promised, to whom.
• Engineering loses days to review support, and the interruptions arrive with deal deadlines attached.
• Somebody has proposed, or bought, a trust portal to make the answers look organized.

None of this indicates bad faith. It indicates a company answering governance-grade questions with a deal-desk process.

Why per-deal answering fails as it scales

The transactional approach has a failure mode that is easy to miss because it compounds quietly. Three mechanisms drive it.

Commitments accumulate without a ledger. Every questionnaire answer and security exhibit is a representation. Made one at a time, under time pressure, by different people, they diverge: from each other, and from the systems they describe as the product changes. The company's stated posture becomes a scatter of documents rather than a position. The gap between what was promised and what is true grows in the dark, and it is discovered at the worst possible time, typically during an incident, a renewal audit, or litigation, when someone reads the old answers next to the new facts.

Marginal cost stays high. A process that treats each review as novel pays the full cost every time: engineering hours, legal review, sales delay. Review load grows with customer count, so the cost curve is linear at best, and the interruptions land on the same few senior engineers.

Nonstandard requests get decided by nobody. Enterprise customers ask for things beyond the questionnaire: specific controls, audit rights, data residency, incident cooperation terms. Without an owner, each request is granted or refused by whoever is closest to the deal, which means the company's risk appetite is being set, one concession at a time, by its most deal-motivated people.

Where the accumulated commitments collide: an incident

The clearest way to see why the ledger matters is to walk the commitments forward to the day they are all invoked at once. A security incident triggers every notification clause the company has ever signed, simultaneously. If ten enterprise contracts carry breach notification terms negotiated individually, the company may owe notices on several different clocks, measured from different starting events (discovery, confirmation, determination of impact), through different channels, with different required content. Some clauses obligate notification for suspected incidents; others only for confirmed ones affecting that customer's data.

An incident response team that has to discover those obligations during the incident, by pulling contracts one at a time while the clock runs, is doing contract review at the worst hour of the company's year. The same collision applies to old questionnaire answers: statements made two years earlier about logging, encryption, or response capability become the baseline against which the company's actual incident performance is judged, by customers and, in the worst case, by opposing counsel. This is why the commitments register described below is not compliance bookkeeping. It is incident readiness, deal infrastructure, and litigation posture in one document.

The consequence for the accountable executive

For the CEO, security review performance is now a revenue variable: it moves close rates, cycle length, and renewal friction. For the GC, the accumulated answers and exhibits are the company's represented security posture, and consistency across them is a litigation and regulatory question, not an administrative one. For the CTO, the review stream is a permanent tax on engineering unless it is systematized. And for all three, the substantive question underneath is the one from the neighboring note: an audit artifact or a filled questionnaire does not by itself establish that anyone is making sound security decisions. Customers are, in effect, forcing the company to have a governable security posture. The choice is whether to build it deliberately or accrete it accidentally.

What to build instead

The durable response is a small set of capabilities, not a bigger pile of documents:

1. A single source of truth for posture. One maintained description of the company's actual security position: architecture, controls, known limitations. Every questionnaire answer derives from it. When reality changes, it changes, and the delta is visible.
2. A commitments register. Every security representation the company has made, by customer, in one place: questionnaire answers, security exhibits, notification clocks, audit rights. The GC can read it; renewal negotiations start from it; incident response consults it, because notification obligations live there.
3. Named ownership. One accountable owner for what the company says about its security and for deciding nonstandard requests. Sales escalates to that owner; the owner has authority to refuse commitments the company cannot keep.
4. Evidence that regenerates. Answers backed by artifacts produced continuously by normal operations (access reviews, logging, testing) rather than assembled per request. This is what turns review response from a project into a lookup.
5. A refusal position. Decided in calm conditions: which requests the company declines (unbounded audit rights, commitments beyond the architecture), and the standard alternative it offers. A refusal position is what makes yes meaningful.

Companies that build these five things convert the review stage from an unpredictable obstacle into a routine step, and, less obviously, they stop misrepresenting themselves by accident.

Boundary conditions

At low volume, the transactional approach is rational: if the company sees a handful of reviews a year, a capable engineer and a careful GC can handle them, and building capability ahead of demand is premature. The transition point is observable rather than theoretical: when review load interrupts engineering monthly, when two customers hold materially different answers to the same question, or when nobody can produce the list of notification obligations within an hour, the company is past it. A trust portal, for completeness, is a presentation layer; it usefully publishes the single source of truth if one exists, and it dresses up the scatter if one does not.

Conclusion

Enterprise customers change the security program's job description. The questions arrive as sales friction, but what they create is governance exposure: a growing body of representations that must stay consistent with each other and with reality. A company can meet that with a deal desk or with a capability. The deal desk holds until volume, inconsistency, or an incident finds the gap. The capability, five artifacts with an owner, costs less than it appears, because it replaces work the company is already doing expensively, one deal at a time.

Related: SOC 2 Is Not a Security Strategy, on why the audit these reviews request cannot substitute for the decisions they force.

← All Field Notes