ISO/IEC 27001:2022 · derived mapping target
A.8.8Management of technical vulnerabilities
Find out about technical vulnerabilities in your systems, assess your exposure and take timely action such as patching. Known, unpatched weaknesses are a leading cause of breaches.
Mapping at a glance
A.8.8Management of technical vulnerabilitiesISO/IEC 27001:2022
A.8.8 is covered by 30 Sekit CSF controls. +25 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0009Risk assessment · TechnicalsupportsFeeding risk assessments with real scanner and vulnerability data grounds A.8.8's technical exposure assessment in evidence instead of opinion.RCF-0012Risk treatment · TechnicalsupportsVerifying that each agreed technical risk measure is genuinely configured in the live environment closes the loop between a vulnerability decision and its implementation.RCF-0033Control testing program · TechnicalsupportsScheduled vulnerability scans and configuration drift checks exercise technical controls continuously, giving A.8.8's exposure picture ongoing rather than point-in-time evidence.RCF-0127Dependency/SBOM management · PolicysupportsThis policy facet mandates that every third-party component be inventoried, the software-composition leg of A.8.8's exposure that dependency vulnerabilities depend on.RCF-0128Dependency/SBOM management · ProcesssupportsThe process facet keeps a current bill of materials per application and reviews it against known vulnerability data on a schedule.RCF-0129Dependency/SBOM management · TechnicalsupportsThe technical facet runs automated dependency scanning that flags or blocks builds containing known-vulnerable components, a direct source of A.8.8's technical vulnerability data.RCF-0154Patch management · PolicysupportsThis policy facet sets written deadlines for applying security updates by severity across every system the company runs, the timeline backbone A.8.8 asks for.RCF-0155Patch management · ProcesssupportsThe process facet applies updates on the committed schedule and tracks per-device patch status so nothing silently falls behind.RCF-0156Patch management · TechnicalsupportsThe technical facet automates patch deployment and reports outstanding patches by age and severity across the fleet, the tooling A.8.8's patch program relies on.RCF-0200SIEM use cases · ProcessrelatedReviewing and updating SIEM detection rules on a recurring cycle keeps threat detection current, a monitoring practice adjacent to but distinct from A.8.8's vulnerability handling.RCF-0217Vulnerability scanning · PolicysupportsThis policy facet requires every server, workstation and externally reachable service to be scanned on a defined schedule, matching A.8.8's core scanning requirement.RCF-0218Vulnerability scanning · ProcesssupportsThe process facet runs scans on schedule and assigns every relevant finding to someone for action, turning scan output into tracked work.RCF-0219Vulnerability scanning · TechnicalsupportsThe technical facet deploys an automated scanner covering the full asset estate and pushes findings into the remediation tracker A.8.8's scanning requirement depends on.RCF-0220Vulnerability remediation SLAs · PolicysupportsThis policy facet defines remediation deadlines by severity, the SLA table A.8.8 expects organizations to hold themselves to.RCF-0221Vulnerability remediation SLAs · ProcesssupportsThe process facet tracks every open vulnerability against its deadline and escalates before the deadline slips, not after.RCF-0222Vulnerability remediation SLAs · TechnicalsupportsThe technical facet computes vulnerability age against the deadline table automatically and notifies owners as items approach or pass due dates.RCF-0229Patch prioritization · PolicysupportsThis policy facet defines how patches are ranked by severity, asset criticality and active exploitation, the prioritization logic A.8.8's timely-action requirement depends on.RCF-0230Patch prioritization · ProcesssupportsThe process facet applies the prioritization rule each cycle and records the reason whenever a patch is deferred past its tier's window.RCF-0231Patch prioritization · TechnicalsupportsThe technical facet merges scanner severity with live threat intelligence so the patch queue reorders around what is genuinely being exploited.RCF-0232Exposure management · PolicysupportsThis policy facet commits to maintaining a view of everything exposed to the internet and reducing exposure without business need, the exposure-management leg of A.8.8.RCF-0233Exposure management · ProcesssupportsThe process facet keeps an accurate inventory of internet-facing assets and shuts down exposure lacking business justification.RCF-0234Exposure management · TechnicalsupportsThe technical facet runs continuous external attack surface monitoring that alerts when a new service appears or a known one turns vulnerable.RCF-0235Penetration testing · PolicysupportsThis policy facet commits to an independent penetration test at a defined interval and after major changes, the adversarial-validation leg A.8.8 expects.RCF-0236Penetration testing · ProcesssupportsThe process facet scopes each test deliberately, runs it with a qualified tester and tracks every finding to closure or formal acceptance.RCF-0329Software supply chain (SBOM) · ProcesssupportsKeeping the component inventory for each application current and reviewing it for vulnerable dependencies extends A.8.8's exposure tracking into the software supply chain.RCF-0330Software supply chain (SBOM) · TechnicalsupportsAutomated dependency scanning in the pipeline flags components with known vulnerabilities before they ship, a supply-chain instance of A.8.8's technical vulnerability identification.RCF-0347Workload protection · ProcesssupportsChecking running cloud workloads against the security standard and investigating deviations extends A.8.8's technical exposure review into cloud infrastructure specifically.RCF-0424Patch/compensating controls (ICS) · PolicysupportsThis policy facet defines a documented approach for OT vulnerabilities that cannot be patched on normal IT timelines, the compensating leg A.8.8 anticipates for production systems.RCF-0425Patch/compensating controls (ICS) · ProcesssupportsThe process facet assesses OT vulnerabilities as advisories arrive and puts a documented compensating measure in place wherever patching is not feasible.RCF-0426Patch/compensating controls (ICS) · TechnicalsupportsTechnical compensating controls, network isolation, application allowlisting, targeted monitoring, protect unpatchable production systems the way A.8.8 expects when normal patching cannot apply.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
Cyber Essentials counterparts
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Patch management report
The proof that security updates are applied on time across devices and systems, with tracking of what is still outstanding.
From the Sekit evidence catalog
In practice
Vulnerability management usually has a scanner in place and a spreadsheet nobody keeps current. An SME can show a scan ran last month, but the report sits in an inbox instead of feeding a tracker with owners and deadlines. Critical findings get patched fast because someone notices; medium findings from six months ago are still open because no one escalates before the SLA slips. Dependency scanning flags an outdated library in the build, but the ticket to upgrade it has been open since the last release, revisited only when the next scan flags the same library all over again.
Common gaps
Vulnerability scans run on schedule, but findings are not tracked to an owner or a deadline, so remediation depends on someone remembering.
Critical vulnerabilities get patched quickly, but lower-severity findings routinely miss their remediation SLA without escalation to management.
Dependency scanning flags outdated libraries in the build, but the fix ticket stays open across multiple releases instead of blocking one.
Questions your auditor will ask
How quickly are critical vulnerabilities expected to be fixed once found?
Written deadlines set days for critical fixes and progressively longer windows for lower severities, and tooling tracks vulnerability age against that table automatically.
Does the company know what is exposed to the internet at any given time?
Continuous external attack surface monitoring alerts the team when a new service appears or a known one becomes vulnerable.
How are open-source components in the codebase checked for known flaws?
Automated dependency scanning runs in the pipeline and flags or blocks builds containing components with known vulnerabilities.
Is penetration testing a one-time exercise or does it repeat?
An independent penetration test is commissioned at a defined interval and after major changes, with findings tracked to closure.
Where regulation demands it
NIS2 Article 21 requires security patch management (6.6) and a defined vulnerability handling and disclosure process (6.10).
ENS op.exp.4 requires maintenance and security updates, the operational obligation A.8.8's patch and remediation program satisfies.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.8.8?”
Also via MCP, free with account