When Your Pentest Findings Outlive Your Ethics Board: Governance Decay Explained

You run a pentest. Findings come in—critical, high, medium. You present them to the ethics board, get sign-off, and file them in a tracker. Then the board dissolves. The CISO leaves. The company pivots. Two years later, those same findings are still open, still exploitable, and nobody remembers who was supposed to fix them. That's governance decay.

I've seen this happen at a major bank, a healthcare SaaS company, and a startup that raised $50M before realizing they had 47 unpatched vulns from a single engagement. The pattern is consistent: ethical findings outlive the governance structures that authorized them. This article walks through why that happens, what works (and what doesn't), and how to build persistence that survives board turnover.

Where Governance Decay Shows Up

Financial services: the 18-month ghost vulns

I walked into a bank’s post-breach review last year. Their pentest report from eighteen months prior listed twelve critical findings. Eleven were closed. One — a path-traversal hole in an internal vault API — had been marked “accepted” by a risk committee that no longer existed. The team who built that API had been outsourced. The product owner had left. No one remembered the exception. That ghost vuln was still live, still exploitable, and it sat in a data path handling SWIFT messages. The governance board had approved the risk, then dissolved. No handoff, no sunset clause, no re-review trigger. That's decay — not malice, not incompetence, but the slow silence after a board stops paying attention.

The odd part is — financial services usually have the best compliance hygiene. They pass audits. They check boxes. But audit scope rarely validates prior risk acceptances. The accepted finding becomes invisible. It drops off the dashboard. The next pentest samples a different endpoint. So the ghost survives, protected by nothing but an expired committee decision and the fact that nobody is brave enough to re-open it. Fixing that single vuln took us three hours. The governance gap that hid it? Still open.

Healthcare SaaS: when compliance cycles miss findings

Healthcare SaaS is a different flavor of the same rot. Compliance cycles — HIPAA, SOC 2, HITRUST — run on a calendar. Quarterly reviews. Annual pentests. The finding you remediate in January stays fixed until the next test. But what about the finding the pentester didn't find? The one that surfaces in June, after the report is filed and the board has moved on to Q3 priorities? That finding has no governance path. No owner. No SLA. It sits in a triage queue behind the next compliance deadline, and because it wasn't in the last audit scope, nobody escalates it.

Most teams skip this: the finding that arrives between governance cycles is the most dangerous. It has no sponsor. No formal risk acceptance process — because the process is triggered by the audit, not by the vulnerability. I've watched a stored-XSS bug in a patient portal drift for seven months because the security team was waiting for the next board meeting to assign it. Seven months of patient data at risk, not because the fix was hard, but because the governance mechanism wasn't designed to catch mid-cycle orphans. That's not a technical failure. It's a process failure dressed up as compliance.

‘Governance decay isn't a broken lock — it's a lock nobody remembers the combination to, so they just leave the door cracked.’

— field engineer, healthcare SaaS post-mortem

Startups: no board, no owner

Startups don't have governance boards. That's the point — and also the trap. When you're ten people, the CTO owns everything. Pentest findings get assigned in Slack. The decision to accept a risk is a two-line message: “That endpoint is deprecated anyway, leave it.” But six months later, the CTO is at a different company. The endpoint is still live — undocumented, unowned, but now serving a feature that grew around it. The acceptance was never documented, never reviewed, never revalidated. Decay happened in a single hiring cycle.

The painful truth is that startup vulnerability persistence is faster than enterprise decay. No formal process means no friction, but also no memory. A finding accepted by a founding engineer in month three is often invisible by month nine. No artifact, no ticket, no risk register entry. The fix is cheap — cost of a deployment — but the awareness is zero. What breaks first is not the code. It's the continuity. Replacing that's harder than patching the vuln. And in the meantime, the ghost lingers, waiting for the next pentest to re-discover what was already known, already accepted, and already forgotten.

Foundations Readers Confuse

Governance decay vs. technical debt

The two look alike on a spreadsheet, but they rot from different ends. Technical debt sits in code — a bad library, a missing input filter, a schema that hurts to query. You can measure it in refactor hours. Governance decay lives in the process around that code: the approval queue that swallowed a critical patch for three weeks, the risk rubric that says “low impact” because nobody updated the asset tags since 2021. I have seen teams burn six months paying down technical debt while the governance rot quietly made every fix they pushed impossible to deploy. The catch is — technical debt produces a clear signal (failed builds, crash logs). Governance decay produces silence, then a breach that looked like a code problem but was actually a chain-of-approval problem.

