ISO 27001 Annex A 8.8: vulnerability management beyond the pen test

The due-diligence questionnaire asks for your scanning cadence and remediation timescales. You have a penetration test report from last spring and a spreadsheet nobody has opened since. This guide explains what ISO 27001 Annex A 8.8 asks for beyond that annual test, and how to run the control as an automated pipeline that auditors and enterprise buyers can both inspect.

It is written for technical leaders, Heads of IT and compliance managers at UK regulated firms and B2B SaaS companies of 25 to 250 staff who need an auditable lifecycle, not a yearly scramble.

What does ISO 27001 management of technical vulnerabilities require under Annex A 8.8?

ISO 27001 A.8.8 requires a working loop: know which software and versions you run, hear promptly when flaws in them are published, judge your exposure, and then patch, mitigate or formally accept the risk on timescales matched to severity. The loop also covers your own products' libraries and a route for outsiders to report flaws.

Annex A 8.8, titled Management of technical vulnerabilities in the 2022 edition, is a preventive control. Closing a published flaw before an attacker reaches it protects confidentiality, integrity and availability together. Exploited flaws are the way in for data theft, tampering and outage alike.

That makes it the control where a gap converts most directly into an incident. After a breach, "a patch was available for months" is the sentence that turns an incident into a negligence story for regulators, insurers and customers.

The commercial checks never stop. Cyber Essentials expects critical and high-risk updates within 14 days of release, enterprise questionnaires ask about your process by name, and cyber insurance proposals probe the same ground.

Proportionality helps. A 50-person firm does not need a vulnerability operations centre: it needs one inventory, one scanner covering the whole estate, a handful of advisory feeds and a written severity ladder.

For a lean firm the trap is patching by instinct, whenever someone remembers. It works until the week it doesn't. The loop is a set of habits that tooling can run, and the sections below show how to wire each one.

Why is an annual penetration test not enough for Annex A 8.8?

An annual penetration test is a point-in-time depth check, not a vulnerability management process. A.8.8 wants continuous discovery, advisory monitoring, triage and tracked closure; a pen test then validates that machinery once a year. Relying on it alone leaves twelve months of exposure between snapshots.

The two activities answer different questions. A vulnerability assessment is broad, automated and repeated: it asks what known flaws exist across everything you run. A penetration test is narrow, human-led and dated: it asks whether a skilled attacker can chain weaknesses into a breach today.

Where you have both, auditors weigh them differently. Months of scan history show the control running every week; the test report shows that someone tried to break in once, and what you fixed afterwards.

Pen test findings should drop into the same ticket queue as scanner findings, with the same severity clocks. A separate remediation project for the report is how items quietly age. If the test finds a known, unpatched flaw your scanner should have caught, the finding is about the loop, not just the host.

What must be in place first, and where does your cloud provider's patching stop?

Vulnerability tracking depends on three neighbours: the asset inventory in A.5.9, because you cannot triage software you have not listed; secure coding in A.8.28, which shares the library-tracking duty; and change management in A.8.32, which carries fixes to production. In cloud, the provider patches the platform; you patch everything you deploy.

Each neighbour supplies a different piece:

• Asset inventory (A.5.9). Vendor, product, version, where it is deployed and who owns it. This register does double duty, and without it every scan has blind spots you cannot see.
• Secure coding (A.8.28). If you build software, the third-party libraries inside it are inventory too, and both controls expect you to track them.
• Change management (A.8.32). Fixes reach production through the same tested route as any other change, covered in the triage section below.

Sequencing follows from this. Start vulnerability tracking as soon as the inventory exists. Do not wait for a perfect register: the first scan often finds unlisted systems, which the inventory then absorbs.

Cloud adds a boundary to draw. In AWS, Azure and GCP the provider patches the platform, while your virtual machines, images, containers, dependencies and configuration remain yours. A managed database service and a virtual machine you run yourself sit on different sides of that line. Write the split down per service and get the provider's reporting duties into the agreement. Assuming "the cloud handles it" is a recurring audit finding.

The scoping error is quieter. Teams scan the networks and hosts they remember, and the forgotten virtual machine stays forgotten and vulnerable.

A scanner pointed at what's convenient, not what's inventoried, only certifies what you already remembered.

How do you monitor advisories and scan often enough?

Combine three inputs: vendor and supplier advisories for your stack, NCSC alerts, and the CISA Known Exploited Vulnerabilities catalogue for flaws known to be exploited in the wild. Pair them with automated scanning across the whole estate at least monthly, as NCSC guidance recommends, so every finding is triaged into fix, acknowledge or investigate.

The NCSC guidance on vulnerability triage and prioritisation tells organisations to assess the entire estate at least every month and to sort unresolved issues systematically. The CISA Known Exploited Vulnerabilities Catalog guidance recommends monitoring the catalogue and prioritising listed flaws, because each one is known to have been exploited in the wild.

Set up the discovery layer in this order:

1. Subscribe to the right channels. Vendor advisories for your stack, plus the notification feeds of your critical SaaS providers.
2. Run a scanner across the estate. Cover endpoints, servers and cloud. Most endpoint-protection and cloud-native tools already include one.
3. Add dependency analysis if you build software. Third-party library flaws then surface with every build.
4. Write disclosure duties into supplier contracts as they renew, and give outsiders a route to report flaws in your own products.

Third-party libraries and supplier-managed systems are the usual leaks. They sit outside the process until someone names them in the inventory and in the contract.

The table compares what each discovery method finds and the evidence it leaves for an auditor.

How do you triage vulnerabilities and set remediation timescales you can actually hit?

