Set the schedule once.
We agree scope, profiles, and cadence with you, matched to the frequency in your policy. Then we run it.
ISO 27001 · ANNEX A 8.8
ISO 27001 vulnerability scanning,
with the evidence already prepared.
Annex A 8.8 asks you to find technical vulnerabilities, evaluate your exposure, and act on it. Your auditor will ask you to prove all three. Auditon runs recurring assessments of your applications and the services behind them, and keeps every scan, finding, fix, and accepted risk on record.
WHAT THE AUDITOR LOOKS FOR
A process that runs.
And proof that it works.
A single scan report shows you looked once. Certification and surveillance audits look for a control operating over time.
| THE AUDITOR ASKS | WHAT AUDITON SHOWS |
|---|---|
| “How do you obtain information about technical vulnerabilities?”A.8.8 | Recurring assessments of your applications, APIs, TLS, and exposed services on an agreed schedule, with a complete scan history. |
| “How do you know the scans actually ran?”A.8.8 · CLAUSE 9.1 | Execution coverage for every run: each tool and stage marked completed, skipped, partial, failed, or timed out, with the reason. |
| “How do you evaluate your exposure?”A.8.8 · CLAUSE 6.1.2 | Severity with CVSS 3.1 and CWE, OWASP and ISO 27001 Annex A references per finding, and an exposure trend across assessments. |
| “Show me you act on findings within your defined timelines.”A.8.8 | Time to fix and SLA adherence by severity, and the age of every open finding, from first detection to resolution. |
| “What about risks you chose not to fix?”CLAUSE 6.1.3 | Risk-accepted exceptions with a recorded reason and an owner, kept separate from open findings. |
| “Do you test security before and after changes?”A.8.29 · A.8.32 | Drift between assessments shows what each round of changes introduced and what it resolved. |
Control references show where Auditon’s output is typically used as evidence. They are mappings, not compliance attestations: your auditor decides what satisfies a control. Auditon does not replace your vulnerability management policy, your risk assessment, or an annual penetration test.
BUILT FOR SMALL SECURITY TEAMS
Certification with a security team of one.
Most companies going for ISO 27001 don’t have a vulnerability management team. They have one engineer, and an audit date.
Fix from one list.
Findings prioritised by severity and grouped by fix, with effort estimates, so your engineer knows where the next hour goes.
Hand over the evidence.
Scan history, SLA adherence, and exceptions for the audit period, in reports you can download and share.
THE RIGHT FIT
Where Auditon fits in your ISMS.
Auditon covers…
- recurring external scanning of web applications, APIs, TLS, and exposed services
- evidence that the scans ran, and what they covered
- time to fix, SLA adherence, and finding age by severity
- risk-accepted exceptions with a reason and an owner
- drift and exposure trends across assessments
You’ll still need…
- a vulnerability management policy that sets scope, cadence, and fix timelines
- your risk assessment and Statement of Applicability
- patch management for endpoints and internal systems
- an annual penetration test, if your risk assessment calls for one
PICK YOUR RHYTHM
Match the frequency in your policy.
The audit baseline.
A common minimum for ISO 27001 programmes, and what many customer questionnaires expect.
For regular releases.
Keeps time-to-fix numbers current and drift easy to explain.
For fast-moving products.
New exposure found within days, well inside most fix timelines.
For critical, public services.
Internet-facing APIs checked every day.
A LITTLE MORE CLARITY
ISO 27001 scanning,
straight answers.
Does ISO 27001 require vulnerability scanning?+
ISO 27001:2022 Annex A 8.8, Management of technical vulnerabilities, requires you to obtain information about technical vulnerabilities, evaluate your exposure, and take appropriate measures. The standard does not name a tool, but regular vulnerability scanning with tracked remediation is the most common way organisations meet and evidence this control.
How often should we scan for ISO 27001?+
The standard does not set a frequency. You define it in your own policy based on risk. Quarterly is a common baseline; teams that ship often or run internet-facing APIs usually scan monthly, weekly, or daily. What matters to the auditor is that you follow the schedule you set.
Will using Auditon make us ISO 27001 compliant?+
No tool makes you compliant on its own. Auditon provides operating evidence for vulnerability management controls: scan history, execution coverage, time to fix, SLA adherence, and exceptions. Your policies, risk assessment, and the auditor’s judgement complete the picture.
Do we still need a penetration test?+
Many organisations keep an annual penetration test for depth, including business-logic testing that automated scanning does not cover. Auditon covers the time in between, watching for new exposure and tracking remediation on a regular schedule.
LET’S TAKE A CLOSER LOOK
Walk into your next audit
with the evidence ready.
Tell us your scope and your audit date. We’ll take it from there.
Get audit-ready ↗Back to the Auditon homepage ↗ISO/IEC 27001 is a standard published by ISO and IEC. Auditon is not a certification body and does not certify compliance. Control references are based on ISO/IEC 27001:2022 and are provided as guidance; confirm how they apply to your ISMS with your auditor.