DDQ fatigue is a security risk, not a productivity problem

This is an opinion piece. I think the industry’s standard framing of DDQ fatigue — that it is a productivity problem to be solved with more analysts and better templates — understates what is actually going on. DDQ fatigue is a security risk. Tired people writing security answers after hours on deadline produce answers that are wrong in ways that real auditors and real attackers can exploit.

I have heard a version of the following sentence from four different security leads in the last 12 months: “I approved an answer Tuesday night that I would not have approved Wednesday morning.” The sentence is always delivered with a shrug. The implicit frame is that shipping an iffy answer on a DDQ is a minor compliance irritation — a technicality the vendor-risk team will probably not notice. I think that frame is wrong.

What a wrong DDQ answer actually is

A DDQ answer is a written representation of a security posture. It is not marketing copy. It is a statement — attested in writing, often by name — about what the vendor does and does not do. When an enterprise buyer onboards a vendor on the strength of a DDQ, the DDQ becomes part of the contractual surface. Misrepresenting a control in a DDQ answer is not the same as overpromising in a pitch deck. It is closer to misstating a material fact.

Three real examples from the last year, lightly anonymized.

Example one. A vendor answered “yes” to a question about MFA enforcement on all production access. The true answer was “yes for humans, exception carved out for service accounts.” That exception got mentioned in a follow-up call three months later, the buyer asked why the DDQ said unconditional yes, and the deal renegotiated around a new control requirement. The vendor did not lose the deal, but the relationship with the buyer’s security team never recovered.

Example two. A vendor answered “AES-256 at rest, key rotation every 90 days” — the KB said so. The KB block had not been updated in 14 months. The actual production environment had moved to KMS-managed keys with quarterly rotation, a change that was in most ways an improvement but was materially different from what the DDQ claimed. A pentest six months later found the mismatch. The vendor had to file an updated representation with every buyer who had onboarded them during the window.

Example three. A vendor answered “four-hour RTO” on a BCP question. The number was right for the primary region. The DR runbook actually had a longer RTO for the secondary region, documented in the playbook, never reflected in the DDQ. A buyer’s incident-response tabletop exercise caught the mismatch.

All three examples were the result of questionnaires answered in a rush. In example one, the SME had been asked to review 40 questions in an afternoon and approved in batch. In example two, the analyst used a stale KB block and nobody caught the version pin. In example three, the answer was pasted from a prior response that predated the DR architecture change.

Why the “productivity problem” framing is wrong

The default vendor narrative around DDQ fatigue is: we have a lot of questionnaires, the team is overworked, we need more tooling. True. Also incomplete.

The framing treats fatigue as a cost-of-business issue, which means the fix is to reduce the cost per questionnaire. Auto-fill 80% of the answers, ticket the rest, ship faster. That is the right tactical move, and we just shipped a pillar on it. But it is not enough on its own, because the productivity framing does not force the vendor to confront the security consequence of getting an answer wrong.

Compare two questions a GRC lead might ask:

“How do we answer this questionnaire faster?”
“How do we guarantee that every shipped DDQ answer is currently true of our actual environment?”

The first is a productivity question. The second is a security question. A tool can help with both. A workflow that only optimizes for the first will happily ship answers that were true three quarters ago. A workflow that optimizes for the second will refuse to ship answers that cannot be verified against current evidence.

We have tried to build the product around the second question. The freshness scoring layer, the evidence-vault requirement, the entailment verifier — all of it exists because the first question is not the important one. Speed is useful. Speed that degrades representation accuracy is not.

What “tired” produces

There is a specific set of errors that tired reviewers produce. They are the same errors a tired pilot produces — not spectacular failures, but drift on the low-severity controls that individually do not matter and collectively shift the vendor’s posture.

Yes when the right answer is “yes, with exceptions.” Exception language is exhausting. The shortcut is to answer the unconditional version.
Copy-paste from last quarter’s answer. The control changed; the answer didn’t.
Approval without reading. An SME batch-approves 40 answers; two of them describe a control that was deprecated six months ago.
Rounding numbers toward the buyer’s expectation. RTO is 5.5 hours; the buyer’s expected ceiling is 4 hours; the answer gets written as “four hours” because four hours sounds better.
Over-claiming maturity. “Yes, we have formalized the process” when the process is documented in a wiki that three people have read.

Every item on that list is the kind of thing a well-rested reviewer would catch. Every item is the kind of thing a sixth-hour reviewer waves through. The fatigue is not abstract. It is a specific degradation in judgment on a specific class of question.

What this means for how the team is staffed

If DDQ fatigue is a security risk, then the staffing question is not “how many analysts do we need to keep up with volume.” It is “what is the maximum number of DDQ answers a single reviewer can approve in a week without their judgment degrading.”

I do not know the exact number. I would guess it is lower than most regulated-vendor security teams admit. If 40 hours per questionnaire is Loopio’s average, and a reviewer is approving 10 questionnaires a week, the reviewer is saturating. Every hour past that baseline is producing answers of lower average quality than the first hour.

The operational move is to cap the load per reviewer and route overflow. That means staffing up. It also means being honest with the commercial side that a questionnaire will take the time it takes. A sales team that leans on the questionnaire team to turn a 300-question response around in 18 hours is producing security risk on behalf of the customer they are trying to sign.

Where I am less sure

I am not sure the buyer side fully understands this. Most enterprise vendor-risk teams treat DDQ answers as a shallow filter — something to clear before the “real” security review — and do not cross-check the answers against current evidence. If they did, vendors would be getting caught on the stale-KB-block problem more often, and vendors would be staffing accordingly. The fact that the stale-block problem mostly surfaces in tabletop exercises and not in vendor-onboarding screens is either a sign that buyers trust the vendor representation more than they should, or a sign that the cost of catching every drift is higher than the cost of accepting some.

I also do not know where the line is between “answer drift that is a representation problem” and “answer drift that is a fraud problem.” I think most of what I have described sits firmly on the representation side. There is probably a version of this that crosses into fraud when the misrepresentation is material and the vendor knew. I have not seen that happen in the cases I know about, and I hope I never do.

The main thing I want to push back on is the industry habit of framing DDQ fatigue as a staffing tax. It is not just a staffing tax. It is a quality tax on one of the most important written representations a vendor makes about their security posture. Treating it like anything less is cheap.