Five ways approval controls collapse, and how to tell them apart
A crypto custody loss, a payroll diversion and a production database deletion look like unrelated incidents. Structurally they are the same handful of defects, appearing in different vocabularies.
What are the five ways approval controls collapse?
Consent decay, where the approved object changed afterwards. Consent evasion, where the path was routed around. Consent absence by configuration, where no approval was ever required. Provenance collapse, where an approval exists but cannot be tied to a person. And post-hoc misreporting, where the record describes something that did not happen.
- Approval failures cluster into five defects: decay, evasion, absence by configuration, provenance collapse and post-hoc misreporting.
- Each has a distinct signature and a distinct remedy, so misclassifying an incident produces the wrong fix.
- Most organisations can locate their own controls in this taxonomy in an afternoon.
Part of Research, datasets and methods
The five defects
| Defect | One-line description |
|---|---|
| Consent decay | A human approved something, but the thing changed afterwards |
| Consent evasion | The approval path was routed around, not broken |
| Consent absence by configuration | No approval was ever required; the control was off |
| Provenance collapse | An approval exists but cannot be tied to a specific person |
| Post-hoc misreporting | The record describes something other than what occurred |
They are not mutually exclusive — a serious incident often involves two or three — but the primary defect determines the remedy.
Consent decay
The approval was real and the object it covered changed between approval and execution.
- A payment approved, then the beneficiary account updated before release
- A deployment approved, then a commit pushed to the same branch
- A transaction reviewed in an interface, then constructed differently for signing
- A plan approved, then re-planned against changed state
Signature: the approval record and the executed object differ. Remedy: bind the approval to a digest of the object and recompute at execution, refusing on mismatch.
Consent evasion
The control exists, functions, and was not involved.
- An emergency path with fewer approvers, invoked under manufactured urgency
- A direct API call bypassing the interface that enforces approval
- A threshold worked around by splitting into smaller amounts
- A privileged account exempt from the policy for operational reasons
Signature: the control has a clean record and the loss occurred anyway. Remedy: enforce at the point of effect rather than at an interface, and treat every exemption as a finding.
Consent absence by configuration
No approval was required, and usually nobody knew.
- A threshold set high enough that nothing reaches it
- An automation identity outside the approval policy
- A new integration that inherited no controls
- An approval setting disabled during a migration and never restored
Signature: no approval record exists and nobody expected one to. Remedy: inventory consequential actions and verify empirically which ones actually require approval — by attempting them, not by reading policy.
Provenance collapse
Something approved it. Establishing who is impossible.
- A shared account used by several people
- A service account used interactively
- An approval recorded against a session rather than a person
- A delegation or out-of-office rule that approved automatically
Signature: the record names an account, and the investigation cannot get past it. Remedy: bind approvals to individual credentials and eliminate shared interactive accounts.
Post-hoc misreporting
The record exists, is internally consistent, and describes something that did not happen.
- An agent's narration of its own actions treated as a log
- An approval status written by an integration rather than a person
- A summary generated separately from the executed payload
- Evidence assembled after the fact for an audit
Signature: the record is clean and contradicted by other evidence. Remedy: generate evidence as a by-product of the control operating, signed at the moment, not compiled later.
Using the taxonomy
Two applications, both cheap.
- On your own controls. For each consequential action, ask which of the five it is currently vulnerable to. Most organisations find they are exposed to three or more.
- On incidents. Classify by primary defect before choosing a remedy. An incident of evasion treated as decay produces a payload-binding fix that changes nothing.
The second is where the taxonomy earns its keep. Misclassification is common because the narrative of an incident emphasises what was unusual about it, and the structural defect is usually the unremarkable part.
Applying it to your own controls
Two uses, both cheap. On your controls: for each consequential action, ask which of the five it is currently vulnerable to. Most organisations find they are exposed to three or more. On incidents: classify by primary defect before choosing a remedy.
| Defect | Signature | Remedy |
|---|---|---|
| Decay | Approval record and executed object differ | Bind to a digest, recompute at execution |
| Evasion | Clean record, loss occurred anyway | Enforce at the point of effect; treat exemptions as findings |
| Absence | No record, and none expected | Inventory consequential actions; test empirically, not by reading policy |
| Provenance collapse | Record names an account | Bind to individual credentials; remove shared interactive accounts |
| Misreporting | Clean record, contradicted by other evidence | Generate evidence as a by-product of the control, signed at the moment |
Objections and honest limits
“Our incidents do not fit these.” Serious incidents usually involve two or three at once. The primary defect is the one that determines the remedy, and it is usually the unremarkable part of the narrative.
“We can just read our policies.” Absence by configuration is only visible empirically. Attempt a consequential action and observe whether approval is actually required.
Coding an incident against the taxonomy
A taxonomy is only a dataset if incidents are recorded the same way each time. Seven fields are enough, and the discipline is that the defect is assigned from the evidence rather than from the narrative in the press coverage.
| Field | Contents |
|---|---|
defect | One of the five: decay, evasion, absence, provenance, misreporting |
surface | Where the approval was supposed to happen |
actor | Insider, outsider, agent, or configuration |
evidence_available | What the organisation could actually produce afterwards |
detection_lag | Time from the act to anyone noticing |
secondary_defect | The second defect, where one masked another |
source | Regulatory filing, court record, or disclosure — with a citation |
Worked codings
Three generic patterns, coded the way the schema intends. None is a specific named incident — these are the shapes that recur, and the point is to show how the fields resolve an argument about which defect applies.
| Pattern | defect | secondary_defect | Why |
|---|---|---|---|
| A departed employee's credential is used for a bulk export | decay | provenance | Authority outlived the relationship; nothing tied the act to a person |
| An agent executes a destructive command with approvals disabled | absence | misreporting | The gate was configured away; the record produced afterwards was assembled, not captured |
| A treasurer approves a payment after a spoofed instruction | evasion | provenance | The control was routed around, and the approval evidence was a chat message |
Notice that provenance appears as a secondary defect in two of the three. That is the pattern worth taking from any archive of these: the primary defect explains how the act happened, and the provenance defect explains why nobody could prove anything afterwards.
When you code your own near-misses this way, the useful output is not the count by defect. It is the evidence_available column, because it is the same answer every time and it is the one you can change before the next incident.
A half-day self-assessment
- List consequential actions. Money movement, permission change, bulk export, destructive operations, credential issuance.
- For each, attempt it. Reading policy does not reveal absence by configuration.
- Check what the record names. An account, or a person.
- Check what the record covers. A reference, or the object that executed.
- Check who wrote the record. The control, or the system asking to be trusted.
Terms used here
- Consent decay
- A real approval whose object changed between approval and execution.
- Consent evasion
- A functioning control that was simply not involved, usually via an emergency path, a direct API call or an exemption.
- Provenance collapse
- An approval that exists but cannot be attributed to a natural person, typically because it names a shared or service account.
Frequently asked questions
Are the five defects mutually exclusive? No. Serious incidents often involve two or three. The primary defect is what determines the remedy.
How do you tell decay from evasion? In decay the approval record and the executed object differ. In evasion the record is clean and the control was simply not involved.
What is the cheapest thing to check? Configuration absence — attempt a consequential action and see whether approval is actually required. Reading policy does not answer it.
Why does misclassification matter? An evasion incident treated as decay produces a payload-binding fix that changes nothing, and the same failure recurs.
Why record a secondary defect? Because one defect usually masks another — typically a provenance failure that made the primary defect unprovable afterwards.
What is the most useful field? evidence_available. It reads the same across almost every incident, and it is the one you can change in advance.
Where this fits in Manav
Manav addresses four of the five directly: binding closes decay, point-of-effect enforcement closes evasion, per-person credentials close provenance collapse, and evidence generated by the control closes misreporting. Absence by configuration is an inventory problem you have to do yourself.
Sources and further reading
- SAP / Oracle segregation of duties control guidance (ISACA)
- Post-incident analyses from custody, payments and infrastructure operators.
- COSO Internal Control — Integrated Framework
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls