Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we set remediation deadlines the business will actually agree to?

6 decision pointsThe pack behind this answer: Vulnerability & Exposure Management

Add to board memo

The short answer

Recommendation
Set one deadline per priority, counted from first detection, and test the draft against your last three months of findings before anyone approves it. Where the test shows routine misses, add capacity or lengthen the deadlines now, and send the genuinely hard fixes to time-limited exceptions.
Reasoning
A standard that is routinely missed is worse for audit than a realistic one that is met. Testing the draft against your own findings turns a negotiation about opinions into one about your numbers. Deadlines follow priority, which already reflects exploitation and exposure, but they do not reflect effort, so the few hard cases belong in exceptions instead of longer deadlines for everything. A fix counts only when a scan confirms it, so plan the confirming rescan too.
Considerations
  • The deadlines of 7, 14, 30 and 90 days, the one-fifth test and the 90% adherence starting point are the defaults in the CISO Times vulnerability pack. Your own standard may set different ones.
  • Some limits are not yours to choose. Where payment card data is in scope, that standard expects critical security patches within one month of their release, while the pack counts from detection, so record the release date too and work to whichever comes first.
  • The approver of the standard approves its deadlines. If IT and the asset owners have not clearly accepted them, put the choice to the approver with the backtest figures. Silence is not acceptance.
  • Where a service provider fixes some of your systems, copy the same deadlines into its agreement so its priorities match yours.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartIT and the business must sign up to fix deadlinesStepDraft one deadline per priority from the defaultsDecisionDoes a regulation or contract set a maximum?StepKeep the affected priorities inside that limitStepRate the last three months of findings against themDecisionWould over a fifth of Priority 2 and 3 findings be late?DecisionCan remediation capacity be added?StepAgree the extra capacity alongside the deadlinesStepAgree longer deadlines now, before approvalDecisionCan a scan confirm each fix before its deadline?StepPlan targeted rescans to confirm fixesStepSend the hard fixes to exceptions, not to the deadlineDecisionDo IT and the asset owners accept the deadlines?StepPut the choice to the approver with the backtestStepApprove the deadlines in the standardDecisionEach quarter, is a priority consistently below target?OutcomeKeep the deadlines and review them yearly

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 17 steps.

  1. Start

    IT and the business must sign up to fix deadlines

    Deadlines only work if the people who fix things believe they can meet them. A standard that is routinely missed is worse for audit than a realistic one that is met. So the goal is a set of deadlines that has been tested against your own workload before anyone approves it.

    In the pack

  2. Step

    Draft one deadline per priority from the defaults

    Tie deadlines to priority, which already reflects exploitation and exposure, and not to the scanner's severity label. The pack's defaults are: Priority 1 mitigated within 72 hours and fixed within 7 days, Priority 2 in 14 days, Priority 3 in 30 days, Priority 4 in 90 days. Count calendar days from the date the finding was first detected on the system, not from when a ticket was raised. A change of priority changes the length of the deadline, never its start.

    In the pack

  3. Decision

    Does a regulation or contract set a maximum?

    Some deadlines are not yours to choose. The pack notes that the payment card standard expects critical security patches within one month of the patch's release, not of detection. Where a service provider runs some of your systems, it fixes them within the deadlines in its contract. If you are not sure whether an outside limit applies, find out before drafting further.

    In the pack

  4. Step

    Keep the affected priorities inside that limit

    Check which priorities the outside limit touches and keep their deadlines within it. In the pack's defaults, Priorities 1 to 3 all fall within one month, and every Critical or High severity finding lands in one of them. Record which priorities you treat as meeting the outside requirement, so an assessor can see the mapping. For those findings, record the patch's release date beside the date of first detection, and work to whichever deadline comes first.

    In the pack

  5. Step

    Rate the last three months of findings against them

    Take the last three months of scanner findings and rate them with your priority model. Count how many fall in each priority, and how many would have missed the draft deadline given the fix dates you actually achieved. This turns a negotiation about opinions into one about your own numbers.

    In the pack

  6. Decision

    Would over a fifth of Priority 2 and 3 findings be late?

    The pack's test looks at Priority 2 and 3 findings. More than one in five overdue means the deadlines, as drafted, would be missed as a matter of routine. If you cannot yet tell, for example because fix dates were never recorded, treat it as yes.

    In the pack

  7. Decision

    Can remediation capacity be added?

    The choice is between more people or time for fixing and longer deadlines. Make it now, before approval, and not after the first quarter of misses. Capacity you only hope to get counts as no.

    In the pack

  8. Step

    Agree the extra capacity alongside the deadlines

    Put the capacity decision in front of the same person who approves the deadlines, so the two are agreed together. A deadline that depends on capacity nobody has committed to will be missed.

    In the pack

  9. Step

    Agree longer deadlines now, before approval

    Lengthen the deadlines that the backtest shows cannot be met, and stay within any outside limit you found. A realistic deadline that is met is better for audit than a strict one that is routinely missed. The pack says to make this change before approval, not afterwards.

    In the pack

  10. Decision

    Can a scan confirm each fix before its deadline?

    A finding counts as fixed on the date a later scan confirms it, not when the owner says it is patched. The pack keeps its scanning frequencies as the minimum for finding new weaknesses, and proves a fix with a targeted rescan when the deadline is close, so closure never waits for the next scheduled scan. If not known, answer no.

    In the pack

  11. Step

    Plan targeted rescans to confirm fixes

    Agree that the triage lead runs a targeted scan of the affected systems when a fix is reported and the deadline is close. The pack's default is within 2 working days, and owners report fixes at least 2 working days before the deadline so the scan lands in time. Where a system is scanned too rarely even to find new weaknesses, raise its frequency as well.

    In the pack

  12. Step

    Send the hard fixes to exceptions, not to the deadline

    Deadlines do not reflect effort: a one-line setting and a platform upgrade get the same one. If the business pushes for long deadlines because of a few hard cases, agree instead that those cases go through a time-limited exception with a risk owner and compensating controls. The deadlines then stay as they are for everything else.

    In the pack

    See also

  13. Decision

    Do IT and the asset owners accept the deadlines?

    Walk the people who will fix things through the backtest and the exception route. The pack's first-month milestone is that IT and security both accept the deadlines. Silence is not acceptance: if you have not heard a clear yes, treat it as no.

    In the pack

  14. Step

    Put the choice to the approver with the backtest

    The approver of the standard approves its deadlines. Give them the choice in plain terms: these deadlines with this capacity, or longer deadlines with the capacity we have. Include the backtest figures. The pack does not describe a separate dispute route beyond this.

    In the pack

  15. Step

    Approve the deadlines in the standard

    The deadlines take effect when the approver signs the standard. Agree the deadline adherence target with the approver at the same time; the pack suggests 90% as a starting point. Where a service provider fixes some of your systems, copy the same deadlines into its agreement so its priorities match yours.

    In the pack

  16. Decision

    Each quarter, is a priority consistently below target?

    Deadline adherence by priority shows whether the agreed deadlines are being kept. A priority consistently below target suggests its deadline or the capacity behind it is wrong, and it is a signal to investigate. Recalibrate with the same backtest rather than quietly tolerating misses.

    In the pack

    See also

  17. Outcome

    Keep the deadlines and review them yearly

    Deadlines that are met and tested stay as they are. Review them with the standard at least every 12 months, and sooner after a significant incident caused by an unfixed vulnerability or a major change in the systems in scope.

    In the pack