Wrong order. Most shops treat governance as a configuration layer you set once, like a firewall rule. It's not. Governance is a runtime. The decision tree you built for exception handling last quarter already assumes a threat model that shifted while you were sprint-planning. That sounds fine until the board votes to “expedite” a high-risk change and the expedite lane has no vulnerability check — because nobody rewrote the lane when the product split into microservices. Real cost: one late-night rollback that should have been a pre-merge scan.

Vulnerability persistence vs. stale findings

A finding can be both true and useless. That's the distinction practitioners blur hardest. Vulnerability persistence means the root condition still exists — the same misconfig, the same missing authentication, the same race window that made the original test succeed. A stale finding means the vulnerability is gone but the report page still says “open” because the governance board never received the remediation evidence, or the CVE tracker never synced with the ticket system. I have watched engineering teams fight ghosts for two quarters because the board’s risk register still listed a buffer overflow that was patched in a routine release. The result: false confidence on one side, real frustration on the other, and zero useful signal for the next pentest.

Most teams skip this: they treat recurrence rates as a simple “did it come back?” question. That misses the drift. A vulnerability can persist through equivalent code paths even if the original file is deleted. I once reviewed a Go service where the team had fixed every reported SQL injection in one endpoint — but the new developer onboarding guide still copied the old raw-query pattern. The vulnerability persisted; the finding record was closed. Governance decay, meet technical debt.

“We closed 92 % of findings last quarter. The breach used a variant we never reported because the original form was alphabet soup.”

— CISO at a mid-size fintech, after a post-mortem that traced the root cause to a decade-old exception process that was never revisited

Flag this for penetration: shortcuts cost a day.

Flag this for penetration: shortcuts cost a day.

Board authorization vs. engineering ownership

One signs, the other ships. That sounds obvious until you see a board reject a fix because the engineering owner used a different CVSS scoring calculator than the one the board’s policy references. Or until the board authorizes a six-month remediation plan and engineering ships it in two weeks — but the authorization window still blocks deployment, because the policy says “board review required.” The asymmetry hurts. Boards own what gets fixed; engineers own how and when. When those two lines drift too far apart, you get a governance chasm: the board votes on a solution that no longer matches the codebase, or engineers bypass the board entirely because the authorization cycle is slower than the vulnerability lifecycle.

The trick is to design handoffs that expire. Board authorization should carry a timestamp — if engineering hasn’t shipped within 30 days of sign-off, the authorization lapses and the risk re-evaluates. That forces both sides to sync, periodically, instead of assuming the original decision still holds. Most teams resist this. “Too much overhead,” they say. I have watched those same teams spend three times the overhead unpicking a fix that was approved against a system that no longer existed. Choose your expensive mistake.

Short sentence: authorization is not ownership. One grants permission; the other carries the consequence when the seam blows out.

Patterns That Actually Work

Automated SLA escalation with rotating owners

The pattern that survives layoffs, reorgs, and ethics board turnover is the one nobody remembers to turn off. I have seen teams build elaborate governance frameworks that collapse the moment the original champion takes parental leave — six months, one firewall rule dies, a critical finding slips back into production. The fix is brutally simple: tie every remediation SLA to a rotation of named owners, not a single inbox. We used a Slack bot that reassigned the primary contact each quarter, drawn from a pool of trained engineers. When someone quit, the bot didn't stall — it picked the next name and bumped the SLA timer. That sounds fine until you realize the new owner might be on-call that week. The catch is you need an explicit handover window: three business days where the old and new owner overlap, or the seam blows out. Most teams skip this.

What usually breaks first is the escalation path. The board sets a 30-day SLA for fixing a medium-severity SSRF in an internal tool. Week one: quiet. Week two: the assigned engineer opens a merge request, but code review sits for five days. Week three: the engineer pivots to an incident. Day 29: someone pushes a cosmetic patch, closes the ticket, and the governance board marks the finding as resolved. The vulnerability persists. The pattern that works adds an automated escalation at day 21 — not to the board, but to the rotating owner's skip-level manager, with a brief summary in plain English. "This SSRF needs backport approval, blocked on review." The manager has 48 hours to unstick it or explain why the board should extend the SLA. Odd part is — most managers prefer the quick escalation over a quarterly review where they must defend a missed deadline. That's human nature. Use it.

