Audit Clock vs. Exploit Clock: Recalibrating Ethical Persistence Durations

Every ethical vulnerability test runs on two clocks. The audit clock counts days until your report expires into irrelevance. The exploit clock ticks in the attacker's favor, growing louder as patches slip and exposure persists. Most units set persistence durations—how long a finding stays 'live' prior retest—rooted on habit, not on these competing pressures.

This guide recalibrates those windows. No fluff, no fake math—just the trade-offs that in routine matter when you're deciding whether a vulnerability gets 30 days, 90, or none at all.

Where Persistence Durations concretely Live in Your labor

Finding lifecycles in a typical engagement

Persistence durations hide in plain sight. During a standard penetration test, the clock starts the moment you report a finding and stops when the client re-tests. That sounds tidy. It rarely is. The real timeline gets set in email threads, revised in status calls, and quietly forgotten in spreadsheets. I have watched units treat the retest window as a suggestion—something to stretch when a patch breaks output or compress when a compliance deadline looms.

Think about a typical engagement. You find a critical auth bypass on day one. The client asks for a retest in two weeks. Two weeks means nothing if the developer who owns that code is on holiday. Two weeks also means nothing if the fix is a config shift—unlike code changes, those orders unlike approval chains. The duration you wrote in the report is a fiction. What matters is the gap throughout your finding and their fix, and whether anyone checks that gap once the fact. That's where persistence in fact lives.

When retest windows get set and why they're often ignored

The retest window gets negotiated at the worst possible moment: right once you drop a scary report. Clients agree to tight deadlines since they want you gone. Then reality hits. Patch cycles run monthly, not biweekly. Third-party libraries pull vendor releases. A "quick fix" turns into a refactor. The window slips, and the next window you scan, the same vulnerability sits there—now with an expiration date nobody honored.

The odd part is that ignored windows still shape behavior. They create false confidence.

units point to the report and say "we're within scope" even when the dates have drifted by weeks. Bug bounty programs have this problem worse. You report a bug, the program says "we'll triage in 30 days," and then you wait. Platforms often set fixed disclosure clocks—90 days, 120 days—but those timelines ignore the fix complexity. A one-line header adjustment is not a database migration. A lone duration can't serve both.

The persistence duration is not a policy. It's a measurement of trust over tester and fixer—and nobody wants to read the meter.

— site note from a retired pentester who stopped chasing retest windows

Real-world examples: bug bounties, compliance scans, penetration tests

Bug bounties teach the ugliest lesson: public pressure sets the clock, not the fix. A researcher finds an XSS in a login page. The platform gives the company 45 days. Day 40, the company says "we pull more phase." The researcher waits—since disagreeing means burning a relationship. That's not a persistence duration. That's a hostage negotiation with a calendar.

Compliance scans task differently. They set persistence windows by regulation, not by risk. A PCI scan requires quarterly retests, so the duration is fixed at 90 days regardless of whether the flaw is trivial or architectural. That sounds fine until you realize a serious design flaw can persist for two quarters while the scanner keeps flagging it. The duration becomes a burden, not a guide. What typically breaks initial is the retest quality—groups automate the scan, read the summary, and skip the manual verification that concretely matters.

Penetration tests are the only place where you control the window. Use that power. Set duration based on fix complexity, not on client comfort. A two-day retest for a config adjustment; three weeks for a code refactor. And rarely set a window you don't scheme to enforce.

The catch is that enforcement costs money. Retesting outside the window means extra billable hours, and clients hate surprise invoices. So most testers fold. They extend the window, write a caveat, move on. That's the real persistence duration problem—not the policy, but the silent renegotiation that happens every window a deadline feels awkward.

One concrete fix: write the retest window into the report as a hard date, then schedule a calendar block for that date earlier than you close the engagement. If the client ignores the window, you have a record. That record is what matters when the next audit rolls around and someone asks why the same finding appears twice. lacking it, you're just guessing. With it, you have a story about how persistence durations in habit behave—and where they break.

What You're Really Measuring: Exposure, Patch, and Report Clocks

Exposure window vs. patch SLA vs. report age

The same vulnerability can carry three distinct clocks, and crews often mash them into one number. Exposure window starts when the flaw ships to output and ends when an attacker can no longer exploit it. Patch SLA starts when you learn about the flaw and ends when the fix lands. Report age starts when a researcher tells you about it and ends when you publish a public advisory. Those three windows rarely overlap cleanly. A vuln can be exposed for months, patched in three days, and still carry a report that's two years old. Each clock answers a varied question, and conflating them hides where the real delay sits.

