Hundreds of denies in a migrated rulebase are unreachable and an intruder can ride them, but their owners have left — what do you fund, and what do you accept?

## What you are actually asking for The instinct is to present the analysis output — thousands of findings, hundreds of unreachable denies — and ask for headcount to work it. That framing loses, in both directions. If leadership says no, you have documented an unaddressed risk you named yourself. If they say yes, you have committed to clearing a backlog whose true blocker is not effort. The blocker is authority. Almost every fix in this backlog is a change to a rule whose requester, approver and business owner have all left the organisation, on a path whose current traffic you cannot see. The technical work per fix is minutes; the search for someone willing to say *yes, close it* is unbounded. ## Frame it as exposure, not as findings What travels upward is: **this policy permits paths it claims to deny.** Not an anomaly count. Concretely — of the unreachable denies, these ones cover paths from a lower-trust segment into an administrative plane, and an intruder with a foothold in that segment does not have to defeat any control to use them; the control is not in effect and has not been for years. That is a statement a non-specialist can act on, and it survives being repeated by someone else in a meeting you are not in. "Four thousand policy anomalies" does not. ## The three asks **1. A decision, not a tool.** State plainly that another analyser would produce a longer report and no change in outcome, because detection is not the constraint. What you need is a standing rule: *a flow with no identifiable owner is not a reason to keep a permit.* Such flows are closed in an announced window and restored within an agreed time if a genuine user appears. That is a business-availability decision — somebody with authority over service continuity has to own it, and if nobody will, that itself is the honest answer to why the rulebase never gets cleaner. **2. A time-boxed re-baselining with a named owner.** Not "clean the rulebase" but a scoped piece of work: the exploitable class only, ranked by what each deny names, worked in announced windows with rollbacks, ending on a date. A project with an end can be staffed; an ongoing hygiene commitment cannot. **3. The change gate.** Whole-policy analysis on proposed changes, failing only on anomalies the change introduces against the recorded baseline. This is the cheapest item on the list and the only one that makes the problem finite. Without it, cleaning is a permanent staffing line, because every removal is replaced by the next migration or the next urgent permit. ## What you accept, out loud Acceptance is not defeat; undocumented acceptance is. Write down which classes stay open and why — redundancy carries no exposure and is not funded; broad-below-narrow structure is intentional and is touched only when someone is already editing that area; partial overlaps are reviewed by segment on a schedule. A recorded acceptance with a reason and a review date is a defensible position in front of an auditor or a customer's security questionnaire. The same findings sitting unread are indistinguishable from negligence, and the only difference between the two is the write-up. ## The assurance conversation nobody wants If a deny rule was ever presented as evidence of a control — in an audit, an attestation, a customer questionnaire — and analysis now shows it unreachable, the honest position is that the control was not in effect for that period. Scope the window, hand over the analysis output as the evidence, and change what you present in future: a rule's text is a claim, and the analysis result is the evidence. Continuing to present rule text you now know may be unreachable is where a documentation problem becomes a misrepresentation. ## Where a principal answer earns its level - It distinguishes what money buys (a time-boxed project, a gate) from what money cannot buy (permission to break an unowned flow). - It refuses to promise full remediation and says why the refusal is the trustworthy answer. - It names who owns each decision — availability owns the breakage rule, security owns the ranking, engineering owns the gate — rather than absorbing all of it into the security team and quietly missing. - It treats the accepted remainder as a deliverable with a review date, not as silence. ## The failure modes Committing to zero findings. Asking for tooling when capacity is the constraint. Deleting unowned permits without a window because the analysis says they are shadowed — the analysis says nothing about who depends on them. And reporting a falling anomaly count as progress while the exploitable class is untouched, which is how a metric replaces the outcome it was meant to represent.