Security Remediation Governance

The problem in one line. A finding is not remediated when the ticket closes. It is remediated when someone independent has confirmed the weakness is gone, and nothing in the process lets “closed” mean less than that.

Why remediation stalls

Most stalled remediation is a governance problem that looks like a tooling problem. Security finds the weakness, but infrastructure, application or business teams own the change. Security is measured on the backlog; the owning team is measured on availability and delivery. Without an agreed rule for who fixes what, by when, and what happens if they cannot, the backlog turns into a negotiation repeated finding by finding.

The problem compounds when one weakness arrives through several doors. A scanner reports it, a penetration test confirms it, an audit cites it and an incident review rediscovers it. Each gets its own ticket, its own owner and its own deadline, and the weakness survives all four.

This note covers what happens after a finding has been prioritized. Prioritization and validation technique are covered in the related reading below. The model here is practitioner judgment, built to be adapted to your change process.

The minimum governance model

On exploitation evidence: CISA’s Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of active exploitation, and the Exploit Prediction Scoring System (EPSS) estimates the probability that a published vulnerability will be exploited in the next 30 days. Both are useful signals for moving a finding up a tier. Neither replaces judgment about the asset, its exposure and what sits behind it.

Closure states that mean something

“Fix deployed” is where many programs stop reporting. The gap between deployed and verified is where reopened findings hide: a patch that did not apply to every host, a configuration reverted by the next deployment, a rule that was changed on the wrong environment. Closing that gap is the single most useful change most teams can make.

One register, many sources

Run every source of findings through the same register and the same rules: vulnerability scans, penetration tests, red team reports, audit observations, cloud posture findings and incident reviews. De-duplicate by root cause rather than by identifier, so the same weakness found three times has one owner and one deadline.

Post-incident actions deserve particular care. They are the commitments most likely to be made in a review meeting and forgotten, and they carry the most credibility with leadership when they are delivered. Give them the same owner, deadline and verification path as any other finding.

Fix the source, not the instance

Recurring findings are a signal that fixes are being applied to instances while the source keeps producing new ones. Tag every finding with a root-cause category, such as base image, build pipeline template, configuration baseline, missing control, process gap or third-party component. When a category recurs, the remediation target is whatever produces it: the golden image, the infrastructure-as-code module, the pipeline template or the baseline. One upstream fix retires a whole class of findings; instance-by-instance patching brings it back on the next build.

What to track

Be cautious with measures that reward volume. Total findings closed favors easy, low-risk fixes. Average time to fix across all findings hides the few that matter. Raw counts of open findings, without tiers, say more about scanner coverage than about risk.

Running the forum

Hold a short remediation review on a fixed cycle that matches your change process. Owners from infrastructure, application and security attend. Discuss only what needs a decision: findings past deadline, exceptions about to expire and reopened items. Record each decision, and send anything unresolved up the escalation path to a named executive.

Two rules protect the process. Security does not grant exceptions to its own findings, and it does not accept risk on behalf of another team. Risk acceptance belongs to someone with authority over the business consequence, and approved exceptions belong in the risk register.

Where to start if governance is thin

1. Pick one source of findings and run it through the full model before extending to others.

2. Name owners at asset level, not team level.

3. Agree tiers and deadlines with the people who carry the risk.

4. Build exception expiry into the tooling so it cannot be skipped.

5. Add a “verified” state and stop counting closures that lack it.

6. Report aging past deadline to those who can act on it.

Sources

Known Exploited Vulnerabilities Catalog — CISA

Exploit Prediction Scoring System (EPSS) — FIRST