Triage on two axes: the CVSS severity score and your own exposure, meaning internet-facing status, regulated data and compensating controls. Then write severity-driven clocks down. NCSC's business-as-usual timescales are 5 days for internet-facing software, 7 for operating systems and applications, and 14 for internal or air-gapped systems.

Those figures come from NCSC guidance on update by default and best-practice timescales. The 5-day window for internet-facing software already budgets for installing on a test environment or backup first and for a phased rollout. A clock that includes testing is one engineering can hit without an outage.

The exposure axis stops the score deciding alone. A medium on your public API can outrank a critical on an isolated test box, because anyone can reach one and almost no one can reach the other.

Here is an example severity ladder for a 50-person regulated firm:

• Critical: within about 48 hours.
• High: within a week.
• Medium: within a month.
• Low: on the normal release cycle.

Where the ladder and the NCSC timescales differ, hold internet-facing systems to the stricter number. Commit only to numbers you can hit, because your own policy becomes the audit yardstick.

Fixes travel through change management like any other change. Test where you can. At this scale, lean on automatic updates for endpoints, browsers and SaaS, where the risk of the patch is lower than the risk of waiting.

The failure to avoid is the urgent patch pushed straight to production untested. It converts a security risk into an outage.

What do you do when a vulnerability can't be patched?

Mitigate and record. Switch the vulnerable feature off, filter at the perimeter, raise monitoring, then capture the decision as a formal risk acceptance signed by someone with authority to accept it, with a named owner and an expiry date. "We're waiting" is only acceptable in writing.

Two cases trigger this path: a zero-day with no vendor fix yet, and a legacy dependency that cannot be upgraded without breaking something. Both follow the same four moves:

1. Mitigate. Apply the vendor workaround, disable the exposed feature, filter at the boundary and watch the asset harder.
2. Record the acceptance. State the flaw, the mitigation and the residual risk in a formal risk acceptance.
3. Assign authority and ownership. Someone able to accept the risk signs it, and a named owner carries the follow-up.
4. Set an expiry. Review on a fixed date and re-check for a patch or a better mitigation.

The review date also triggers a retest of the mitigation itself. A filter rule that has quietly changed no longer mitigates anything, and the review is when someone checks.

The pitfall is the exception handled by silence. A ticket open for months with no decision recorded reads to an auditor as neglect. The same ticket with a signed, owned, expiring acceptance reads as control.

What do auditors sample for ISO 27001 Annex A 8.8?

Auditors pull a scan report from months back, pick findings, and trace each to a fix plus rescan or a signed risk acceptance. They check dates against your own SLA table and compare scanner coverage with the asset inventory. Missing systematic discovery or criticals open for months grades major; isolated misses grade minor.

Expect these questions in the room:

• "How do you find out that something you run has a published flaw? Show me the feed, not the theory."
• "What are your remediation timescales by severity, and can you show me a recent critical that met them?"
• "Here's a high from your April scan report. Walk me to its closure or its risk acceptance."
• "How much of your estate does the scanner actually cover, and how do you know?"
• "What happened after your last pen test?"

If you ship software, open-source dependencies get asked about specifically. Keep the dependency-analysis reports ready alongside the infrastructure scans.

Have this evidence ready before the audit:

• The vulnerability management policy, with severity-based timescales and the scanning rules of engagement.
• Scanner and dependency reports over time.
• Remediation tickets that trace a finding to a deployed fix inside the committed window, plus the confirming rescan.
• Signed risk acceptances, each with an owner and a review date.
• The inventory the scans are scoped against, so coverage can be checked.
• The latest penetration test report and the remediation plan that followed it.

Smaller gaps aggregate. An individual SLA miss, a missing rescan or a risk acceptance without a review date grades minor, but a pattern of them can tip into a major.

The classic own goal is declaring victory on patch deployment without a rescan. The auditor then meets the same finding in the next report, with no evidence the fix took.

How do you engineer a continuous remediation pipeline?

Treat the control as a pipeline: scanner and dependency output becomes tickets automatically with severity-driven due dates, CI gates block newly vulnerable libraries at merge, patch rings run endpoint updates in waves, and a dashboard tracks time-to-remediate, coverage against inventory and acceptance expiries. The same view serves engineers, management and auditors.

Each part earns its place differently:

• Scanner-to-ticket automation. Findings flow into the ticketing system with due dates attached. The SLA clock starts itself, and nothing depends on someone reading a PDF.
• CI dependency gates. A check at merge stops a newly vulnerable library entering the build, which is cheaper than fixing it in production.
• Patch rings. Managed auto-update waves with exception reporting turn the largest patching surface, the endpoint estate, into a monitored background process.
• The SLA dashboard. The numbers are computed continuously rather than assembled before an audit, so the view doubles as management reporting and audit evidence.

Measurement is what separates this from a policy document. The auditor tests you against your own numbers, so the first time you compute them should not be in the audit room.

An SLA nobody measures is a wish with a number on it.

Effort is front-loaded and small. Tooling is days of work, and the steady cost is a few hours a week of triage, which is why the automation matters.

The upside is commercial. When a due-diligence questionnaire asks for your scanning cadence and remediation timescales, you export the answer from the dashboard instead of writing it from scratch. The same evidence answers cyber insurance proposals.

Our GRC engineering service builds this kind of continuous-monitoring pipeline, with vulnerability data as one of its richest evidence feeds. Our cloud security architect engagement covers scanner selection and integration across AWS, Azure and GCP, plus a prioritised remediation roadmap.

At this scale, that rhythm satisfies auditors and enterprise customers without a yearly scramble.

Frequently asked questions