Vulnerability Scanner Configuration Review Checklist
Verifies that the scanning tooling is configured to produce trustworthy results before any metric derived from it is reported upward.
Available soon
- Format
- Excel
- Size
- 60 KB
- Length
- 9 sheets
- Version
- 1.0
- Updated
What's inside
- Instructions
- Checklist
- Results & Sign-off
- Lists
- Definitions
- Framework References
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | Fill in the review details at the top of the Results & Sign-off sheet: which scanners and engines are covered, who is reviewing, and the date. The review is required at least every 6 months. |
| 2 | Read the four EXAMPLE rows at the top of the Checklist sheet to see how a completed row looks, then delete them — they are counted in the summary until you do. |
| 3 | Work through the Checklist sheet area by area. For each check, look at the evidence named in the pass criterion. Record where the evidence is kept (a file name, ticket or report), who checked it, and the date. |
| 4 | Set the Result to Pass only when the pass criterion is fully met. Otherwise set Fail and write the action and a due date. Use N/A only when the check truly does not apply, and write why. |
| 5 | Fill the [[double-bracket]] values in the pass criteria with your own sample sizes and periods, or accept the suggested value. Change them before the first review, not during it. |
| 6 | Watch the Record status column. It shows 'Reason missing', 'Action missing' or 'Evidence, owner or date missing' until each row is complete. |
| 7 | Checks marked Yes in 'Affects reported figures' are the ones that make coverage, deadline or overdue figures wrong when they fail. The summary will not say 'Ready to report upward' while any of them has failed or is unchecked. |
| 8 | Open the Results & Sign-off sheet. Read the result for each area and the overall answer to 'Ready to report upward?'. The standard owner records the decision and signs off. |
| 9 | If the answer is not 'Ready', say so in the next report built from the Vulnerability Management Metrics Workbook, and name the failed checks as a limitation of the figures. |
| 10 | To add your own checks, type them into the empty rows at the bottom of the Checklist table and choose an Area from the list; the summary counts them automatically. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
Tailoring — small organisation: if a service provider or a single person runs everything, keep all nine areas but reduce the sample sizes (for example 3 instead of 10). Area 9 matters most when one account can change the scanner and hide its own results.
Tailoring — regulated financial entity: keep evidence for every Pass, not only for failures, because supervisors ask how the figures in management reports were assured. Add checks for any scanning frequency or scope set in your ICT risk management framework, and repeat the review before each report to the management body.
Tailoring — IT run by a service provider: ask the provider to complete the checklist and supply the evidence, and have the standard owner review it and sign off. Check AC-03 first — without read access to raw results you cannot verify anything else.
A Fail is a finding about the scanner, not about the people running it. Fix it, record it and re-run the check; the history of reviews is the evidence that the control works.
Checklist
One row per check. Yellow cells are yours to complete. Rows marked EXAMPLE show a completed row — delete them before the review is signed off.
| Check ID | Area | Check | Pass criterion | Standard reference | Affects reported figures | Evidence reference | Checked by | Date checked | Result | Reason (N/A) or action and owner (Fail) | Action due | Record status |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | 3. Definitions and scanner health | Vulnerability definitions update at least daily | At the time of review, every scanning engine and agent policy shows a definitions update within the last 24 hours, and the update history shows no gap longer than 24 hours in the last 30 days. | VM-07 | Yes | Screenshot of update history, 30 days, saved to [[evidence folder]]/2026-09 | IT Operations Manager | 14 Sep 2026 | Pass | Complete | ||
| EXAMPLE | 2. Authenticated scanning and credentials | Authenticated logins succeed | At least 95% of authenticated scans in the last period logged in successfully, taken from the scanner's own login report rather than estimated. | VM-05 | Yes | Login success report for August: 88% (132 of 150) | IT Operations Manager | 14 Sep 2026 | Fail | Service account locked on 18 servers after password change. Reset and re-test. | 21 Sep 2026 | Complete |
| EXAMPLE | 5. External scanning | Payment card scans are in place, where they apply | Where payment card data is handled: external scans at least every three months by an approved scanning vendor, with passing results retained. Otherwise mark N/A with the reason. | §4.3 guidance | No | Head of Information Security | 15 Sep 2026 | N/A | No payment card data is stored, processed or transmitted; card payments are handled entirely by an outsourced payment page. | Complete | ||
| EXAMPLE | 7. Exclusions and suppressions | Every exclusion has a reason, an owner and a review date | Every excluded system, address range or check is listed with the reason, the person who approved it and a review date. | VM-02 | Yes | Exclusions list exported 2026-09-15; 6 entries, all with reason, approver and review date | Head of Information Security | 15 Sep 2026 | Pass | Complete | ||
| SC-01 | 1. Scope and asset coverage | Scan targets match the asset register | Every in-scope system in the Scan Coverage & Asset Scope Register is in at least one scan target group or has a working agent. Reconciled within the last [[30]] days; differences listed with a reason. | VM-01, VM-02 | Yes | Not yet checked | ||||||
| SC-02 | 1. Scope and asset coverage | Coverage in the last complete period meets the target | At least 95% of in-scope systems were successfully scanned in the last complete period. Every system not scanned is listed with a reason and a date by which it will be. | VM-02 | Yes | Not yet checked | ||||||
| SC-03 | 1. Scope and asset coverage | New systems enter scanning promptly | For a sample of [[5]] systems that went live since the last review, each was added to scanning before, or within 5 working days of, going into production. | VM-03 | No | Not yet checked | ||||||
| SC-04 | 1. Scope and asset coverage | Every network range and cloud account is covered | Every internal network range and every cloud account or subscription the organisation administers is either a scan target or a recorded exclusion with a reason. | VM-01 | Yes | Not yet checked | ||||||
| SC-05 | 1. Scope and asset coverage | Retired systems have been removed | Systems retired since the last review are removed from scan targets and the register, and their open findings are closed with the retirement recorded as evidence. | VM-01 | No | Not yet checked | ||||||
| SC-06 | 1. Scope and asset coverage | Criticality and internet-facing tags are correct in the scanner | For a sample of [[10]] systems, the criticality (Critical, High, Standard) and internet-facing flag held in the scanner or tracker match the register. Priorities depend on both. | VM-01; §5.1 | Yes | Not yet checked | ||||||
| AU-01 | 2. Authenticated scanning and credentials | Servers and end-user devices are scanned with credentials or an agent | Authenticated scanning or an installed agent is used wherever the technology allows. Systems scanned without credentials are listed with the technical reason. | VM-04 | Yes | Not yet checked | ||||||
| AU-02 | 2. Authenticated scanning and credentials | Authenticated logins succeed | At least 95% of authenticated scans in the last period logged in successfully, taken from the scanner's own login report rather than estimated. | VM-05 | Yes | Not yet checked | ||||||
| AU-03 | 2. Authenticated scanning and credentials | Credential failures are fixed quickly | The last [[5]] credential failures were each investigated and corrected within 5 working days. | VM-05 | No | Not yet checked | ||||||
| AU-04 | 2. Authenticated scanning and credentials | Scanning accounts have only the rights they need | Scanning uses dedicated accounts, not personal administrator accounts. Each has only the rights needed to read software and configuration, and interactive login is disabled where the platform allows. | A.8.9 | No | Not yet checked | ||||||
| AU-05 | 2. Authenticated scanning and credentials | Scanning credentials are stored and rotated safely | Credentials are held only in the scanner's encrypted store or a password vault — not in scripts, spreadsheets or email — and are changed [[every 12 months]] and when someone who knew them leaves. | A.8.9 | No | Not yet checked | ||||||
| AU-06 | 2. Authenticated scanning and credentials | Agents are reporting in | Where agents are used, at least [[95%]] of devices have reported within the last [[7]] days. Devices whose agents have gone silent are listed with an owner. | VM-02, VM-04 | Yes | Not yet checked | ||||||
| DU-01 | 3. Definitions and scanner health | Vulnerability definitions update at least daily | At the time of review, every scanning engine and agent policy shows a definitions update within the last 24 hours, and the update history shows no gap longer than 24 hours in the last 30 days. | VM-07 | Yes | Not yet checked | ||||||
| DU-02 | 3. Definitions and scanner health | Scanner software is supported and current | Every scanning engine runs a version its supplier still supports, and no more than [[one]] release behind the current one. | VM-07 | No | Not yet checked | ||||||
| DU-03 | 3. Definitions and scanner health | Every scanning engine is online | All scanning engines, sensors and collectors are online and have completed a scan in the last [[7]] days. None has failed silently. | VM-02 | Yes | Not yet checked | ||||||
| DU-04 | 3. Definitions and scanner health | Update and engine failures raise an alert | A failed definitions update or an offline engine sends an alert to a named person, and the last such alert (or a test) is recorded. | VM-07 | No | Not yet checked | ||||||
| SF-01 | 4. Scan schedules | Internet-facing systems are scanned on schedule | A schedule exists at the minimum frequency (weekly) and the last [[4]] runs completed. | §4.3 | Yes | Not yet checked | ||||||
| SF-02 | 4. Scan schedules | Critical and High systems are scanned on schedule | Internal scans of Critical and High criticality systems run at least weekly, and the last [[4]] runs completed. | §4.3 | Yes | Not yet checked | ||||||
| SF-03 | 4. Scan schedules | Standard servers and network devices are scanned on schedule | These systems are scanned at least monthly, and the last [[3]] runs completed. | §4.3 | Yes | Not yet checked | ||||||
| SF-04 | 4. Scan schedules | End-user devices are scanned on schedule | Laptops and desktops are scanned continuous (agent) or monthly, with results from the last period for at least [[95%]] of devices. | §4.3 | Yes | Not yet checked | ||||||
| SF-05 | 4. Scan schedules | Cloud infrastructure is assessed on schedule | Cloud infrastructure and configuration are assessed continuous (posture tool) or weekly. | §4.3 | Yes | Not yet checked | ||||||
| SF-06 | 4. Scan schedules | Web applications are scanned on schedule | Web applications and websites are scanned quarterly, and before major releases; the last major release had a scan before go-live. | §4.3 | No | Not yet checked | ||||||
| SF-07 | 4. Scan schedules | Scans are not cut short | No scheduled scan in the last period was stopped by a time window or time-out without being re-run. Partial scans are visible in the scan history. | VM-02 | Yes | Not yet checked | ||||||
| SF-08 | 4. Scan schedules | An urgent scan can be run on demand | When a widely exploited vulnerability is announced, internet-facing systems can be scanned for it within [[24 hours]]. The last occasion (or a test) is recorded. | §4.3 | No | Not yet checked | ||||||
| EX-01 | 5. External scanning | Internet-facing systems are scanned from outside | External scans run from outside the organisation's network against every internet-facing address and host name in the register. | VM-06 | Yes | Not yet checked | ||||||
| EX-02 | 5. External scanning | The external target list is complete | The external target list was reconciled within the last [[90]] days against public name (DNS) records, public address allocations and cloud services with public addresses. | VM-06 | Yes | Not yet checked | ||||||
| EX-03 | 5. External scanning | Payment card scans are in place, where they apply | Where payment card data is handled: external scans at least every three months by an approved scanning vendor, with passing results retained. Otherwise mark N/A with the reason. | §4.3 guidance | No | Not yet checked | ||||||
| SP-01 | 6. Scan settings | Scans look at every relevant port and service | Internet-facing systems are scanned across all network ports. Internal scans use the port range set in the scan policy; any 'common ports only' setting is a recorded decision. | VM-02 | Yes | Not yet checked | ||||||
| SP-02 | 6. Scan settings | Disruptive checks are limited by decision, not by default | Checks that could disrupt fragile systems (such as industrial equipment or old printers) are switched off only for those systems, by a recorded decision — not across the whole estate. | A.8.9 | No | Not yet checked | ||||||
| SP-03 | 6. Scan settings | Severity ratings are unmodified | The scanner's severity ratings (Critical, High, Medium, Low) come from the published rating method. Any local change to a rating is recorded and approved. | §5.1 | Yes | Not yet checked | ||||||
| SP-04 | 6. Scan settings | Exploited vulnerabilities are flagged | The scanner, or the triage process, flags findings listed in a known-exploited vulnerabilities catalogue, so that Priority 1 and 2 can be set. | §5.1 | Yes | Not yet checked | ||||||
| SP-05 | 6. Scan settings | Changes to the scanner are controlled | Changes to scan targets, policies, schedules and exclusions since the last review appear in change records with who approved them. | A.8.9 | No | Not yet checked | ||||||
| XS-01 | 7. Exclusions and suppressions | Every exclusion has a reason, an owner and a review date | Every excluded system, address range or check is listed with the reason, the person who approved it and a review date. | VM-02 | Yes | Not yet checked | ||||||
| XS-02 | 7. Exclusions and suppressions | Exclusions were reviewed at this review | Each exclusion was reviewed at this review. Those no longer justified were removed and the systems brought back into scanning. | VM-02 | Yes | Not yet checked | ||||||
| XS-03 | 7. Exclusions and suppressions | False-positive suppressions have evidence and approval | Every finding suppressed as a false positive has recorded evidence and the standard owner's approval. | VM-14 | Yes | Not yet checked | ||||||
| XS-04 | 7. Exclusions and suppressions | Risk-accepted suppressions match approved exceptions | Every finding suppressed as an accepted risk matches an approved exception with an expiry no more than 90 days after approval. No suppression outlives its exception. | VM-17 | Yes | Not yet checked | ||||||
| RI-01 | 8. Integrity of results | Each finding is counted once | The same vulnerability on the same system is counted once, even when it is found by more than one scanner, agent or scan. | VM-11 | Yes | Not yet checked | ||||||
| RI-02 | 8. Integrity of results | Findings close only on evidence | In a sample of [[10]] closed findings, each was closed because a later scan no longer found it, or with other objective evidence attached — not because a ticket was marked done. | VM-13 | Yes | Not yet checked | ||||||
| RI-03 | 8. Integrity of results | The first detection date is kept | Rescans and re-imports keep each finding's original first-detection date, so deadlines are counted from first detection. | VM-08 | Yes | Not yet checked | ||||||
| RI-04 | 8. Integrity of results | The tracker agrees with the scanner | The number of open Priority 1–3 findings in the scanner matches the Vulnerability Remediation Tracker to within [[2%]], and the difference is explained. | VM-11 | Yes | Not yet checked | ||||||
| RI-05 | 8. Integrity of results | Scan results are kept long enough | Scan results and schedules are retained for [[12 months]], or the period set in the Standard's records table. | §9 | No | Not yet checked | ||||||
| RI-06 | 8. Integrity of results | Reports use the agreed definitions | Figures reported upward are calculated with the definitions in the Vulnerability Management Metrics Workbook. | VM-21 | No | Not yet checked | ||||||
| AC-01 | 9. Access to the scanner | Administrator access is limited and reviewed | Only named people can change the scanner. The list was reviewed at this review and leavers have been removed. | A.8.9 | No | Not yet checked | ||||||
| AC-02 | 9. Access to the scanner | Sign-in to the scanner uses multi-factor authentication | Every administrator sign-in to the scanner's management console requires multi-factor authentication. | A.8.9 | No | Not yet checked | ||||||
| AC-03 | 9. Access to the scanner | The organisation can see raw results | Where a service provider runs the scanner, the organisation has read access to raw results and to the configuration, not only to summary reports. | §13 tailoring | No | Not yet checked | ||||||
| AC-04 | 9. Access to the scanner | Changes on the scanner are logged | The scanner's own activity log is switched on and retained, so changes to targets, exclusions and suppressions can be traced to a person. | A.8.9 | No | Not yet checked |
Results & Sign-off
Results and sign-off
Calculated from the Checklist sheet. Only the yellow cells are yours to complete. The answer to 'Ready to report upward?' is stated in words: there is no score, because one failed check that affects reported figures matters more than any number of passes.
Review details
| Field | Value | ||||||
|---|---|---|---|---|---|---|---|
| Scanners and engines covered by this review | [[e.g. internal scanner, endpoint agents, external scanning service]] | ||||||
| Reviewer (name and role) | [[Name, role]] | ||||||
| Date of this review | 15 Sep 2026 | EXAMPLE date — replace | |||||
Date of the previous review
| Next review due (at the latest) | 15 Mar 2027 | No more than 6 months after this review (VM-07). |
Results by area
| Area | Checks | Pass | Fail | N/A | Not yet checked | Failed, affects figures | Area status |
|---|---|---|---|---|---|---|---|
| 1. Scope and asset coverage | 6 | 0 | 0 | 0 | 6 | 0 | In progress |
| 2. Authenticated scanning and credentials | 7 | 0 | 1 | 0 | 6 | 1 | Blocking failure |
| 3. Definitions and scanner health | 5 | 1 | 0 | 0 | 4 | 0 | In progress |
| 4. Scan schedules | 8 | 0 | 0 | 0 | 8 | 0 | In progress |
| 5. External scanning | 4 | 0 | 0 | 1 | 3 | 0 | In progress |
| 6. Scan settings | 5 | 0 | 0 | 0 | 5 | 0 | In progress |
| 7. Exclusions and suppressions | 5 | 1 | 0 | 0 | 4 | 0 | In progress |
| 8. Integrity of results | 6 | 0 | 0 | 0 | 6 | 0 | In progress |
| 9. Access to the scanner | 4 | 0 | 0 | 0 | 4 | 0 | In progress |
Includes the EXAMPLE rows until you delete them, and any checks you add with an Area chosen from the list.
Overall
| Measure | Count |
|---|---|
| Checks in total | 50 |
| Passed | 2 |
| Failed | 1 |
| Not applicable | 1 |
| Not yet checked | 46 |
| Failed checks that affect reported figures | 1 |
| Unchecked checks that affect reported figures | 28 |
| Rows missing a reason, action, evidence, owner or date | 0 |
| Ready to report upward? | Not ready | ||||||
|---|---|---|---|---|---|---|---|
| Why | 1 failed check(s) would make reported coverage, deadline or overdue figures wrong. Fix them first, or report the figures with this limitation stated and approved by the standard owner. | ||||||
Sign-off
| Field | Value | ||||||
|---|---|---|---|---|---|---|---|
| Reviewed by (name, role) | [[Name, role]] | ||||||
Reviewer's date
Standard owner's decision
| Standard owner (name) | [[Name]] | ||||||
Decision date
| Conditions or comments | [[e.g. report coverage with the note that 18 servers were scanned without credentials in August]] | ||||||
The decision should follow the answer above. If the owner decides to report despite a 'Not ready' answer, the conditions must say which figures are affected and how.
Lists
| Result | YesNo | Area | Decision |
|---|---|---|---|
| Pass | Yes | 1. Scope and asset coverage | Figures may be reported upward |
| Fail | No | 2. Authenticated scanning and credentials | Report with the limitations stated |
| N/A | 3. Definitions and scanner health | Do not report until fixed |
4. Scan schedules
5. External scanning
6. Scan settings
7. Exclusions and suppressions
8. Integrity of results
9. Access to the scanner
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Affects reported figures | A check marked Yes here would make scan coverage, deadline adherence or overdue figures wrong if it failed. The summary will not show 'Ready' while any of these has failed or is unchecked. |
| Agent | Software installed on a device that reports its installed software and configuration to the scanner, instead of the scanner logging in over the network. |
| Authenticated scan | A scan that logs in to the target system with valid credentials, or uses an installed agent, so it can see installed software and configuration. It finds far more missing patches than a scan that does not log in. |
| Definitions (vulnerability definitions) | The scanner supplier's list of known vulnerabilities and how to detect them, updated as new vulnerabilities are published. A scanner with old definitions reports a clean result for vulnerabilities it does not yet know. |
| Exclusion | A system, address range or check deliberately left out of scanning. Every exclusion lowers true coverage, so each needs a reason, an approver and a review date. |
| External scan | A scan run from outside the organisation's network, showing what an attacker on the internet can reach. |
| False positive | A finding reported by the scanner that is not actually present. Suppressing one needs evidence and approval (VM-14). |
| Internet-facing | Reachable from the internet, directly or through a published service, without first connecting to the organisation's private network. |
| N/A (not applicable) | The check does not apply to this organisation or this scanner — for example, payment card scans where no card data is handled. Always give the reason. |
| Scan coverage | The percentage of in-scope systems successfully scanned in the period (VM-02). |
| Scanning engine | The component that actually runs scans — a server, appliance, cloud service or sensor. Larger estates have several. |
| Suppression | A setting that hides a finding from reports, usually for a false positive or an accepted risk. A suppression that outlives its reason hides real exposure. |
| Standard reference | The requirement in the Vulnerability & Exposure Management Standard that the check tests (VM-xx), or its section number. A.8.9 marks checks that come from configuration management rather than the Standard. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 8.8 — Management of technical vulnerabilities | Areas 1 to 8 |
| ISO/IEC 27001:2022 | Annex A 8.9 — Configuration management | Areas 2, 6 and 9 |
| NIST CSF 2.0 | ID.RA-01 — “Vulnerabilities in assets are identified, validated, and recorded” | Areas 1 to 8 |
| NIST CSF 2.0 | PR.PS-01 — “Configuration management practices are established and applied” | Areas 2, 6 and 9 |
| PCI DSS v4.0.1 | Requirement 11.3 — identifying, prioritising and addressing internal and external vulnerabilities regularly | Areas 2, 4 and 5 |
| DORA — Regulation (EU) 2022/2554 | Article 9 — protection and prevention, including documented policies for patches and updates (Article 9(4)(f)) | Whole checklist |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 10 — vulnerability and patch management, including automated vulnerability scanning at least weekly for ICT assets supporting critical or important functions | Areas 1, 4 and 8 |
Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); PCI DSS v4.0.1