How do we…
How do we defend our prioritisation method to an auditor?
Add to board memoOpen the memo
The short answer
- Recommendation
- Show that the method is written and approved, gives the same answer whoever applies it, and has deadlines that are met. Then invite the auditor to re-derive a random sample of priorities from their recorded inputs, after running that test yourself every quarter.
- Reasoning
- Under ISO/IEC 27001 an auditor usually tests two things: that your criteria for judging risk give consistent, comparable results when applied again, and that you act in proportion to your exposure to technical vulnerabilities. Re-deriving recorded priorities tests the first directly, and adherence figures show the deadlines are met, not just written. Stating the method's known limits, and how each is managed, reassures an auditor more than claiming none.
- Considerations
- The sample of 10, the 90% adherence signal and the quarterly cycle are the defaults in the CISO Times vulnerability pack. Your own standard may set different ones, and the pack lets a small organisation run the calibration checks every six months.
- A difference is acceptable only when the record shows a raise with its reason, or a lowering with the standard owner's decision, the reason and a control that changed an input. A lowering made to avoid a missed deadline is never valid.
- If the method and the standard disagree on a deadline, the standard wins and the method is corrected.
- The method does not on its own meet payment card requirements, whose month runs from the patch's release. For systems in scope, also record the release date and work to whichever date comes first.
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
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. 15 steps.
Start
An auditor will test how we prioritise findings
Under ISO/IEC 27001 an auditor usually tests two things. First, that you have defined criteria for judging risk that give consistent, comparable results when applied again (clause 6.1.2). Second, that you evaluate your exposure to technical vulnerabilities and act in proportion to it (Annex A 8.8). A defence has to show both.
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelHow to defend the method to an auditor
Decision
Is the method written down and approved?
The auditor needs a document to test against: the approved standard with its deadlines, and the rating method that assigns each finding a priority. Ranking by the scanner's severity alone, or by judgement in a meeting, cannot be re-derived. If approval records cannot be found, answer no.
- Yes: Gather the evidence the auditor will ask for
- No, or not known: Write and approve the method before you defend it
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelEvidence to have ready
- P01-A04 Vulnerability Risk Rating & SLA ModelPurpose
Outcome
Write and approve the method before you defend it
Adopt a written method that asks whether the weakness is being exploited, whether an attacker can reach the system, how severe it is, and how much the system matters. Before approval, rate your last three months of findings with it and check how many would have missed their deadline. Then apply it for a period, so there are records to test.
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelBefore approval
- P01-A04 Vulnerability Risk Rating & SLA ModelInputs
Step
Gather the evidence the auditor will ask for
Five things: the approved standard and method, with matching deadlines; the findings record showing each finding's four inputs, priority, deadline, first-detection date and closure evidence; every raise and lowering, with who decided and why; the calibration record; and reports of deadline adherence by priority. If the method and the standard disagree on a deadline, the standard wins and the method is corrected.
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelEvidence to have ready
- P01-A04 Vulnerability Risk Rating & SLA ModelRules for applying the model (rule RM-01)
- P01-A04 Vulnerability Risk Rating & SLA ModelPurpose
Step
Re-derive a random sample of priorities yourself
Pick findings at random from your records; the pack's default is 10. For each, take the recorded inputs and read the priority again from the method's table. Do this every quarter, so the first run is not in front of the auditor. It is the same test you will invite the auditor to run.
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelThe re-derivation test
Decision
Does every re-derived priority match the recorded one?
A match shows the method is applied the same way each time. A finding whose inputs were not recorded cannot be re-derived, so count it as a mismatch.
- Yes: Are the deadlines met, and is adherence reported?
- No: Is each difference a recorded raise or lowering?
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelThe re-derivation test
Decision
Is each difference a recorded raise or lowering?
A difference is acceptable when the record shows why. A raise needs the reason. A lowering needs the standard owner's decision, the reason, and a control that changed one of the inputs. A lowering made to avoid a missed deadline is not a valid explanation. If the record is silent, answer no.
- Yes: Are the deadlines met, and is adherence reported?
- No, or not known: Find why it differs, correct it, and test again
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelRules for applying the model (rules RM-06, RM-07)
Step
Find why it differs, correct it, and test again
Look for an input recorded wrongly, a tool or spreadsheet that applies the table incorrectly, a definition that two people read differently, or a change nobody recorded. Correct the record and the cause. Check any tool against the method's calibration test cases, and have two people rate the same findings to expose unclear wording.
- Then: Re-derive a random sample of priorities yourself (back to an earlier step)
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelCalibration test cases
- P01-A04 Vulnerability Risk Rating & SLA ModelBefore approval
Decision
Are the deadlines met, and is adherence reported?
Auditors ask whether the deadlines are achievable. The method's answer is that they were tested against real findings before approval and adherence is reported regularly. The pack's quarterly signal is a priority consistently below 90% adherence. If adherence is not measured, answer no.
- Yes: State the method's limits and how each is managed
- No, or not known: Show what was decided about the missed deadlines
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelQuestions auditors commonly ask
- P01-A04 Vulnerability Risk Rating & SLA ModelEvery quarter
- P01-A08 Vulnerability Management Metrics WorkbookMetric Definitions
Step
Show what was decided about the missed deadlines
Show the adherence figures, the overdue escalations and what was decided about them: more capacity, longer deadlines approved in the standard, or exceptions. A priority is never lowered to rescue a deadline, so a lowering recorded after a missed deadline will stand out in the re-derivation test.
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelEvery quarter
- P01-A02 Vulnerability & Exposure Management Standard5.2 Remediation deadlines (rule VM-10)
Step
State the method's limits and how each is managed
Exploitation sources lag. CVSS scores ignore context. Two exposure levels simplify reality. Everything depends on the asset inventory. Findings are rated one at a time, so a chain of Medium flaws can be missed. Deadlines do not reflect effort. For each, say how you manage it, for example unknown exposure and criticality default to the more urgent value. An auditor is more reassured by stated limits than by none.
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelLimitations
Step
Prepare answers to the questions auditors usually ask
Why not fix by CVSS score? How do you know a weakness is exploited? Who can change a priority, and how is that controlled? Are the deadlines achievable? Does this meet payment card requirements? Each answer should point to a rule in your method and a record that shows it applied.
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelQuestions auditors commonly ask
Decision
Has a calibration review been recorded this quarter?
The quarterly review looks at the spread of findings across priorities, deadline adherence, how often priorities were raised or lowered, findings later exploited while rated low, inputs that were defaulted because they were unknown, and the re-derivation test. The pack lets a small organisation run these checks every six months instead. If there is no record within your cycle, answer no.
- Yes: Invite the auditor to re-derive priorities themselves
- No, or not known: Run and record a calibration review before the audit
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelEvery quarter
- P01-A04 Vulnerability Risk Rating & SLA ModelCalibration record
- P01-A04 Vulnerability Risk Rating & SLA ModelAdapting this template
Outcome
Run and record a calibration review before the audit
Run the quarterly checks now and record the date, who reviewed, the findings sampled, the mismatches found and any change proposed. A recent record, even the first one, answers the auditor's question of whether the method is monitored.
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelCalibration record
- P01-A04 Vulnerability Risk Rating & SLA ModelEvery quarter
Outcome
Invite the auditor to re-derive priorities themselves
You have a written method, evidence it is applied consistently, figures showing the deadlines are met or managed, and a record that it is reviewed. Offer the auditor the re-derivation test on a sample they choose. It is the strongest defence the method has.
In the pack
- P01-A04 Vulnerability Risk Rating & SLA ModelThe re-derivation test
- P01-A04 Vulnerability Risk Rating & SLA ModelHow to defend the method to an auditor
Practical checklist
- Check that the standard and rating method are written, approved and carry matching deadlines; if not, adopt one and apply it before the audit.
- Gather the findings record, every raise and lowering, the calibration record and the adherence reports.
- Re-derive a random sample of priorities from their recorded inputs, counting a finding with missing inputs as a mismatch.
- Trace each unexplained mismatch to its cause, correct the record and the cause, and test again.
- Show what was decided about missed deadlines: more capacity, longer deadlines approved in the standard, or exceptions.
- Write down the method's known limits and how each is managed.
- Prepare answers to the questions auditors usually ask, each pointing to a rule in the method and a record.
- Record a calibration review within your cycle, then offer the auditor the re-derivation test on a sample they choose.
Evidence to have ready
- The approved standard and rating method, with matching deadlines and approval records.
- The findings record showing each finding's four inputs, priority, deadline, first-detection date and closure evidence.
- The record of every raise and lowering, with who decided and why.
- The calibration record: date, reviewer, findings sampled, mismatches found and changes proposed.
- Deadline adherence reports by priority, and the decisions taken on missed deadlines.
Assumptions
- You already prioritise findings with a written method, or are about to adopt one. “How do we decide what to fix first when the scanner shows thousands of findings?” walks through the method in the CISO Times vulnerability pack.
- The sample sizes and thresholds shown are the pack's defaults. Your own standard may set different ones.
Not covered here
- How to assign a priority to a finding in the first place. That is “How do we decide what to fix first when the scanner shows thousands of findings?”.
- How to set deadlines the business will agree to. That is “How do we set remediation deadlines the business will actually agree to?”.
- How to prove a finding is closed. That is “When is a finding closed: when the patch is applied, or when a rescan confirms it?”.
Related questions
- How do we decide what to fix first when the scanner shows thousands of findings?
- How do we set remediation deadlines the business will actually agree to?
- When is a finding closed: when the patch is applied, or when a rescan confirms it?
- If remediation deadlines are routinely missed, do we change the deadline, the capacity or the scope?
- If the auditor raises a major nonconformity, then what?