The DDQ evidence-gap audit before year-end

The auditor is going to ask in February. The question will be some version of: “show me the evidence behind the claim you made on question 47.” If the evidence is a screenshot from 2023, a policy that was superseded in August, or a certification that lapsed in October, the answer reverts to unsupported.

Run the audit now. It takes an afternoon. It catches the regressions before somebody else catches them for you.

What the audit checks

Pull the library. For every DDQ answer used in the last three quarters, confirm three things.

The first is that the cited evidence still exists at the URL or in the document it was drawn from. Policies get reorganized. Wiki pages get renamed. The evidence you pointed to in June sometimes moves between then and December, and the pointer breaks silently. An evaluator who clicks the link and lands on a 404 does not write back asking where the policy went — they write back asking what else is broken.

The second is that the cited evidence still supports the claim. Policies get revised. A clause that read “encryption at rest via AES-256” in the May version of the policy sometimes reads “encryption via platform-default managed keys” in the November version. The cited answer is still in the library, pointing at the current policy, but the policy no longer supports the claim. This is the most common failure mode, and the hardest to catch without a line-level diff.

The third is that the claim is still true at the organizational level, independent of the library. Safe Security noted that vendors frequently recycle answers six to nine months past their validity — the answer survives in the library while the underlying capability has quietly regressed. Shelf’s broader point on outdated KB content applies directly: the library’s fluency is not the same as the library’s accuracy.

The 60-minute pass

1. Export the list of DDQ answers used more than twice in the last ninety days. This is the library’s working surface — answers used once are archive, answers used many times are load-bearing.
2. For each, open the evidence link in a new tab. Confirm the link resolves. Confirm the evidence text still contains the language the answer cites.
3. For each answer that fails one of those checks, tag it needs-refresh and route it to the owner. Do not delete it; a dangling answer is still better than a missing one, and the replacement needs a human to confirm the new language.
4. For answers that pass both checks, confirm with the domain owner — security, legal, finance — that the claim is still true. A three-sentence Slack message is enough.
5. Add an expiry date to every answer you reviewed. Ninety days from today. The next audit runs from the expiry list.

That’s it. The remaining work — updating the evidence, rewriting the answers — does not have to happen in the audit window. The audit produces a work queue. The queue gets worked in January, before the February auditor arrives.

What the audit does not do

It does not fix the underlying problem, which is that DDQ libraries rot the way every knowledge base rots, and rotation is a maintenance burden the audit makes visible but does not eliminate. We walk through the fuller answer in the DDQ response playbook: ownership, expiry, automatic freshness surfacing, evidence-pinned answers. The audit is the first-pass diagnostic. The playbook is the operating rhythm that makes future audits cheap.

The second thing the audit does not do is guarantee the next response will be correct. It catches the claims the library can no longer support. It does not catch new claims the library has not yet been asked. Those land in the next DDQ, as they always do, and the answer is that the library grows by one more row that needs an owner and an expiry date.

Run the audit this week. Not next week. The calendar compresses fast once the first Monday of December passes.