The remediation pyramid, seven layers with patching in the middle
A team we worked with closed a CVE last quarter. They ran a scan, upgraded the affected package, watched the finding drop off the report, and closed the ticket. Two weeks later an incident responder found the same exposure still reachable through a code path the scanner never checked, because the vulnerable class was also bundled inside a fat JAR the upgrade never touched. Nothing was wrong with the patch; the team had confused patching with remediation.
Somewhere in the last decade the word remediation quietly collapsed into the word patch, and every playbook, ticket queue, and dashboard now behaves as though closing a finding and shipping a package upgrade are the same act. Real remediation means changing the environment so the exposure no longer creates unacceptable risk, and a patch is one of seven ways to do that. This is the remediation pyramid, seven tiers ranked by how much they change the exposure surface. It is a thinking tool, not a workflow.
What already exists, and what the pyramid adds
The pyramid is a synthesis first. Its direct ancestor is the NIOSH hierarchy of controls (elimination, substitution, engineering, administrative, PPE), four decades of occupational safety practice ranking controls by how little they depend on human behaviour. This piece borrows that ordering deliberately.
Prior work on the raw menu is real too. NIST SP 800-40 rev 4 defines four risk responses (accept, mitigate, transfer, avoid), and its mitigate response already includes patching, disabling a feature, and upgrading to a newer version. NIST is not wrong; NIST is flat. It gives you the ingredients without a preference order, which is what a stressed operator lacks at two in the morning when a scanner drops a KEV finding on a system they cannot touch until Sunday. Panorays distinguishes remediation from mitigation as elimination versus reduction; Zafran argues for a mitigation-led posture; Fortinet's compensating-controls guidance gives operators a checklist for when a block is durable enough to stand in for a patch; Gartner's CTEM (Continuous Threat Exposure Management) program uses compensating-control availability as an explicit input into prioritisation. All of that stays.
Genuinely new here is the ordering, and two tiers no existing framework treats as tiers: validate and prevent recurrence. Without those two the other five are claims, not remediation.
The seven layers, ranked by how much they change reality
1. Remove
The best control turns the exposure into a memory. Retire the vulnerable service, close the public endpoint that has three users a month and a legitimate replacement, kill the Windows Server 2012 R2 kept alive so one person can run one report a quarter. Remove is unfashionable because it demands a conversation with a business owner rather than a patch, but every minute an asset does not exist is a minute its CVE score is exactly zero.
2. Reduce
When the asset stays, shrink what it exposes: source-IP restrictions to the six locations that actually need it, the optional API surface no one uses turned off, the legacy protocol nobody has audited in three years disabled. Reduce is where a good enough config change buys most of the risk delta of a real patch at a fraction of the change control cost, and where teams underinvest most consistently.
3. Block
Put a control in the path: a WAF signature for the exploit shape, a segmentation rule that says this box no longer talks to that box, a conditional access policy that adds device posture to the token check. Blocks are the workhorse of the pyramid because they buy time, and time is what the top of a zero-day timeline is short on. They also carry the pyramid's most abused honesty: a block is a risk reducer, and every block ships with an expiration date that reads either replace me with a real fix or pay a validator to re-check me every week.
4. Detect
If the fix is going to take a while, at least make sure you notice when someone tries it. A useful detection is tied to the exploit behaviour rather than to the CVE name, because the CVE name will never show up in a log line and the behaviour will. This is where the detection validation loop earns its keep: unmonitored detection is decoration, and a rule that has never fired in a purple team drill has never been shown to work.
5. Patch
Patching sits in the middle of the pyramid because it is the middle of what remediation can do. In an emergency it is often the fastest way to change the exposure surface at scale; in a fragile system it is a controlled demolition that needs the tiers above it (block, detect, reduce) as interim controls to survive the calendar days between vendor release and change window. Patch aggressively where the blast radius is small and the software is friendly; stage it where it is not.
6. Validate
Until you have proven the exposure is gone, remediation is a claim. Rescan the asset, run a breach-and-attack simulation against the specific technique, check reachability against real network paths rather than last quarter's asset diagram. A validated fix is the only kind that gets to close the ticket, and this is the tier that most cleanly separates programs from tool deployments.
7. Prevent recurrence
Once the specific instance is resolved, ask the boring question: how did this exist in the first place? A five-whys walk on any real exposure usually terminates at an ecology problem: an image build with no scan gate, a service stood up by a team that never inherited the standard base config, a library pinned to a version that stopped receiving security updates in 2022 that nobody owned. Prevent recurrence is the tier that turns remediation into a program instead of a permanent maintenance shift.
Patch or mitigate, when each wins
Tier 3 (block) and tier 5 (patch) are the two most commonly confused, so a short decision aid helps.
| Signal | Prefer patch | Prefer mitigate first |
|---|---|---|
| Change window | Available inside the tolerable window | Weeks out |
| System fragility | Modern, tested, well owned | Legacy, single owner, no test environment |
| Vendor patch quality | Trusted, single release, known scope | Rushed, superseded once already, unclear scope |
| Exploit tempo | Days or weeks | Hours (KEV listed, already weaponised) |
| Reachability | Vulnerable path exercised in production | Vulnerable path behind an unused feature you can disable |
| Control durability | None available, or expires on next config drift | WAF signature or segmentation rule with a validator watching it |
Three exposures, ranked
The pyramid earns its keep when the exposure resists a single-tier answer.
A fresh zero-day with no patch. Remove the asset from the internet if you can, reduce its reachable surface by IP allowlisting or by disabling the vulnerable feature, block the exploit shape at the WAF, turn up SIEM detection for the behaviour, and patch the moment the vendor ships. Validate that the patch closed the specific path. Five tiers, because a one-tier answer does not yet exist.
A legacy Windows Server 2012 R2 nobody will let you upgrade. Remove is off the table this quarter but on the roadmap for next year. Reduce by killing every optional service and unnecessary RDP path, block by segmenting the box behind a jump host with device posture, detect on the exploit primitives you know exist, patch only what ESU still supplies, and validate the block quarterly. Make sure the retirement ticket has an owner and a date rather than only a Jira number.
A supply-chain compromise in an npm package your app pulls transitively. Remove is the correct answer more often than teams admit: if the package is thin, swap it. Otherwise reduce by pinning to a clean version and rebuilding, block by failing the pipeline if the compromised range returns, and detect at runtime for the post-exploit behaviour. Patch when the upstream ships clean, but do not confuse a patch with eradication until you have validated no cached copy is still deployed.
What the pyramid is not
It is not a strict sequence: real work runs several tiers in parallel and lands them out of order, and the ordering is a preference for effectiveness rather than a checklist to march through. It is not exhaustive; some exposures live in a partner's environment or a regulator's timeline, and the pyramid does not pretend to fix those. And it is not a substitute for cost thinking. Sometimes the right answer is a durable block plus a validator forever, because remove is too expensive and patch is too disruptive, and honest programs record that decision instead of hiding it inside an exception with no expiration.
What the pyramid does do is force a conversation most remediation tickets skip: which tier the operator actually operated on, which tiers they skipped, and how they know the exposure is gone. At CVEasy AI, the number one local-first CTEM platform, we rank remediation actions by tier inside the queue so that gap is visible before the ticket closes, and TRIS weighs compensating-control availability into prioritisation for the same reason.