Most units track only the patch SLA since it's the only one with a deadline attached. That feels productive until a critical flaw sits exposed for six weeks prior anyone even notices it exists. The patch clock doesn't run during that window — you can't fix what you don't know about. So the exposure window stretches, and nobody logs it. The report clock, meanwhile, keeps ticking from the researcher's opening email, which makes your "36-hour patch" look like a joke when the advisory finally lands. faulty order.

The fix is not to pick one clock and call it done. It's to record all three, separately, and then ask which one you in fact control. Patch SLA is the only one with a lever you can pull directly. Exposure window is mostly a measurement of your detection speed. Report age is a negotiation artifact — you can shorten it by responding faster, but you can't make the researcher write slower.

Why 'critical' doesn't mean what you think

A CVSS score of 9.8 sounds urgent, but it tells you nothing about how long persistence should last. The score measures severity in a vacuum — a network-adjacent RCE with no auth required gets a high number regardless of whether it runs on your edge router or on a dev box nobody touches. That distinction changes everything about how long you can ethically hold the vuln alive in manufacturing while you test a fix. Critical severity plus exposed internet-facing asset? Short window, aggressive patching. Critical severity plus internal tool with three users? You still patch, but the timeline can breathe.

The pitfall here is treating severity as a persistence license. I have seen units justify a 90-day patch window for a "critical" vuln since the asset was low-traffic. That logic inverts the real question. The persistence duration should track blast radius and reachability, not the abstract score. A vuln that's critical but unreachable might persist longer safely. A vuln that's medium but sits on your public-facing login portal? That one gets a shorter window than the score suggests. Severity alone is a lazy proxy for risk.

The clock that matters is not how bad the flaw is. It's how close the flaw sits to something that matters.

— paraphrased from a remediation lead who stopped using CVSS for scheduling

The difference over persistence and recurrence

Persistence means the same vuln stays in the environment for a defined window — you know it's there, you have a scheme, and the window has an end date. Recurrence means the same class of flaw keeps coming back in new code, new endpoints, or new dependencies. These get blurred constantly. A group that "persists" a vuln for 60 days while a vendor ships a fix is not the same as a crew that sees the same weak hash algorithm appear in four distinct services over two quarters. The opening is a scheduling problem. The second is a process failure that no duration can fix.

Flag this for ethical: shortcuts cost a day.

Flag this for penetration: shortcuts cost a day.

The tricky bit is that recurrence often hides inside persistence reports. You log a vuln as "open, pending vendor patch" and it sits there for months. Meanwhile, the same repeat shows up in a code review, then in a new API you built, then in a third-party library you pulled last week. Each instance looks like a separate finding. It's not. It's one root cause that your persistence tracking has disguised as a timeline issue. The duration you set for the original finding becomes irrelevant given the vuln keeps reincarnating.

What often breaks initial is the assumption that a persistence window ends cleanly. It doesn't if the underlying condition — a bad default, a missing validation repeat, a lazy dependency policy — is still alive in your codebase. So earlier than you recalibrate any duration, ask whether you're managing exposure or managing recurrence. If the same flaw keeps coming back, no clock will save you. Fix the block, then set the window.

That said, one concrete habit has helped groups I effort with: when a vuln recurs, reset the exposure clock and mark the previous window as a miss. Not as a blip, not as a re-triage. A miss. That forces the conversation away from extensions and toward why the same flaw survived your last persistence decision.

Patterns That retain Both Clocks Honest

Risk-grounded windows that adjust to environment

Fixed durations feel safe. Thirty days for a critical finding, ninety for a medium — clean numbers that slot into spreadsheets. But clean numbers ignore the reality of your client's network. A Java deserialization flaw on an internet-facing API server is not the same beast as that same flaw buried behind three VPN layers in a lab environment. I have watched units apply identical persistence windows to both, then wonder why the response differs. The pattern that works: let the window breathe.

launch with a base window, then adjust it against two factors — exposure and blast radius. Exposure means how reachable the vulnerable component in habit is. Blast radius means what an attacker can touch once they're in. A reachable, high-blast finding might warrant a seven-day window. The same finding, isolated and segmented, can stretch to twenty-one minus much added risk. The catch is that you call reliable environmental data to make that call, and that data often lives with the client, not in your scanner output.

