The vulnerability remediation process: from finding to proven fix

A vulnerability remediation process is the repeatable path a finding takes from "reported" to "proven fixed": triage it, give it one owner, fix it inside an agreed deadline, verify the fix, and close it with evidence. If any of those steps is missing, findings sit in a backlog and the same flaw comes back at the next test.

This guide takes a finding through each stage for software teams that receive findings from penetration tests, scanners, bug reports and dependency alerts. You can adopt all of it this week, and where a standard says something specific, the text names it.

What is the vulnerability remediation process?

The word "remediation" covers more than patching. NIST's patch guidance describes enterprise patch management as identifying, prioritising, acquiring, installing and verifying updates. The same shape applies to flaws in your own code, where the fix is a code change and not a vendor patch.

A good process answers five plain questions for every finding: is it real, how much does it matter here, who fixes it, by when, and how do we know it is gone. Most teams can answer the first two. The last three are where findings stall, usually because nobody was named, the deadline was never agreed, or "done" meant "the ticket was closed" and not "the exploit no longer works".

It also helps to separate three things people mix up. Vulnerability management is the whole programme: scanning, testing, tracking and reporting. Remediation is the part where a finding gets fixed. Patch management is the narrower job of applying vendor updates. This post covers the middle one, and it assumes findings arrive from somewhere, such as a penetration test, a scan or a disclosure from an outside researcher.

The stages at a glance

Seven stages cover almost every case. Small teams can run them in one shared tracker; larger ones add tooling. What matters is that each stage has an output you can check.

Why does remediation speed matter?

Speed matters because most of the risk window sits in your own queue, and exploited flaws are used quickly. Four public numbers, read together, set the tone for the rest of this guide.

• The Verizon 2026 Data Breach Investigations Report states that 31% of breaches now start with software vulnerabilities.
• The IBM Cost of a Data Breach Report 2026 gives a global average breach cost of 4.99M USD, a 12% increase over the previous year.
• CISA's earlier Binding Operational Directive 22-01, since revoked and superseded by BOD 26-04, noted that less than 4% of CVEs have been publicly exploited, but that of those, 42% were used on day 0 of disclosure, 50% within 2 days and 75% within 28 days.
• The CISA Known Exploited Vulnerabilities catalog lists 1,734 vulnerabilities at the time of writing (8 October 2026).

Two lessons follow. Few flaws are ever exploited, so not every finding is an emergency. Those that are get used fast, so the urgent few must never wait in a general queue. That is why triage and deadlines are separate stages below.

Stage 1: Intake and de-duplication

Findings arrive from many places: a pentest report, a scanner export, a bug bounty or disclosure email, a customer security questionnaire, a dependency alert. If each source has its own spreadsheet, the same flaw is tracked three times and fixed zero times.

Pick one system of record. It can be your normal issue tracker with a "security" type and a few required fields. Each real issue gets one record, and duplicates link to it. Fifty scanner alerts for one missing header are one finding.

Record these fields at intake and refuse to move on without them:

• A one-line title that says what is wrong and where, for example "Invoice API returns another customer's invoice by ID".
• The source and date it was reported, because the deadline clock starts here.
• Evidence: the request and response, a screenshot, or the line of code. A finding with no evidence goes back to the reporter.
• The affected service or repository, so routing is automatic.
• A CWE reference where one fits, which makes later trend reporting possible. The MITRE CWE list is the common vocabulary.

A security ticket with the URL, parameter and payload costs ten minutes to act on; "XSS on the site" costs an hour.

Stage 2: Triage, deciding what matters here

Triage is two separate judgements, and mixing them is the most common mistake. The first is whether the finding is real. The second is how much it matters in your environment.

Is it real? Confidence

A scanner reports a suspicion. A tester who exploited the flaw reports a fact. Those deserve different handling, which is why severity and confidence are kept apart. A high-severity, low-confidence item needs a quick manual check before it consumes a developer. A medium-severity, fully reproduced item may deserve more urgency than the label suggests. Our post on why exploited findings beat suspected ones goes deeper on the cost of false positives.

For triage, ask for a reproduction. If the reporter gives you a request that returns the wrong data, you can replay it in two minutes and the question is settled. A scanner line needs that work done first.

How much does it matter here? Severity in context

The Common Vulnerability Scoring System gives a starting number. FIRST, which maintains it, describes CVSS as capturing the principal characteristics of a vulnerability and producing a numerical score reflecting its severity. That is a measure of how bad the flaw is in general, not how bad it is on your system on a Tuesday. Treat the base score as an input. Adjust it for your own context, using the CVSS vector and the environmental metrics in CVSS 4.0.

Add the context that changes the answer:

