Your fix policy gives "authenticated only" flaws 90 days and unauthenticated ones 7 — would you defend that split or change it?

## Why the split exists at all A single short window for every finding is not a stricter policy; it is an unenforceable one. Teams cannot fix everything in seven days, so the exception queue becomes the real policy, exceptions get granted by whoever is loudest, and the programme loses the ability to say what is actually required. Tiered windows are how you keep a rule that people meet. Do not argue against tiering. Argue about where the tier boundary is drawn. ## The boundary is drawn in the wrong place "Authenticated only" is a description of an advisory's wording. The property you actually care about is whether the position the flaw needs is one your estate hands out cheaply. Those two coincide on some systems and diverge sharply on others: - On a hand-provisioned internal tool with 40 named users, authenticated is a genuine restriction. - On a self-service multi-tenant product, authenticated is one signup away from unauthenticated, and a 90-day window on those findings is a 90-day window on internet-reachable findings. - On build infrastructure, "requires local execution" is granted to anyone who can open a pull request, so a class named after locality is misclassifying its most exposed host type. So the re-cut is: name the classes after **who holds the position**, not after the precondition's label. Something like *position held by nobody outside a named list*, *position obtainable by any customer or contractor*, *position obtainable by any anonymous party*. The last two collapse into the short window regardless of the word "authenticated". ## The three clauses that keep it honest **Chain-aware.** Preconditions are joints. If an unauthenticated finding in the same trust zone yields the account or the execution position that a slower-class finding needs, the pair inherits the shorter window. Without this clause the policy reliably grants three months to the second half of an externally reachable path. **Population-aware.** Set an explicit threshold and a self-service test. Above N holders, or where the position can be obtained without a human approving anything, the class collapses to the short window. A number here is worth a paragraph of judgment, because a number can be applied by someone who has never met you. **Change-triggered.** The classification is a fact about the estate, so it expires when the estate changes. A product moving to self-service signup, a repository going public, a build trigger that begins running contributor content, two VLANs merged during an office move: each of those silently reclassifies a slice of the backlog. Name those events in the policy and require a re-sort when one happens, because nobody will think to do it otherwise. ## What you owe the people who can refuse Engineering owns the capacity, and a policy they cannot apply is a policy they will route around. Three obligations follow: - **Mechanical application.** A service owner must be able to classify a finding with one question they can answer themselves. If the rule requires a security engineer's judgment per finding, it does not survive contact with four hundred services. - **A window on every class.** "Best effort" is not a class. If the longest tier has no date, the tier is an exemption with better manners. - **Predictable reclassification.** If a finding can jump from 90 days to 7 overnight, say in advance exactly which events do that. Surprise escalations are how a policy loses the goodwill it needs. ## The constraint from outside Contracts and regulators frequently fix remediation windows against a published severity score rather than against your position classes. You usually cannot replace their scheme, and you should not try. Keep the contractual scoring for reporting and obligations, and use position for **sequencing** inside the window it gives you. Where the two genuinely conflict, the contractual clock wins and you carry the cost; where the contract is silent, position ordering is what stops the team from fixing the wrong things first. Be able to say this cleanly, because an auditor asking why a finding sat for 80 days deserves an answer that references the agreement, not your internal taxonomy. ## The failure mode to name explicitly The policy this question is really testing against is the one that ranks by precondition count: more listed preconditions, longer window, encoded as a formula so it looks objective. It is objective, and it is objectively measuring the wrong thing, because a precondition your own architecture grants for free scores the same as one nobody can satisfy. If you inherit such a policy, the highest-value change is not tightening the numbers. It is replacing the input. ## What a strong answer sounds like Defend the tiering, attack the boundary, and land the three clauses. Then concede what the split still cannot do: it is a sequencing tool with fixed capacity behind it, so if the short-window class is larger than the team can service, the honest response is to say so and argue for capacity or for reducing the position-granting surface, not to quietly widen the classes until the backlog fits.