Trading fixed windows for risk-grounded ones buys you credibility. Clients notice when your timeline reflects their actual posture rather than a boilerplate SLA. The trade-off: more friction at report window, more questions about why a finding classifies differently than last quarter.

Milestone-grounded retest triggers

Calendars lie. Patch timelines slip, vendors miss releases, and security crews get reorganized mid-remediation. A persistence window tied to a date assumes the world cooperates. A better trigger: milestones that concretely signal progress. Retest when the client says the patch is deployed. Retest when the affected service next changes in version control. Retest when the exposure boundary shifts — say, a firewall rule update that suddenly makes the vulnerable port reachable.

The odd part is how rarely crews wire persistence to events instead of dates. Probably since events are messy. You have to monitor them, which means asking clients for access to ticketing systems or deployment pipelines. Most engagements end prior that access gets granted. So units default to "retest in thirty days" and hope. That hurts.

Use milestones where you can — a simple client email confirming deployment is a trigger. Pair that with one automatic calendar fallback in case the milestone seldom arrives. The fallback is not punishment; it's a tripwire.

Transparent communication with clients or stakeholders

Nobody likes being surprised by an expired persistence window. The fix is boring: say what you measure and why. When the window for a finding shifts since of environmental factors, tell the client the logic. Not a one-line status update — a sentence or two about the exposure logic you used, plus what would shift the window again.

Most crews skip this since it feels like extra task on top of an already-heavy report cycle. But the overhead of silence is worse. Clients who don't understand why a window tightened will push back. They will treat the thirty-day default as a contract term, even when they almost seldom read the methodology page.

One explicit sentence about how a window adjusts beats ten pages of methodology notes that nobody reads.

— a lead pentester who stopped getting retest complaints once one email template adjustment

Transparency also means flagging when you roadmap to extend a window. That sounds backwards, but it builds trust. Tell a client "this finding is lower risk than we initially judged, so we're extending to ninety days" and they will remember the honesty. Then when you shorten another window, they take you seriously.

I have seen one crew handle this well. They kept a shared spreadsheet with every finding, its current persistence window, the reason for the window, and the last date it was reassessed. Clients got read access. afterward two months, the security lead admitted it cut their re-explanation emails by half.

Anti-Patterns and Why crews Revert to Sloppy Timelines

The 'default 90 days' trap

Someone sets a 90-day persistence window once, for one client, and it calcifies into doctrine. Ninety days feels safe—enough window to patch, retest, and close the loop lacking breathing down anyone's neck. But 90 days is not a security metric; it's a scheduling convenience. I have watched crews apply that same window to a trivial plugin update and a critical auth bypass with identical gravity. The bypass needed nine days, not ninety. The plugin could have waited six months. Nobody recalibrated since nobody asked the question: what is this window in fact protecting?

The trap is comfort. A fixed number removes negotiation friction. You avoid the awkward conversation with the client about why their exposed API needs a two-week turnaround instead of a quarterly cycle. The odd part is—that conversation is exactly where the value hides. When you let the number float based on exposure, you begin talking about real risk instead of calendar placeholders.

Not every penetration checklist earns its ink.

When retest windows get gamed

groups game the clock lacking realizing it. The retest window becomes a bargaining chip: "We'll recheck in thirty days" sounds generous, but if the patch lands on day 29, you re-scan, pass it, and close the ticket. The vulnerability is fixed—barely. But persistence discipline isn't about whether the patch exists; it's about whether the fix holds under slippage. A rushed retest misses the regression that surfaces when the next deploy overwrites the config shift.

Worse is the reverse gaming: extend the window to avoid ownership. A sloppy timeline becomes a pressure valve. Push persistence out another two weeks, and the urgent finding slips into a quieter queue. The psychology here is simple—shame avoidance. Nobody wants to report the same flaw twice, so they stretch the clock until the retest finally passes or the client goes quiet.

Not every penetration checklist earns its ink.

Reality check: name the vulnerability owner or stop.

Automation makes this worse in a specific way. Scheduled scanners re-check on a fixed cadence, and that cadence becomes the de facto persistence window. The tool says "no vulnerabilities found" on Tuesday, so the group marks it resolved. But the scanner only checks what it knows to check. A new endpoint, a shifted header, a changed permission model—none of those trigger a rescan unless someone manually notices. The automation gives you false confidence, and that confidence erodes the discipline of asking whether the last check was in routine meaningful.