• Exposure. Is the affected endpoint on the public internet, behind a VPN, or internal only?
• Data and function. Does it touch payment data, personal data, admin functions or tenant boundaries?
• Exploitability. Is there a working proof of concept? How hard is it to reproduce? See exploitability.
• Known exploitation. Is this flaw being exploited in the wild? CISA's Known Exploited Vulnerabilities catalog lists those, and our KEV entry explains how to use it.
• Likelihood. The Exploit Prediction Scoring System estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It applies to CVEs, so it helps with dependency findings more than with bugs in your own code. See EPSS.
• Compensating controls. A WAF rule, a feature flag or network restriction can lower urgency, but only if someone has checked it holds.

CISA's Binding Operational Directive 26-04, published in 2026 for US federal civilian agencies, is a useful public example of this approach. Instead of fixed deadlines driven by a CVSS score, it weighs whether the asset is publicly exposed, whether the vulnerability is known to be exploited, whether exploitation can be automated, and whether it gives partial or total control. It binds federal agencies, not private companies, but the four questions transfer well to any triage meeting. Read the directive itself for the exact scope. This is the idea behind risk-based prioritisation.

The triage decision

End every triage with one of four outcomes, written on the record:

1. Fix, with a severity and a due date.
2. Mitigate now, fix later, where a temporary control reduces risk while the real change is scheduled.
3. Accept the risk, with a named approver and a review date (see the risk acceptance section below).
4. Reject, because it is not reproducible or not applicable, with the reason written down.

Run triage on a fixed rhythm, such as twice a week for a small team, and have the person who understands the service in the room. Our guide to reading a penetration test report and the post on reading a single finding show what a triage-ready finding looks like.

Stage 3: Give every finding one owner and one date

The most reliable predictor of a stalled finding is a ticket assigned to a team, a channel or "security". Assign it to one named developer or, at minimum, one named engineering manager who can reassign it. A shared queue is how items age for months.

Three things should be on the ticket when the developer opens it:

• How to reproduce the issue, in steps they can follow without asking.
• What "fixed" looks like, written as a testable statement: "Account B receives a 403 when requesting Account A's invoice."
• Remediation guidance that points at the class of fix, such as an ownership check on the server, rather than a symptom patch.

A due date comes from your service level agreement for the finding's severity. That is the next section.

What remediation SLAs should you set by severity?

A remediation SLA is an internal promise: findings of a given severity get fixed within a set number of days. It turns "we will get to it" into a deadline that can be measured. The numbers below are common starting points, not a standard. No single body publishes one deadline table for application findings, so choose figures your team can actually meet, then tighten them as your process matures.

These are illustrative. What the standards actually say is narrower, and it helps to know the difference.

What the standards actually say

PCI DSS v4.0.1

Requirement 6.3.3 expects applicable patches for critical vulnerabilities, ranked through your own risk process under 6.3.1, to be installed within one month of release. Other patches follow a time frame you set from that ranking. Requirement 11.4.4 expects exploitable vulnerabilities and security weaknesses from a penetration test to be corrected. The standard is in the PCI Security Standards Council document library; our post on PCI DSS penetration testing requirements covers the testing side.

CISA BOD 26-04

Issued on 10 June 2026 for US federal civilian agencies only, it replaces BOD 19-02 and BOD 22-01. Its Table 1 sets windows from 0 days plus forensic triage, for publicly exposed Known Exploited Vulnerabilities with automatable, total-control exploits, down through 1, 3 and 7 days to 30 and 90 days. The lowest-risk cell, a non-exposed flaw outside the KEV catalog with partial impact, is fixed on system upgrade.

SOC 2 and ISO 27001

SOC 2 and ISO 27001 auditors generally look for a documented policy and evidence that you follow it. They rarely prescribe a number of days.

The lesson from all of them is the same: write your own timelines, risk-rank consistently, and then actually meet them.

What to write in the policy

• The severity scale and who decides it. Tie it to your risk rating method.
• The clock: it starts when the finding is accepted as valid, or when it is reported. Pick one and state it.
• What happens at the deadline: automatic escalation to the engineering manager, then to the head of engineering.
• Faster tracks for known-exploited flaws, regardless of base score.

Stage 4: Fix the cause, not the example

Most application fixes fall into a few types. Knowing which one applies keeps the discussion short.

Fix the class of bug

If one endpoint lacks an ownership check, ask where else the same pattern lives. A developer who fixes /invoices/{id} and leaves /invoices/{id}/pdf open has fixed the example and kept the flaw. In the pull request, ask the author to list the sibling endpoints they checked. Better still, move the check into a shared function so the next endpoint inherits it.

Use temporary controls honestly

When the real fix will take weeks, a stop-gap is reasonable: disable a feature, add a rule, restrict the network path. Record it as a mitigation, not a closure. The finding stays open with a new, shorter review date, because a rule written against yesterday's payload is easy to get around. Treat it as a bridge, never as the destination.

