up:: The Human & Organizational Side MOC
The Contradiction Audit
The contradiction audit is a governance exercise that enumerates every system encoding a cryptographic assumption, checks each one against the organization’s stated post-quantum position, and produces a list of contradictions with an owner against each. It exists because people read words as claims and systems as evidence, and where the two disagree the systems win. An engineer deciding this week whether migration work outranks a delivery commitment is reading the issuance system, the approved algorithm list, and the incident scorecard, and none of those has heard the announcement.
The short version:
- A stated commitment competes with every system that still encodes the old assumption, and the systems have consequences attached.
- The contradictions are enumerable, which makes this unusually checkable compared with most organizational work.
- The loudest one is almost always certificate issuance, because an issuance system still writing long-lived classical certificates contradicts every statement of urgency the program has made.
- The most damaging one is the security function’s own estate, because that is the first place engineers look.
- The output is a list with owners and dates, which makes it governance work rather than communications work.
Think of a hospital that announces a new hand-hygiene standard and then leaves half the dispensers empty. The announcement was sincere, the policy is on the wall, and the staff have learned what the institution actually requires by walking past the empty dispenser 40 times a week. Nobody decided to undermine the policy. The building simply kept saying something the memo did not.
Why do systems override announcements?
Because a system carries a consequence and an announcement carries an intention, and people calibrate on consequences.
This is not cynicism about employees. An engineer choosing between migration work and a delivery deadline is making a rational read of what the organization rewards, and the incident scorecard, the sprint commitment, and the approved algorithm list all answer that question with more authority than a slide did. When those answers contradict the stated position, the correct inference is that the organization has stated a preference and encoded a requirement, and the requirement is what binds.
The second effect is quieter and worse. A visible contradiction tells people the organization has not actually placed the bet, which makes it individually irrational for anyone else to place it either. That is how a program acquires a reputation for being something you can safely wait out, and reputations of that kind survive several rounds of renewed sponsorship.
What are the systems that usually contradict the position?
Six, in rough order of how loudly they speak:
| System | The contradiction it encodes | What resolving it looks like |
|---|---|---|
| Certificate issuance policy | Long-lived classical certificates still being issued today, each one extending the exposure past the stated deadline | A dated stop on classical-only issuance and a lifetime cap, per Declaring Classical Cryptography End-of-Life |
| Approved algorithm lists | Post-quantum algorithms absent, or present only via an exception process, so using them costs a team paperwork | The new algorithms listed as ordinary approved options, and the exception burden moved onto the classical ones |
| The incident scorecard | An engineer who touches working cryptography absorbs any resulting incident, and one who leaves it alone absorbs nothing | Migration work carved out of the availability metric for the teams doing it |
| Procurement and contract terms | Contracts signed with no algorithm-agility clause, locking in vendor-controlled surfaces for the length of the term | PQC language written into the standard terms, per PQC Procurement and RFP Language |
| Budget cadence | Annual funding reviewed against quarterly delivery tells everyone this is deferrable, whatever the deck says | Multi-year funding with the crossing named as its own line |
| The security function’s own estate | The team issuing the mandate has not migrated its own systems | Security’s estate crossed first, which is also the cheapest available real milestone |
Why is this more checkable in cryptography than elsewhere?
Because cryptographic assumptions are written down in machine-readable places rather than held as culture.
Most organizational consistency work is subjective, since you are assessing whether leaders behave in line with stated values. Here the assumption lives in an issuance template, a policy document with an algorithm list, a contract clause, and a metric definition. Each of those can be pulled, read, and compared against a one-page statement of position, and the comparison produces a finding rather than an impression. That makes the audit defensible in front of an internal audit function, and it makes the remediation assignable, which is what separates it from an engagement survey.
It also has a natural cadence. Run it once at the start of the program to produce the baseline, then again whenever the stated position changes, since a revised position creates fresh contradictions in systems nobody thought to update.
Why won’t your vendor tell you about this?
Because every item on the list is internal, and none of it is a product.
A vendor can supply the algorithms, the discovery, and the certificate tooling. Nothing they sell changes your incident scorecard, your budget cadence, or the exception process in your approved algorithm list, and those are frequently the binding constraints. Raising them would also mean telling a buyer that the obstacle sits in the buyer’s own governance, which is a harder conversation than a product gap and it does not close a deal.
There is a sharper version worth saying plainly. A vendor benefits from a program that keeps buying and never finishes, and a contradiction audit is one of the few exercises that reliably shortens the distance to completion.
What do you actually do about it?
- Write the position first, in one page. The audit compares systems against a stated position, so an unstated position produces an audit with nothing to check against.
- Pull the six artifacts and read them literally. The issuance template, the approved algorithm list, the metric definitions, a recent contract, the funding cycle, and an inventory of the security team’s own estate. Literal reading is the whole method, since the question is what the system says rather than what it was meant to say.
- Produce a list with 3 columns: the contradiction, the owner, the date it resolves. Anything without an owner and a date returns unchanged next quarter.
- Start with issuance and the scorecard. Issuance is the loudest and most visible, and the scorecard is the one quietly punishing the exact behavior the program is asking for.
- Publish the resolved list internally. The audit’s second effect is the useful one: engineers who watch a contradiction get fixed update their read on whether the organization has actually committed.
Common misconceptions
- “This is a communications problem.” The systems are the communication. Adding another announcement on top of an unresolved contradiction reinforces the contradiction, since it demonstrates that statements and requirements move independently.
- “We already did a gap assessment.” A gap assessment measures your estate against a target architecture. This measures your own governance against your own stated position, and organizations routinely pass the first while failing the second.
- “Leadership already committed publicly.” Public commitment is where the audit starts rather than where it ends, and a public commitment sitting on top of 6 unresolved contradictions is precisely the pattern that teaches people to wait.
- “The exception process is fine, teams can just request one.” An exception requirement is a tax on the behavior you want. Whichever option requires paperwork is the one the organization has marked as unusual.
- “This will look bad in front of audit.” A documented list with owners and dates is stronger evidence of diligence than silence. Regulators and courts treat the absence of a program far more harshly than the presence of one that surfaces its own problems.
Questions people ask
How long does the audit take? Usually 1 to 2 weeks for the first pass, because the artifacts already exist and the work is reading them against a stated position rather than generating anything new.
Who should run it? Someone with the standing to request the artifacts and no stake in the answer. The accountable migration owner commissions it, per Cryptographic Ownership, and running it is often better done by someone outside the program.
What if we find 20 contradictions? That is an ordinary first result and it is good news, because each one is a concrete, assignable fix. The organizations in trouble are the ones that find none, which usually means the position was written vaguely enough that nothing can contradict it.
Is this the same as a policy review? A policy review checks documents against each other. This checks live operational systems, including metrics and contracts, against a stated intent, and metrics are where most of the real contradictions live.
Our procurement terms are set centrally and we cannot change them. Then that entry gets an owner outside your program and a longer date, and it stays on the list. A contradiction with a slow fix is different from one nobody has named.
How often should it run? At program start, whenever the stated position changes, and annually after that. The annual pass mostly catches new contracts and new metric definitions, which are the two that regenerate.
What is the single highest-value fix? Usually the incident scorecard, because it is invisible, it is unarguable once seen, and it is the one directly punishing the people whose cooperation the whole program depends on.
Go deeper
- Declaring Classical Cryptography End-of-Life: the stated position the audit checks everything against.
- The Turned-Off Test: the completion measure that pairs with this one.
- Cryptographic Ownership: who commissions the audit and who resolves what it finds.
- PQC Procurement and RFP Language: the fix for the contract-terms row.
Everything here is the map, given freely. When your team needs the position written and the audit run against your actual systems, contracts, and metrics, that’s the work I do.
Last verified 2026-08-19 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.