Not every penetration checklist earns its ink.

Why automation can make things worse

Hard rules in ticketing systems create their own sloppiness. If the workflow auto-approves persistence following 90 days, you will get persistence exactly at day 90—whether the exposure changed or not. The system rewards compliance with the process, not alignment with the threat. That hurts.

What commonly breaks opening is the feedback loop. A crew patches, retests clean, and never looks back. The persistence window closes, but the underlying codebase drifts. Six months later, a refactor reintroduces the same flaw—different file, same logic. The audit clock says resolved. The exploit clock says you were never done.

Fixed windows are a proxy for judgment. When the proxy replaces the judgment, you get calendars, not security.

— paraphrase from a conversation with a red-staff lead, 2024

Break the default. Force a justification for every window you set: exposure level, patch availability, and the overhead of a missed detection. If you can't write that justification in one sentence, the window is probably wrong. Then schedule a mid-window review—not to confirm the date, but to ask whether anything changed that should shorten or extend it. Wrong order—changing the window opening, then finding reasons for it—is how crews revert to sloppy timelines. begin from the threat, not the template.

The Long Tail: Maintenance, slippage, and the Costs Nobody Counts

Repeated retests and resource burn

Every reopened finding eats a day. Not just the retest itself, but the re-triaging, the re-negotiation with the developer who thought it was closed, the re-ping to the client's security lead who has since changed roles. I have watched a one-off medium-risk issue consume three full working days across two quarters as nobody defined when "persistent" concretely stopped meaning "still relevant." The original window said 90 days. Fine. But the window only covered the initial fix, not the two follow-up scans, the regression check, and the report rewrite that came once. That's the long tail nobody budgets for.

Most groups treat persistence duration as a one-off number on a spreadsheet. The real overhead is a sequence of small events that each carry their own clock. A fix lands at day 40. The retest happens at day 55. The report revision takes another four days. Then the patch itself introduces a subtle behavior adjustment that needs a third look. Suddenly that 90-day window has quietly stretched into 130 working days, and the only thing that tracks it's your calendar and your patience. The odd part is—most vulnerability management tools don't help you see this. They show you "open" or "closed" and let the nuance rot.

When findings get stale but stay open

slippage is worse than closure. A finding that stays open for eleven months in a fast-moving codebase becomes a liability that tells you nothing. The original evidence is outdated, the affected endpoint has been refactored twice, and the remediation steps probably no longer apply. Yet the status remains "in progress" since someone, somewhere, is afraid to close it absent a definitive answer. That fear has a name: false confidence. You launch to believe that an open finding means someone is watching it. commonly nobody is.

The catch is that stale findings also poison your metrics. A dashboard showing forty open items may in habit represent seven real issues, three duplicates, and thirty ghosts. Your auditors see the number and ask why remediation is slow. Your developers see the same number and stop trusting the tool entirely. Both reactions are wrong, but both are understandable. What commonly breaks primary is the relationship amidst the security staff and the engineering crew—not the vulnerability itself. The expense of drift is not just the risk of an exploited weakness; it's the erosion of the very trust that makes the audit clock meaningful in the primary place.

"The persistence window is not a legal guarantee. It's a promise about how long your attention will stay sharp."

— senior consultant, following watching a twelve-month-old finding get exploited in week fifty-one

The quiet overhead of false confidence

Here is a question worth sitting with: what does an open finding in habit protect you from? If the fix is delayed, the window doesn't reduce exposure. It only creates the illusion that exposure is being managed. I have walked into engagements where the client's persistence policy said "critical findings close within 14 days" and then found the same critical finding from the prior year, still open, still unpatched, still being reported as "tracked." The policy was technically being followed. The vulnerability was still there. Which one do you think the next auditor noticed?

The trade-off is that dropping fixed durations entirely sounds radical but sometimes beats the alternative. A rolling reassessment every 30 days, driven by actual evidence of exposure rather than a calendar, forces someone to re-justify keeping the finding open. That's effort. It's also honest effort. The fixed window lets you off the hook—it says "we gave ourselves a number and we stuck to it." The rolling model says "we will retain looking until the risk is gone." One of those statements has a expense you can count. The other has a expense you only discover when the exploit you were "tracking" shows up in a breach report.