Findings-as-code: version-controlled remediation

Your pentest report is dead the moment the ethics board approves it. PDFs rot on Sharepoint; spreadsheet statuses drift; the one admin who understood the risk profile transfers to another team. The alternative is to treat every finding like a unit of code — an immutable blob with a hash, a descriptive title, and a link to the commit that proves remediation. We did this once by storing findings in a plain YAML file inside the affected repository. Each finding had a field called remediated_in: a git SHA. The catch is that the remediation SHA must pass CI with the fix applied and the exploit test removed. No SHA, no closure. The board can't mark something as resolved until the automation confirms the hash exists on the main branch. That hurts when a team wants to close a finding by arguing that the risk is "accepted" — the pattern forces them to push a policy exception as a separate file, version-controlled, with an explicit expiry date.

One concrete anecdote: a team at a mid-size SaaS company found a race condition in a payment webhook. The pentest report described it in two paragraphs. The governance board accepted a risk-mitigation memo and closed the finding. Six months later, a refactor reintroduced the exact same race condition. Nobody noticed because the original finding was archived. Findings-as-code would have prevented this — the YAML file remained in the repository, flagged as status: open, because the remediation SHA never arrived. The board's memo was a separate document, not a code change. That's the difference between governance and actual persistence. The trade-off is that this pattern requires discipline: every pull request touching a file with an open finding triggers a bot reminder. Noisy? Yes. But noise is better than silence when the vulnerability is still live.

Wrong order. Most teams implement the version control after the third breach — they start with PDFs, then spreadsheets, then a Jira board that nobody grooms. I recommend starting with the YAML file before the pentest begins. Hand the testers a template, let them write findings directly into the repo, and your governance board inherits version history for free. That's one afternoon of setup. The alternative costs you a day every quarter when the board asks, "Wait, did we actually fix that one?"

Quarterly governance reviews with board transition triggers

The quarterly review is the most common pattern, and also the most commonly faked. Teams hold a 90-minute meeting, click through a slide deck, update a RAG status column, and adjourn. Two quarters later, the same findings are still orange. The pattern that actually works adds a hard transition trigger: after two consecutive quarters with no movement on any finding, the board must either accept permanent risk or escalate the entire portfolio to the CISO. No extensions. No "we're waiting on engineering capacity" — if the finding has sat for six months, the board's patience is a liability.

'A finding that survives two quarterly reviews unchanged is not a vulnerability anymore. It's a feature of your risk appetite.'

— paraphrased from a security engineer at a fintech firm, during a post-mortem I attended

The trigger does something else: it forces board transitions to be explicit. When a board member steps down, the new member inherits not just the portfolio but the countdown clock on any finding that has already aged one quarter. They can't reset the SLA. This prevents the classic governance decay pattern where a new board grants a "grace period" and effectively extends the life of an unpatched vulnerability by three months. One rhetorical question: would your current board survive a clean handover where the clock never stops? If the answer is no, then your governance is already decaying — you just haven't noticed because the same people have been sitting on the same findings for a year. The fix is as simple as a calendar rule: every quarterly review includes a five-minute check of the transition log. Who joined, who left, and which findings now have new owners whose first action is to defend a deadline they didn't set. That discomfort is the only reliable signal that your pattern is working.

Anti-Patterns and Why Teams Revert

'Fix it next sprint' — the infinite deferral

This is the most common decay pattern I see in post-pentest governance. A critical finding surfaces—say, a credential leak in a staging pipeline that mirrors prod. The board agrees it's urgent. Then someone says the magic words: "We'll slot it into the next sprint." Next sprint becomes two sprints later. Then it slips to a "tech debt backlog" that nobody grooms. Six months later, the same vulnerability reappears in the next pentest. Worse—it has spawned three children.

The psychological force here is diffused urgency. When a governance board votes to defer, every member feels they did their job. The issue was seen, discussed, logged. Nobody sits with the pain of a live exploit path. That gap—between awareness and accountable ownership—is where persistence rots. I have watched teams defer the same RCE finding three cycles in a row, each time with a valid-sounding reason: dependency conflict, refactor pending, leadership reprioritization. The catch is—each deferral trains the organization that vulnerabilities are negotiable. They're not.

