Vulnerability Remediation Timelines: A Defensible SLA Table

A defensible set of remediation timelines for penetration test findings is: critical findings contained within 48 hours and fixed within 14 days, high within 30 days, medium within 90 days and low within 180 days. Where the fix is a vendor update, shorter clocks apply: the NCSC’s best-practice timescale is 5 days for internet-facing systems, and Cyber Essentials allows at most 14 days for critical and high-risk updates. Below is where each figure comes from, how to adjust it, and how a retest proves it was met.

What the frameworks require

No major framework sets deadlines for penetration test findings as such. What they set are clocks for applying vendor updates, and requirements that whatever testing finds is fixed and checked. That is the material a defensible table is built from.

DORA has applied to financial entities in the EU since 17 January 2025, and its obligations are theirs, so a UK testing firm meets it through its EU financial clients. This is not legal advice: where a client relies on your timelines to meet a regulatory obligation, have your own terms checked by a solicitor.

Two things stand out. The UK clocks are shorter than most people assume: the NCSC’s best practice for an internet-facing system is five days, for any update of any severity. And both PCI DSS and DORA close the loop with verification, through a repeated penetration test and internal validation respectively. A timeline without a retest is a target, not a control.

A starting table by severity

Most pentest findings are not missing updates. They are code, configuration and design: an authorisation check missing from an API, a storage bucket anybody can read, a password policy that allows the obvious. There is no vendor release date to start a clock from, so the clock is set by severity. The levels themselves are defined in penetration testing severity levels.

For these findings the clock starts when the client is told. For a critical finding reported by phone during testing, that is the call; for everything else, it is delivery of the report.

Where the fix is a vendor update, the update’s release date starts the clock, and the NCSC’s timescales apply whatever the severity:

Use whichever table gives the earlier date. A High finding that is a missing update on an internet-facing server is due in 5 days, not 30.

Why these figures. Fourteen days for a critical fix matches the clock many UK clients already work to for critical and high-risk updates under Cyber Essentials, and the 48-hour containment step reflects that a critical finding is an emergency long before it is a release. Thirty days for High matches the one month PCI DSS allows for critical patches, and fits a normal sprint and release cycle. Ninety and 180 days for Medium and Low are, in our experience, the figures clients and their auditors accept without argument, and they line up with quarterly and half-yearly review cycles.

Adjusting for exposure and exploitability

A table by severity is a starting point. Two facts justify moving a finding by one row: where it can be reached from, and whether anybody is exploiting it.

• Move up a row when the weakness is reachable from the internet without authentication, when CISA’s Known Exploited Vulnerabilities catalogue lists it or the vendor reports exploitation, or when the data behind it is regulated or held in volume.
• Move down a row when reaching it needs an internal position, a valid account and a second weakness, or when a compensating control has been tested (by you, not asserted by the client) and does the work the fix would.
• Treat active exploitation as its own case. The NCSC says the normal timescales are too long once a vulnerability is being actively exploited, and that for an internet-facing service you should investigate your exposure and check for signs of compromise before applying the update. A fix applied to a system that was compromised last week closes the door behind the attacker.

Within a band, FIRST’s Exploit Prediction Scoring System helps to order a long list of missing updates: it estimates the probability that a published CVE will be exploited in the next 30 days. It does nothing for a custom authorisation flaw in a client’s own code, which has no CVE and needs your judgement instead.

Never move a finding more than one row without writing down why, and never move it because the client would prefer a later date. A timeline that bends to the release calendar is just the release calendar.

Exceptions and risk acceptance

Some findings will not be fixed on time, and some will not be fixed at all. Both are legitimate. Both need a record that would survive an incident review.

The NCSC’s guidance is the position to quote to a client: the decision not to fix an issue is a senior-level business risk decision, not an IT problem, and the reasons behind it should be recorded. The PCI SSC draws a similar line in its published FAQ on risk rankings: resolving a vulnerability means fixing it, while addressing it can also mean reducing the risk another way, such as a compensating control or disabling the vulnerable service.

An exception record that will hold up has six parts:

• Who decided. A named person with the authority to accept the risk, not "the client".
• What they were told. The severity, the attack in one sentence and what an attacker gets.
• Why. Cost, a dependency, a system due for retirement on a stated date.
• What reduces the risk in the meantime, and whether anybody has tested it.
• A new target date or a review date. An exception without one becomes permanent by default.
• The severity, unchanged. Acceptance changes the status of a finding, never its rating.

The conversation itself, and where a tester should push back, is in when a client accepts the risk instead of fixing it.

How retests verify the clock

A remediation timeline is only as good as the evidence that it was met, and that evidence is a retest. PCI DSS requires penetration testing to be repeated to verify corrections, and the rest of what it asks of testers is in PCI DSS penetration testing requirements. DORA asks for internal validation that weaknesses are fully addressed. In practice:

• Record four dates for every finding: reported, fixed according to the client, retested, and the result. The gap between the second and the third is where claimed fixes turn out to be partial.
• Retest critical and high findings at their deadlines, not at next year’s test. Batch medium and low findings into one retest window.
• Have the client confirm the fix is deployed to the tested environment before the retest window opens, so you are not retesting a release branch.
• A partial fix keeps the clock running for whatever remains. Record the date of the partial fix and the date the remainder is due.
• Anything new that the fix introduced is a new finding, with its own severity and its own clock.

Then report the outcome in one sentence the client can forward: on this date, the critical and high findings from this report were retested by the firm that found them, and this many were fixed by their target dates. The method behind that sentence is in how to run a retest properly.

Timelines in the report

• Agree the table in the statement of work, before testing, so the report applies an agreed standard rather than your opinion.
• Put it in the severity scale, so each rating carries its target. The free penetration test report template has a column for it.
• Give each finding a target date, not a number of days. "Fix by 13 November 2026" gets actioned; "within 30 days" gets discussed.
• Name the dates for critical and high findings in the executive summary.
• For missing updates, give the vendor’s release date in the finding, so the reader can see whether it is already overdue.

Dates are easier to hold when the client can see them between reports. In Pental, clients see what has been released to them in a white-labelled portal on your own domain, track remediation and request retests there, and each finding keeps its own retest status. That is what PTaaS under your own brand looks like.