The Promises in Your Security Questionnaire Are Controls Now

Category: Customer Trust & Third-Party Risk Tags: customer trust, security questionnaires, contractual commitments, security addendum, breach notification, control ownership, evidence

The worst hour of an incident I ever worked had nothing to do with the incident. We were about ninety minutes into a service degradation, the technical picture was still forming, and someone from legal joined the bridge and asked how long we had to notify affected customers. The security team said seventy-two hours, because that is what the policy said. Legal said that some contracts committed us to twenty-four, and at least one enterprise agreement said twelve. Nobody on the bridge could say which customers those were, because the commitments lived in signed contract exhibits, and the contract exhibits lived in a repository the incident process had never touched. We spent the next hour doing document review instead of incident response. The clock we were actually being measured against had been running since the first alert, and we did not know its length.

That is what an unmanaged customer commitment looks like when it finally matters. Somewhere upstream, in a sales cycle nobody remembers, a question was answered and a clause was signed. It became a binding requirement on the organization at that moment. It just never became a control.

Every Answer Is a Representation

Start with what a security questionnaire actually is. It is not a marketing exercise and it is not a quiz. It is a set of written representations about how your company operates, made to a customer who is relying on them to make a purchasing decision, and increasingly attached by reference to the agreement that follows. When the response library says encryption at rest is enabled on all customer data stores, that is not a description of intent. It is a statement of fact that someone will eventually check.

The trouble is who answers them and under what pressure. A four hundred question due diligence request lands with a deal date attached, and it gets routed to whoever has capacity, which is rarely the person who owns the control being described. The answers get assembled from a response library, from a previous customer's completed questionnaire, and from a quick message to an engineer who replies between meetings. Every one of those sources is plausible. None of them is evidence. And the pressure runs one direction: a yes moves the deal, a no or a qualified answer invites a follow-up call, so the softest defensible answer wins. Multiply that across a few hundred deals and you have accumulated a large body of commitments that no one has ever read as a set.

The Commitments Live Where No Control Owner Looks

The structural problem is location. Customer security commitments end up scattered across at least four places, and not one of them is the control library. They are in completed questionnaires sitting in the sales tooling. They are in the trust center, published to the world. They are in contract exhibits: the security addendum, the data processing agreement, the service level schedule with its notification windows and its audit rights. And they are in the least visible place of all, the email where someone answered one more question to close the deal.

Meanwhile the people who actually operate the controls work from a different set of documents entirely. They work from the policy, the framework mapping, the audit program for whatever certification is in flight. Those documents describe the general posture of the company. They do not describe the specific promises made to a specific customer, which are frequently stricter. The general policy says notify within seventy-two hours. The enterprise contract signed last spring says twenty-four. Both are true. Only one of them is enforceable by a customer with a lawyer, and it is not the policy.

This is the same failure I described in the unified control library, where the same requirement expressed by four different frameworks turns into four disconnected pieces of work. Customer commitments are simply another framework, one with the sharpest teeth and the least structure. Nobody publishes them as a standard. Your customers assemble them one negotiation at a time, and the resulting requirement set is unique to you.

The Answer Was True in March

Then there is decay. A questionnaire answer is a point-in-time claim, and the response library that makes your team fast is the same mechanism that propagates a stale claim into every future deal. An answer written when a control genuinely worked gets reused for two years after an architecture change quietly retired it. The library has no expiry, no owner, and no link back to the evidence that justified the answer in the first place, so nothing in the process ever forces a recheck. The reuse rate is the point of a response library, and it is also exactly how a single wrong sentence reaches four hundred customers.

I have written before that a control that isn't tested is a hope, and the customer-facing version is worse, because the hope has been put in writing and signed. At least an untested internal control fails privately. An untested commitment fails in front of the counterparty who is holding the contract, generally at the moment they have the most leverage. The honest question to ask about any answer in your library is not whether it was true when written. It is when it was last verified against the running system, and by whom.

Make the Commitment a Row

The fix is unglamorous and mostly clerical, which is why it rarely gets done. Customer commitments have to become rows in the same register as everything else, with the same fields you would demand of any control requirement: what was promised, in what document, to which customers, who owns the underlying control, what evidence proves it, and when that evidence was last refreshed. Once commitments are rows, three things become possible that are impossible today.

You can find the strictest promise. Sort the notification obligations and the tightest window rises to the top, and that number, not the policy default, is the one that belongs in the incident runbook. The bridge should never be discovering its own deadline. You can find the orphans, the commitments that map to no control and no owner at all, which is the population that will fail an audit and the population most worth fixing first. And you can find the drift, the rows whose supporting evidence is older than the change that broke them, which is where a routine architecture decision silently turned a signed promise into a misstatement.

The scope question always comes up here, because a large company has thousands of these and nobody is going to inventory them all at once. Take the tiering discipline from vendor work and point it the other way: start with the contract exhibits for your largest customers by revenue, because that is where the strictest terms and the real audit rights live, then the standard security addendum that most deals sign unmodified, since one clause there applies across the whole book of business, then the published trust center, which is a commitment to everyone at once and the cheapest to keep accurate. The long tail of individually negotiated questionnaire answers comes last, and it can be sampled rather than enumerated.

The Moment It Gets Checked

These commitments get tested in three predictable places, and none of them is a comfortable time to start looking. The first is an incident, where the notification window is the only deadline that matters and it is contractual, not regulatory. The second is a customer audit, when someone exercises the right-to-audit clause nobody read at signing and asks you to demonstrate the specific control your questionnaire described, in their words rather than your framework's. The third is a renewal, where a customer's security team compares this year's answers against the ones you gave them last year, which is a consistency check most response libraries would fail if anyone ran it internally first.

The difference between organizations that handle those moments and organizations that improvise is not diligence or headcount. It is whether the promises exist as structured data somewhere a control owner can see them. That is the whole reframe. Customer trust is a revenue function on the way into a deal, and it becomes an operational obligation the moment the deal closes. Most programs are built entirely for the first half of that sentence, with a fast response process, a well-stocked library, and a good trust center, and nothing at all for the second half.

We eventually built the register I described, and the first pass found notification windows in four different lengths and a handful of commitments whose owners had left the company. The most useful artifact turned out to be a single line at the top of the incident runbook giving the shortest contractual notification window in force and the customers it covered. It took one afternoon to produce once the rows existed. It would have saved us an hour on the bridge, at the exact moment an hour was the most expensive thing we had.