What breaks this pattern? Hard deadlines with human consequences. Not a ticket priority flag, but a rule: anything tagged "critical" that misses two sprint boundaries escalates to the CISO's office for a written exception. That forces a decision: fix it or own the risk personally.

Single-point accountability (the hero trap)

One person holds the keys. The bright senior engineer who filed the original finding. The security champion who chases owners every week. The compliance lead who manually tracks spreadsheet rows. That sounds efficient—until that person goes on leave, switches teams, or burns out. I have seen a three-month governance recovery evaporate in two weeks because the only person who understood the remediation plan was in a hospital with no cell service.

Not every penetration checklist earns its ink.

Not every penetration checklist earns its ink.

The anti-pattern is personal heroism disguised as process. Teams revert because the system never actually stabilized—it just had a human patch. The moment that patch moves, the seams blow out. The odd part is—boards celebrate this behavior. They give awards to the person who single-handedly closed fifteen tickets. But the metric that matters is: can the same vulnerability re-occur without that person? If yes, the board hasn't fixed anything. It outsourced vigilance.

Good governance distributes accountability oddly: not evenly, but with explicit backup. Every remediation owner must name a secondary owner before the board signs off. No secondary? The finding stays open. That feels bureaucratic until the primary owner gets hit by a bus—metaphorical or literal.

Manual tracking in a Jira graveyard

Many teams start with a tidy spreadsheet or a shared Notion page. It works for four weeks. Then someone pastes the wrong date. Then a column gets sorted wrong. Then a finding quietly ages past its SLA while everyone assumes "someone else" is watching. I have audited boards that had seven different tracking surfaces: one spreadsheet, two Jira filters, a Confluence table, three email chains, and a Slack pinned message. Nobody knew which source was truth. The result? Seven different answers to "Is the critical finding resolved?"

The reversion trigger here is coordination overhead. When tracking requires manual cross-referencing, teams naturally optimize for the path of least effort: ignore the system, do a quick check, assume it's fine. That works until it doesn't. A friend once described his team's Jira board as "a cemetery with status labels"—tickets sat dead for months, marked "In Progress" because nobody wanted to close them without a sign-off that never came.

Fix this by forcing one unified state machine. Automate status transitions: when a fix is merged to a specific branch, the ticket moves to "Verification Required" automatically. No human updates. No email reminders. If a ticket sits in "Open" past its SLA, it pings the board chair—not the engineer. That changes who feels the pain.

"We used three different tools to track findings. After six months, not one person could tell me which vulnerabilities were actually closed. The board was a theater, not a governance function."

— Director of Security at a mid-market SaaS firm, describing his team's 2023 retrospective

That hurts. But the lesson is clean: if your governance process takes more effort to maintain than to exploit a vulnerability, the attackers win by default. Revert-proof your board by removing every manual step that a human can lie about—including to themselves.

Maintenance, Drift, and Long-Term Costs

Annual refresh costs vs. cumulative risk

Most teams budget a flat number for annual retesting—say, a fixed-price pentest every twelve months. That sounds fine until you map the decay curve. A finding that scored 'High' in January 2023 might still be open in January 2024, but the environment around it has shifted: a new API gateway was bolted on, the original developer quit, and nobody updated the compensating controls. The cost to reassess that single finding now includes scoping the change, re-running half the test suite, and a triage meeting that should have taken fifteen minutes but eats three hours. I have seen finance departments approve a $40k annual retainer while ignoring the $120k in accumulated drift work—the hidden surcharge for not closing findings when they were fresh.

Multiply that across twenty findings. The arithmetic is brutal: one stale vulnerability per quarter, each requiring a partial reaudit, and suddenly your annual security spend doubles without a single new test. Worse, the risk score on the board stays static because nobody recalculates likelihood after infrastructure changes. A Medium finding from last year can silently become Critical when a new cloud service inherits its trust boundary. The catch is—governance boards love static numbers. They make the dashboard look clean. Clean dashboards kill accurate budgets.

Drift from original intent when findings get stale

Every pentest finding carries context: the exact route the tester took, the config file they modified, the timestamp of the session. Let that sit for six months and the context rots. I watched a team reopen a SQL injection finding only to discover the vulnerable endpoint had been migrated to a different microservice—but the governance board still listed it under the old IP range. Wrong order. They spent a week tracing phantom traffic before realising the original test didn't match the current architecture. That week is a pure cost of drift, not a cost of fixing the vuln.