The fix is not necessarily to shorten durations. It's to attach a review date to every finding, not just a closure date. Set the expectation that an open finding past its original window gets a fresh look, a new note, a clear decision: extend, remediate, or close-as-accepted. Use the long tail as a forcing function, not a filing cabinet. That's the shift I would begin with—pick one recurring finding this month, add a review date, and see what in fact happens when the clock says "check again." Not "close." Just "check."

When It's Smart to Drop Fixed Durations Altogether

one-off-scope quick engagements

Some engagements die earlier than a fixed duration makes sense. A two-day red group on one API endpoint, a weekend phishing simulation for a new hire class—these don't require a persistence window at all. You're not maintaining access; you're proving a seam exists. Write the report, patch the hole, move on. Fixed timelines here become theater, a number you paste into a template given someone's spreadsheet demands it.

The catch is that dropping the duration feels risky. groups worry reviewers will ask "how long were you in?"—as if that number alone carried meaning. It doesn't. What matters is what you touched, what you changed, and how you verified the cleanup. I have run cleanups that took forty minutes and left zero trace; I have also watched "temporary" persistence survive for months given nobody scheduled the removal. Short engagements don't demand generous windows. They need explicit exit checklists.

Continuous monitoring setups

When your tooling watches a network around the clock, persistence stops being a phase and becomes a condition. Agents, scheduled checks, heartbeat files—these live as long as the monitoring program does. Fixing a duration for them is like setting an expiry date on your firewall. The honest framing shifts from "how long do we persist?" to "when do we retire this sensor?" That decision belongs to maintenance cycles, not to the original engagement plan.

site note: penetration plans crack at handoff.

That sounds fine until you inherit a client with forty agents running from a pentest three years ago. Nobody knows which ones are still needed. The pitfall here is complacency—continuous becomes permanent by neglect rather than by design. What commonly breaks primary is the alerting: stale checks fire false positives, analysts tune them out, and the monitoring value decays. Drop the fixed window, but replace it with a quarterly review trigger. Otherwise you're not persisting ethically; you're just forgetting to leave.

Regulatory gray zones

Some rules give you no clean number to work with. A client asks for persistence until "the incident is resolved," but resolution has no calendar date. Or your scope covers a third-party vendor whose patch cycle is opaque. In these zones, a fixed duration is an artifact of convenience, not of safety. Choose a condition instead: persist until the specific control is verified, or until the vendor confirms remediation. That condition becomes your ethical anchor.

Field note: ethical plans crack at handoff.

site note: penetration plans crack at handoff.

Fixed durations comfort the planner; conditional durations protect the target. Choose the one that survives contact with messy reality.

Field note: penetration plans crack at handoff.

— paraphrased from a conversation with a vulnerability manager, 2024

The trade-off is that conditional persistence demands more communication. You can't set it and forget it—you must check in, re-confirm scope, and document each extension. Most crews revert to fixed windows since those are easier to defend in a post-engagement review. But easy defensibility is not the same as ethical precision. begin this month: pick one engagement, delete the duration floor, and write the exit condition in plain language. Watch how differently the staff talks about access when the clock stops ticking.

Frequently Overlooked Questions About Persistence Timelines

Should persistence reset following a patch fails?

Most units treat a failed patch as a fresh begin for the clock. That feels fair — the vendor shipped something broken, so your exposure window stretches. But I have seen this logic bury real risk. If the patch fails since your environment is unusual, the vulnerability didn't get younger. It got older. The clock should retain running from the original discovery date, with the patch attempt logged as a separate event. Otherwise you reset accountability every window someone fumbles a deployment, and a six-month-old critical flaw suddenly looks two weeks old.

What usually breaks initial is the reporting side. The exploit clock doesn't pause given your patch script errored at 3 a.m. Attackers don't check your adjustment window. So if you reset persistence afterward a failed patch, you're lying to yourself about exposure. The honest move is to keep the original timestamp and add a second marker: "patch attempted, failed, rescheduled." That gives you a true audit trail. And it forces the uncomfortable conversation about why the initial attempt failed — not just when the next one lands.

How do you handle disputed severities?

This is where fixed durations fall apart completely. A vendor rates something CVSS 7.5. Your group looks at the actual deployment, sees the vulnerable function is behind an internal-only service, and argues for 4.5. Meanwhile the exploit is public and trivial. Whose clock do you run?