Stage 5: How do you verify a fix?

Closing a ticket when the developer says "done" is the single biggest source of false confidence. A deployed change is a claim. A retest is the evidence.

The strongest check is to replay the original exploit against the fixed build. If the request that returned another customer's invoice now returns a 403, the fix works for that case. If it still returns data, or returns it through a slightly different route, you have learned something a fresh scan would not tell you. This is what closed-loop retest means: the proof of the fix is the same exploit that proved the flaw.

A new scan can only say "the scanner no longer reports this". That is weaker, because scanners miss things (false negatives) and may not exercise the same path. For logic and access-control flaws, a scan often could not find the flaw in the first place, so a clean scan proves little.

How to run a good retest

1. Keep the original reproduction steps with the finding so anyone can replay them.
2. Test on the build that will ship, not only on a developer's branch.
3. Try variations: other HTTP methods, other IDs, encoded values, the sibling endpoints, and the mobile or API version of the same function.
4. Check the response, not just the status code. A 200 that returns an empty body may still be leaking through headers or timing.
5. Record the result with the request, the response and the date, as the retest entry describes.

If your pentest provider includes a retest window, use it. PCI DSS 11.4.4 expects corrections to be verified, and most pentest buyers' guides, including ours on the VAPT checklist, make retest a named step for that reason.

Stage 6: Close with evidence and a regression test

A finding can close in three ways: fixed and verified, accepted with sign-off, or rejected with a reason. Anything else is "open".

For a verified fix, the closing record should hold:

• The pull request or change reference.
• The retest evidence and who ran it.
• The date the fix reached production, which is the real remediation date.
• The regression test that now guards it.

Measure time to remediate to the production date, not the ticket closed date. Teams that stop the clock at "merged" overstate how quickly they fix things.

Tell the people who were told about the flaw. If a researcher reported it, the OWASP cheat sheet on vulnerability disclosure recommends acknowledging the report, giving regular updates, confirming the fix and, where useful, asking them to retest. The OWASP guidance has the detail.

When is risk acceptance the right call?

Sometimes the right answer is not to fix, or not yet. A legacy admin screen behind a VPN, used by two people, may not justify a rewrite this quarter. That is a legitimate decision as long as it is a visible one. Risk acceptance without a record is just neglect with a polite name.

A usable acceptance record has:

• The finding, its severity and the evidence.
• The reason for not fixing now, in business terms: cost, dependency on a vendor, planned retirement of the system.
• Compensating controls in place, and who verified them.
• A named approver with the authority to carry the risk. That is a business or engineering executive, not the person who found it or the person who would do the fix.
• An expiry date, set by how serious the risk is, after which the decision is reviewed.

Put accepted items on your risk register, and report them with the open findings, not separately. Auditors often ask for exactly this. An accepted risk that reappears at the next pentest with no expiry date or approver tells them nobody is minding it.

Never accept your way out of a known-exploited flaw on an internet-facing system without escalating it. That is the case where a deadline and a mitigation matter most.

Which remediation metrics should you track?

Pick a small set and report it monthly. A long dashboard hides the three numbers that matter.

Where the process usually breaks

• No single owner for the process. Someone has to run triage and chase deadlines. That is a role, even when it is 10 per cent of one person's week.
• Everything is "high". If most findings are high, the labels stop carrying information. Use context to move items up and down, and keep confidence separate.
• Fixes that close the example, not the class. The invoice endpoint gets its check and the PDF endpoint beside it does not. Ask for sibling endpoints in every pull request.
• Retests that never happen. A closed ticket feels like progress. Without a replayed exploit, nobody knows whether the fix holds.
• Risk acceptances that never expire. A one-time decision becomes permanent policy by default.

Fitting remediation into continuous testing

If you test more often than once a year, remediation has to run as a steady flow of small tickets, short deadlines and automatic retests. Our guide to continuous penetration testing explains how annual and continuous testing fit together.

Where Cyberlop fits

Cyberlop finds vulnerabilities in web apps and their APIs with black-box, grey-box and white-box pentesting. It reports only what it actually exploited, so each finding arrives with the request, the response, a screenshot where a person can see it, and, in white-box mode, the line of code. That removes the reproduction step from triage. Severity and confidence are kept apart, and findings carry CWE and OWASP references, which makes routing and trend reporting simpler.

When the fix lands, Cyberlop re-runs the exact exploit against the new code, which is the verification stage described above. It can also run on a schedule or in CI/CD and gate a build. For how a finding is laid out, see how it works and what the evidence looks like. Teams under regulatory pressure can see how this supports audits.

No tool replaces the owner, the deadline and the sign-off. This process works with any source of findings.