What usually breaks first is the reproduction steps. Testers write them fast, assuming a stable environment. Six months later, the database collation changed, the WAF rules got tightened, and the proof-of-concept payload that worked in August fails in February—not because the vuln is gone, but because the path to trigger it has shifted. Teams then argue about whether it's a real finding or a false positive. The board kicks it back to the next quarterly review. Another quarter of drift. The odd part is—the original remediation plan, which assumed the codebase would stay still, becomes a fiction that nobody admits is fiction.

‘We accepted the risk last year. Why are we now paying for a risk we already accepted?’ — Board member, three months before a breach that used that exact finding.

— paraphrased from a post-incident review I sat in; the question itself was the real vulnerability.

Hidden costs: re-audits, breach penalties, lost trust

The direct costs—re-audit fees, consultant overtime, emergency patch sprints—are the ones that show up on invoices. The insidious costs don't. When a stale finding eventually triggers a breach, the penalty is rarely limited to the data loss. Compliance fines multiply because the audit trail shows the finding sat unresolved for fourteen months without a documented re-evaluation. Regulators read that as negligence, not as a governance process that simply drifted. I have seen a single unattended Medium finding inflate a GDPR fine by 40%—not because the breach was catastrophic, but because the paper trail looked lazy.

Lost trust is harder to price but hits faster. Customers who learn that a known finding was deferred year after year don't ask about the governance board's quarterly approval process. They ask why they should keep paying for a service whose risk register reads like a deferred-maintenance log. The sales cycle stretches, renewal conversations get tense, and the security team spends time explaining a five-year-old governance structure instead of fixing code. The irony is—the board that was supposed to prevent this kind of exposure becomes the reason it persists.

Field note: penetration plans crack at handoff.

Field note: penetration plans crack at handoff.

Most teams skip this: a simple cost-per-drift metric. Take the total annual security spend, divide by the number of open findings older than one year. If that number drops below the cost to fix one finding during a normal sprint, you're subsidising decay. That's not a governance problem. That's a math problem dressed up as a policy. Fix the math, and the policy tends to follow—because the board can't argue with a line item that says '$12,000 per stale vuln' when the remediation task would have cost $400.

When Not to Use a Governance Board

Small Teams That Can Own Findings Informally

Not every vulnerability finding needs a dozen people in a room with a slide deck. I have seen three-person devops shops do more ethical persistence per week than Fortune 500 boards manage in a quarter. The trick is—they skip the governance theater entirely. When your team fits around one table, the fight over 'who owns the fix' becomes a five-minute Slack thread. Formal boards add latency that kills the very urgency a finding needs to survive. That sounds fine until a critical finding sits on a board backlog for two sprints, waiting for quorum.

Small teams still decay. They just decay faster—and notice sooner. What usually breaks first is documentation: the fix gets deployed, the ticket gets closed, the root cause disappears into tribal memory. No board to archive the why. That hurts more than most teams admit. But if your ship cycle is under two weeks and your security person meets engineers daily, a formal board is overhead you can safely refuse. The cost of the meeting exceeds the cost of the miscommunication it prevents.

Short-Lived Projects With Fixed End Dates

A pentest finding on a project that sunsets in three months? Don't convene a governance board. Wrong order. Boards are designed for continuous systems—codebases that outlive their authors. Short-lived projects need a simple handoff: fix it, log it, archive the repo. I have watched teams spend four weeks building a governance pipeline for a service that got decommissioned before the second review cycle. That's not ethical persistence; it's bureaucratic inertia dressed up as rigor.

The edge case everyone misses: what if a short-lived project gets extended? Suddenly your informal sign-off has no audit trail. The fix for that's a lightweight closure document—one page, three fields (finding, fix, date), signed by the team lead. No steering committee, no escalation matrix. Save the board for the infrastructure that will still be running when your kids start college.

Findings Already Fixed Before the Board Meets

Here is the rhetorical question that stings: if your team patches a critical finding in the same hour it was reported, why are you still convening a board to approve the remediation? I see this pattern constantly—developers fix the bug, push the PR, and then sit through a 45-minute governance session that retroactively blesses work already done. That's governance theater, not governance. The fix doesn't become more ethical because a board nodded at it.

The board that only stamps already-closed tickets is a cost center wearing a security badge.