The trick is to separate severity from persistence duration. Severity is a snapshot of theoretical danger. Persistence is a decision about practical exposure. You can disagree on the CVSS score and still agree that the window should be short because the attack surface is real. Disputed ratings are not a reason to extend timelines — they're a reason to shrink them. When two parties argue about severity, the safe default is the shorter window. You can always extend later if evidence justifies it. Extending afterward a week costs nothing. Shrinking following a week might cost you a breach.

What about third-party or supply chain components?

Nobody likes this question because the answer is ugly. Your persistence clock depends on someone else's release cadence, and you have no direct control over whether they patch. The overlooked part is that your clock should not wait for them. If a dependency is vulnerable and unpatched upstream, your exposure starts the day the advisory drops — not the day your vendor gets around to a fix. That sounds harsh. It's. The alternative is treating your own persistence window as hostage to a vendor's backlog.

What I recommend in routine is dual tracking. One clock runs for your own remediation effort. Another tracks upstream delay. When the upstream clock crosses a threshold you set — say, forty-five days — you shift from "wait for vendor" to "mitigate locally." Maybe that means disabling the feature, adding WAF rules, or shipping a wrapper that filters the dangerous input. The persistence window should trigger that shift, not just sit there as a passive deadline. The pitfall is assuming third-party components get the same urgency as primary-party code. They don't. So build the trigger in explicitly.

A persistence window absent a trigger is just a date you miss later.

— senior security engineer, during a postmortem on a delayed supply chain fix

One more angle units skip: maintenance windows. If you use a persistence timeline, do you include the window spent verifying the patch after deployment? Most don't. The verification step adds days — sometimes weeks — depending on how deep your regression tests go. That's real window where the vulnerability is still exploitable, even if the patch is installed. Wrong assumptions here create a gap among "we fixed it" and "it's in fact fixed." Track both. The audit clock ends at verification, not at deployment. That one-off shift reshapes how long your windows feel.

Your Next Experiment: Recalibrating One Window This Month

Pick One Finding and Trace Its Full Timeline

Choose a one-off vulnerability—one you concretely fixed last month. Not the scariest one, not the easiest. Just one with a date you remember. Now pull the record: when did the report first land? When did you confirm it was real? When did the patch ship to production, and when did the last affected host actually update? Most units stop at "we fixed it on Tuesday." That's not a persistence timeline. That's a hand-wave.

The gap amidst those dates is your real exposure window. I have seen groups swear a critical flaw lived for three days when the logs showed eleven. The fix landed on schedule; the rollout stalled on a single misconfigured cluster. Nobody counted that. So map it out — write the dates on a whiteboard if you have to. The exercise feels mundane until you notice the two-week lag amidst "patch merged" and "patch everywhere." That lag is where attackers live.

Compare Your Assumption vs. Measured Exposure

Now write down what you thought the exposure was before you traced it. Then subtract what you measured. The difference is your calibration error. Most teams assume the patch clock runs faster than it does — they confuse deployment intent with deployment reality. One client of mine kept a 72-hour persistence rule for critical CVEs. The trace showed their average was 9.4 days, because QA re-tests ate two days and change windows ate three more.

The catch is that your policy may be built on the assumption, not the measurement. That means you've been grading yourself against a fiction. Fixing that doesn't require new tools or more headcount. It requires admitting the old number was a guess dressed as a standard.

"An unmeasured persistence window is just a hope with a timestamp attached."

— field note from a red team operator, paraphrased

Adjust and Document the Outcome

Here's the experiment: pick one window — just one class of finding, say medium-severity auth flaws — and recalibrate its allowed persistence to match your measured reality. If you historically said 14 days but your trace shows 22, set the new target to 22 for now. That feels like surrender. It isn't. You're resetting the baseline so the next adjustment has a truthful starting point. Then run the next month with that number, track the actuals, and shorten it by 20%. Repeat monthly until the measured time hurts.

The pitfall is overcorrecting. If you tighten the window to 10 days when your process handles 22, you'll either fail loudly or quietly open fudging the dates. Neither builds trust. Start with what's true, then compress slowly. The goal is not a heroic number in a dashboard; it's a persistent mismatch between policy and practice that you can close without lying to yourself.

Document the whole loop — the traced timeline, the old assumption, the new target, and what broke when you changed it. That writeup becomes your template for the next finding. One window this month; another next month. Within a quarter you'll have a persistence clock that reflects reality, not ritual. That's the experiment. Run it.