Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

When do we…

When is a finding closed: when the patch is applied, or when a rescan confirms it?

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

Add to board memo

The short answer

Recommendation
Close a finding only when a later scan of the same system no longer reports it, or other objective evidence such as a configuration export shows the fixed state. Applying the patch moves it to awaiting verification, and it counts as fixed on the date of the confirming evidence.
Reasoning
An installed fix is not the same as a weakness that is gone: an update can fail, or wait for a reboot that has not happened. A ticket marked done or an email saying patched is not objective evidence. A scan that failed to log in looks clean, so it cannot show the fix worked. Because the finding counts as fixed on the confirming date, owners report fixes early enough for that scan to land before the deadline.
Considerations
  • The 2-working-day targets and the 90-day exception limit are the defaults in the CISO Times vulnerability pack. Your own procedure may set different ones. The closure rule itself is what auditors test.
  • The person who made the fix should not be the only one who confirms it. A service provider's own closed status counts only as its report that the fix was made.
  • Retired systems, false positives and late fixes need their own evidence: a retirement record and no response to scans; written evidence approved by the standard owner; or an exception, which keeps the finding open.

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
StartThe owner says the finding has been dealt withStepOwner marks it fixed, awaiting verificationDecisionWhat does the owner say happened?DecisionHas a later scan of the system completed properly?DecisionIs there a configuration export or version report?StepWait for the next scan, or run a targeted oneDecisionIs the finding gone from that scan?OutcomeReopen it with the original deadlineDecisionIs the removal recorded, and does it no longer answer scans?DecisionHas the standard owner approved written evidence?OutcomeKeep it open until the evidence existsOutcomeNot closed: it stays open under an exceptionOutcomeClosed on the date of the confirming evidence

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. 13 steps.

  1. Start

    The owner says the finding has been dealt with

    A fix that was installed is not the same as a weakness that is gone. An update can fail, or wait for a reboot that has not happened. Closure needs evidence that the finding is no longer present on that system.

    In the pack

  2. Step

    Owner marks it fixed, awaiting verification

    The owner states what was done: update installed, setting changed, or system removed. They report it early enough for a confirming scan before the deadline; the pack's default is at least 2 working days before. A service provider's own 'closed' status counts only as this report.

    In the pack

  3. Decision

    What does the owner say happened?

    Each situation has its own evidence. The person who made the fix should not be the only person who confirms it; in the pack the triage lead verifies.

    In the pack

  4. Decision

    Has a later scan of the system completed properly?

    Check the next scheduled scan of the same system. Where the scan should log in, make sure it did: a failed login produces a scan that looks clean, so it cannot show the fix worked. If you cannot tell whether the scan completed and logged in, treat it as no.

    In the pack

  5. Decision

    Is there a configuration export or version report?

    Where a scan cannot reach the system, other objective evidence can close the finding: a configuration export or a version report showing the fixed state. A ticket marked done or an email saying 'patched' is not objective evidence.

    In the pack

  6. Step

    Wait for the next scan, or run a targeted one

    If the deadline is close, run a targeted scan of the affected systems; the pack's default is within 2 working days. Otherwise the next scheduled scan will do. The finding stays open meanwhile.

    In the pack

  7. Decision

    Is the finding gone from that scan?

    Compare the same weakness on the same system. If the scan still reports it, the fix did not work or did not reach every affected component.

    In the pack

  8. Outcome

    Reopen it with the original deadline

    Tell the owner the fix did not take. The deadline stays where it was, counted from first detection. If it can no longer be met, the owner requests an exception before it passes.

    In the pack

    See also

  9. Decision

    Is the removal recorded, and does it no longer answer scans?

    A retired system closes its findings when the asset inventory and the retirement or change record are updated, and the system no longer answers scans. A system that simply did not appear in one scan may be switched off, moved or unreachable. If either piece is missing or unclear, treat it as no.

    In the pack

  10. Decision

    Has the standard owner approved written evidence?

    A false positive needs written reasoning with supporting evidence, such as the vendor's statement that the fix was included in an update the scanner does not recognise. Only the standard owner may approve it. The owner's opinion that the finding does not apply is not enough.

    In the pack

  11. Outcome

    Keep it open until the evidence exists

    Do not close the finding. Its deadline keeps running from first detection. Collect the missing evidence, and if that cannot happen before the deadline, the owner requests an exception in time.

    In the pack

  12. Outcome

    Not closed: it stays open under an exception

    An exception does not close a finding. It stays open with a risk owner, compensating controls and an expiry, in the pack's default no later than 90 days after approval, or sooner where your exception standard sets a shorter maximum for its risk. When the exception expires and the finding is still there, it counts as overdue again.

    In the pack

    See also

  13. Outcome

    Closed on the date of the confirming evidence

    Close it with the date and reference of the confirming scan or evidence. The finding counts as fixed on that date, so a patch installed on time but confirmed after the deadline counts as late. If the same weakness returns after closure, treat it as a new finding with a note that it recurred.

    In the pack

    See also

Practical checklist

  1. Have the owner mark the finding fixed, awaiting verification, state what was done and report it at least 2 working days before the deadline.
  2. Check that a later scan of the same system completed and, where it should log in, did.
  3. Run a targeted scan within 2 working days if the deadline is close.
  4. Close the finding with the date and reference of the confirming scan or evidence.
  5. Reopen it with its original deadline if the scan still reports it, and tell the owner.
  6. Request an exception before the deadline if the evidence cannot exist in time.
  7. Treat a weakness that returns after closure as a new finding, with a note that it recurred.

Evidence to have ready

  • For each closed finding, the confirming scan reference or configuration export, and the closure date.
  • For retired systems, the updated inventory record and the retirement or change record.
  • For false positives, the written reasoning, the supporting evidence and the standard owner's approval.
  • For findings under exception, the approved exception with its risk owner, compensating controls and expiry.
  • Reopened tickets showing the original deadline was kept.

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.

When does a vulnerability finding count as closed in your process?

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

  • You track findings with a detection date and a deadline, and you can run a targeted scan of a named system when needed.
  • The working-day targets shown are the defaults in the CISO Times vulnerability pack. Your own procedure may set different ones. The closure rule itself is what auditors test.

Not covered here