Practical checklist

  1. Draft one deadline per priority, counted in calendar days from the date the finding was first detected on the system.
  2. Check whether a regulation or contract sets a maximum, and keep the affected priorities inside it.
  3. Rate the last three months of findings with your priority model and count how many would have missed each draft deadline.
  4. Add capacity or lengthen the deadlines before approval if more than a fifth of Priority 2 and 3 findings would have been late, or if you cannot tell.
  5. Plan targeted rescans so each fix can be confirmed before its deadline.
  6. Agree that fixes which cannot be made in time go to a time-limited exception with a risk owner and compensating controls.
  7. Have the approver sign the deadlines and the adherence target in the standard.
  8. Check adherence by priority each quarter, recalibrate with the same test, and review the deadlines with the standard at least every 12 months.

Evidence to have ready

  • The backtest: findings per priority over the three months and how many would have missed each draft deadline.
  • The approved standard with its deadlines, the adherence target and the approver's sign-off.
  • The record of the capacity decision or the lengthened deadlines agreed before approval.
  • Quarterly deadline adherence by priority, and any recalibration that followed.
  • Where a service provider fixes your systems, the agreement showing the same deadlines.

Practitioner pulse

What other practitioners do

One question about your practice. Answer it to see how others answered. We don't ask who you are or where you work.

What deadline do you set to fix a Priority 1 finding: one that is being exploited and can be reached from the internet?

You can't change your answer once it's counted.

How this works

Answers are counted, not attributed: your answer adds one to the count for the option you chose, and we keep no account, IP address or organisation with it. A Cloudflare check confirms the answer comes from a person.

We discourage repeat answers from the same browser, but cannot prevent them, so treat the results as indicative. To do that, this browser remembers for 30 days that it answered this question, but not which option.

The results are the readers who chose to answer, not a survey of the profession, and the pack default is a starting point, not a norm. Results show once a question has 100 answers.

All pulse results

Assumptions

Not covered here