Your security backlog is all audit checkboxes while incidents come from elsewhere — how do you rebalance?

## The situation, stated honestly The backlog is full of items whose only justification is a framework row. The incidents of the last year came from somewhere else. Both facts are real, and the naive conclusion — do less compliance work — is wrong, because the certificate is attached to contracts and the contracts are attached to revenue. The problem is not that obligation work exists; it is that obligation work and risk-reduction work are competing for the same engineers out of the same queue, judged by the same metric, and the metric favours the checkbox. ## Separate the portfolios and fund them differently Make the split explicit and visible: **Obligations.** Work that exists because a framework, a regulator or a customer contract requires it. Success is 'satisfied and evidenced'. It is a **cost to minimise**, not a risk to reduce, and the way to minimise it is to automate the check and the evidence so that satisfying it next quarter costs nearly nothing. Every hour spent automating a control's evidence is an hour permanently removed from this portfolio. **Risk reduction.** Work justified by measured exposure — incident and near-miss patterns, leading indicators, threat coverage. Success is a metric moving. The overlap is the good part: a control that is both obligatory and effective. Aim to grow that overlap by re-implementing obligations as effective checks rather than by adding separate work in both columns. ## Change the number, or the backlog will not change The backlog optimises for whatever is reported. A single pass-rate figure rewards adding many easy controls and punishes replacing one weak control with one strong one that starts red. So publish a second axis alongside it. Useful candidates: - A small set of exposure indicators with real variance: 95th-percentile time from leaver event to access revoked, proportion of privileged accounts with a phishing-resistant factor, count of production services outside the standard identity path. - Control-to-incident coverage: of the last N incidents, how many had a control whose failure would have caught it. - Evidence cost: engineer-hours per control per quarter, which makes automation visibly pay for itself. And say plainly what pass rate is: a measure of **obligation satisfaction**, not of security. Leadership reading 98 percent as assurance is the most expensive form of satisfied-but-ineffective in the organisation, because it drains urgency from the work that is not on the report. ## The leverage is at the interpretation layer Between a framework objective and an internal control there is a translation step, usually done once, years ago, by someone copying a common implementation. That translation is where the checkbox was born and where it can be rewritten. Most frameworks state an **objective** — authenticate users appropriately, restrict access to what is required — and leave the implementation to you. So the same objective that produced a 90-day rotation control can be re-implemented as phishing-resistant factors plus compromised-credential monitoring plus deprovisioning driven by the HR leaver event, and still satisfy the objective. Do this with the auditor in the room **early**. An auditor asked in advance whether a proposed implementation satisfies an objective will usually engage with it; an auditor shown a retired control at fieldwork will raise a finding. Bring the mapping, the check and the evidence format together — how the new control will be sampled matters as much as what it does. ## Sequencing, so nothing goes red on the way Run the replacement in parallel for at least one reporting period, keeping the old control alive. You get a clean transition with both evidence sets, a real measurement of the new control's red rate before anything depends on it, and no window where the report shows a gap. Retire the old control at a period boundary, in writing, with the mapping updated. ## Choose the fights Not every checkbox is worth attacking. Three tests for whether to spend the political capital: 1. **Does it consume real engineering time each quarter?** If so, automate the evidence first and reassess; the cheapest win is usually cost, not deletion. 2. **Does it cause harm?** Some controls actively degrade security — mandatory rotation producing predictable mutations is the canonical case — or train people to treat the security function as an obstacle. Those are worth the fight. 3. **Does it give false assurance?** A control that leadership believes covers a risk it does not cover is worse than no control at all, because it suppresses the funding request that would fix the risk. A cheap, automated, harmless checkbox that nobody thinks about fails all three. Leave it green and spend the quarter elsewhere. Knowing which battles not to fight is most of what separates a lead who changes the programme from one who is known for complaining about compliance.