— Engineering lead at a Series B fintech, after sitting through her seventh redundant review

The pitfall here is subtle: if you let the board skip findings that are already fixed, you lose your early-warning radar. Patterns of self-deployed patches—signals that your team is skipping process—never get surfaced. But there is a cleaner answer: classify findings as 'self-resolved' in your tracker, run a monthly three-minute spot check for pattern drift, and never let a board approve what is already done. That saves hours. Redirect those hours toward the findings that actually sit unresolved. Most teams skip this: they treat all findings equally, so the urgent ones get lost in the noise of the already-fixed ones.

Open Questions and FAQ

How do regulatory audits treat stale findings?

Badly. That's the short answer. A penetration test finding from eighteen months ago — still unaddressed, still sitting in a ticketing system — becomes a liability multiplier during a PCI-DSS or SOC 2 audit. I have watched auditors flag a single medium-risk finding as an exception, then use the governance board's own sign-off logs to prove the organization knew about the vulnerability and chose not to remediate. The logic is brutal: if your board accepted the risk, the finding is now a documented business decision, not a technical gap. That transforms a patchable bug into a governance failure.

The tricky bit is timing. Most regulatory frameworks don't mandate a specific shelf life for findings; they require evidence of active review. A finding from 2022 that was reviewed in Q3 2024 with a fresh risk acceptance carries more weight than a finding from last month that nobody has touched. What usually breaks first is the review cadence — teams stop re-evaluating old acceptances because the board meeting agenda runs long. The seam blows out when the auditor asks "Who re-assessed this in the past six months?" and the answer is silence.

'We accepted that risk two years ago. The board minutes prove it.' — then the auditor pulls the incident log from last quarter where that exact flaw was exploited.

— paraphrased from a remediation post-mortem, retail sector, 2023

Should AI-generated findings have the same governance?

Not yet — and treating them identically is a trap. AI scanners produce findings at a volume and confidence distribution that human pentesters don't: hundreds of low-signal alerts, a handful of genuine issues, and a non-trivial slice of hallucinations. Routing all of them through the same governance board that handles manual findings guarantees decision fatigue. I have seen boards rubber-stamp AI findings in under thirty seconds per item because the list is too long to read. Wrong order. That hurts more than skipping the scan entirely.

The fix I have recommended in practice is a tiered intake. AI-generated findings below a certainty threshold (typically sub-70% confidence or unsupported by a second tool) land in a fast-track queue, not the board agenda. Only those that survive human triage — or meet a severity cutoff — touch the governance process. The trade-off is overhead: you need a human to run the triage, and that person must have authority to discard findings without escalation. Most teams skip this. They bolt an AI pipeline onto existing governance and wonder why the board spends ninety minutes debating false positives.

The honest answer is that we don't yet have enough longitudinal data to know whether AI findings drift differently than human findings. The patterns that actually work so far suggest that governance boards should treat AI output as candidate evidence, not accepted findings, until a human signs off. That will change as tooling matures. Right now, pretending otherwise generates process debt — and debt compounds.

Can governance decay be measured objectively?

Partially. The metrics that matter are boring and surprisingly effective: mean time between board reviews for each finding, the percentage of findings that roll over to the next quarter unmodified, and the ratio of new acceptances to re-assessments. A board that reviews 40 findings per quarter but re-evaluates only 3 of them is drifting — the other 37 are aging silently. Another objective signal is the gap between a finding's initial risk score and its current score after n quarters without remediation. If the score hasn't changed despite the organization's threat landscape shifting, decay is present.

The catch is that no single number captures governance health. A low rollover percentage could mean the board is diligent — or it could mean they're closing findings arbitrarily to keep the queue clean. I once worked with a team that measured success as "zero findings older than six months." They achieved that by lowering severity ratings on old items until the items fell below the review threshold. That's not governance. That's a dashboard hack. The objective measure requires pairing velocity with depth: do re-assessments include fresh threat intelligence, or are they just a status check?

One proxy I trust is the recurrence rate — how often the same class of finding reappears after a board acceptance. If your board accepts SQL injection risk in Q1 and a similar injection surfaces in Q3, the acceptance didn't hold. The governance process created a false sense of closure. That is measurable. That is also painful to report. But reporting it beats the alternative: discovering the decay during an incident post-mortem, with the board's own sign-off as exhibit A.