ISO 27001 Vulnerability Scanning Requirements: What Auditors Expect

Why vulnerability scanning matters for ISO 27001

ISO 27001 is the international standard for information security management systems (ISMS). If your organisation is pursuing certification -- or maintaining it -- vulnerability scanning is not optional. Multiple controls in Annex A explicitly require you to identify, assess, and remediate technical vulnerabilities.

Auditors do not just want to know that you scan. They want to see evidence that you scan regularly, that you act on findings, and that you have a documented process for doing so.

Which ISO 27001 controls require vulnerability scanning?

The 2022 revision of ISO 27001 reorganised Annex A into four themes. The controls most relevant to vulnerability scanning are:

A.8.8 -- Management of technical vulnerabilities

This is the primary control. It requires you to:

• Obtain timely information about technical vulnerabilities in your systems
• Evaluate your exposure to those vulnerabilities
• Take appropriate measures to address them

In practice, this means you need automated vulnerability scanning as part of your process. Manual review alone is not sufficient for most auditors -- the volume of vulnerabilities across modern infrastructure is too high.

A.8.9 -- Configuration management

This control requires you to establish and maintain secure configurations for your systems. Vulnerability scanning helps verify that configurations have not drifted from your security baseline -- for example, detecting that TLS has been downgraded or that a new service was deployed with default settings.

A.8.34 -- Protection of information systems during audit testing

While this control is about audit testing itself, it sets expectations that security testing (including vulnerability scanning) is conducted safely and with proper authorisation.

A.5.7 -- Threat intelligence

This control requires you to collect and analyse threat intelligence. Vulnerability scanning feeds directly into this by identifying which known threats are relevant to your infrastructure.

What evidence auditors expect to see

An auditor will typically ask for the following during a certification or surveillance audit:

1. Documented vulnerability management policy

A written policy that covers:

• Scope -- which systems are scanned
• Frequency -- how often scans are performed
• Roles and responsibilities -- who runs scans, who triages findings, who approves remediation
• Severity classification -- how you prioritise findings
• Remediation timelines -- expected fix times by severity (e.g., critical within 48 hours, high within 7 days)
• Exception process -- how you handle accepted risks

2. Scan reports with timestamps

Auditors want to see actual scan output showing:

• Date and time of each scan
• Systems in scope
• Findings with severity ratings
• Comparison with previous scans (are findings being fixed, or are they recurring?)

3. Remediation evidence

For each finding, auditors want to trace the lifecycle:

• When was the vulnerability discovered?
• When was it assigned for remediation?
• When was it fixed?
• Was the fix verified by a follow-up scan?

A ticket trail (Jira, ServiceNow, etc.) linking scan findings to remediation tasks is ideal.

4. Management review records

Evidence that scan results are reported to management and reviewed at regular intervals. This is often part of the ISMS management review meeting.

5. Risk treatment records

For vulnerabilities that are not fixed (accepted risk), auditors expect a formal risk acceptance with:

• Justification for why the risk is accepted
• Compensating controls in place
• Review date for re-evaluation

How often you need to scan

ISO 27001 does not prescribe an exact frequency, but auditors have strong expectations:

Scan type	Minimum frequency	Best practice
External vulnerability scan	Monthly	Weekly or continuous
Internal vulnerability scan	Monthly	Weekly
After significant changes	Immediately	Immediately
After a security incident	Immediately	Immediately

"Significant changes" includes deploying new systems, changing network architecture, applying major updates, or adding new internet-facing services.

For NIS2 compliance, the expectations are similar -- continuous monitoring is becoming the standard.

What a good vulnerability management process looks like

Discovery

Maintain an up-to-date inventory of all assets (servers, domains, cloud resources, applications). You cannot scan what you do not know about.

Scanning

Run automated scans on a regular schedule. Include both external (internet-facing) and internal scans. Use multiple scan types:

• Network vulnerability scanning (Nessus, OpenVAS, Qualys)
• Web application scanning (OWASP ZAP, Burp Suite)
• Attack surface scanning (SurfaceScan)
• Configuration auditing

Triage

Not every finding is equally urgent. Classify findings by:

• Severity (critical, high, medium, low)
• Exploitability (is there a known exploit in the wild?)
• Exposure (is this internet-facing or internal only?)
• Business impact (what data or system is at risk?)

Remediation

Assign findings to the responsible team with clear deadlines:

• Critical -- 48 hours
• High -- 7 days
• Medium -- 30 days
• Low -- 90 days or next maintenance window

Verification

Re-scan after remediation to confirm the fix is effective. This closes the loop and provides evidence for auditors.

Reporting

Produce regular reports (monthly at minimum) showing:

• Total findings by severity
• New findings since last report
• Findings remediated since last report
• Average time to remediate by severity
• Trend over time (is your security posture improving?)

Common audit findings related to scanning

These are the issues auditors flag most often:

1. No automated scanning in place -- relying entirely on manual reviews or penetration tests once a year
2. Incomplete scope -- scanning only the main website but not subdomains, cloud infrastructure, or APIs
3. No evidence of remediation -- scans show the same findings month after month with no action taken
4. No documented process -- scans are run ad hoc without a formal policy or schedule
5. No management visibility -- scan results are not reported to management or reviewed in governance meetings
6. Stale asset inventory -- the scan scope does not match the actual infrastructure
7. Missing risk acceptance -- known vulnerabilities are not fixed but have no formal risk acceptance on file

How SurfaceScan helps

SurfaceScan is designed to satisfy ISO 27001 vulnerability scanning requirements out of the box. It continuously discovers your external attack surface -- including subdomains, IP ranges, and cloud assets -- and scans for vulnerabilities on a configurable schedule. Each finding includes a severity rating, description, and remediation guidance. Historical scan data is retained so you can demonstrate improvement over time. The dashboard provides the management-level reporting auditors expect, and findings can be exported for integration with your ticketing system. Whether you need to show evidence for A.8.8 compliance or demonstrate that expired certificates are caught before they cause outages, SurfaceScan provides the audit trail.