Annex A 8.8 asks you to know about technical vulnerabilities in the systems you run, judge your exposure, and act. MopokeHQ does that for the software you build and keeps a hash-chained record of each step.
ISO/IEC 27001:2022 control 8.8, management of technical vulnerabilities, asks you to get information about vulnerabilities in the systems you use, evaluate your exposure, and take appropriate measures.
The 2022 control replaced A.12.6.1 and A.18.2.3 from the 2013 edition. ISO does not set scan frequencies or patch deadlines. You define them, and the auditor checks that you meet them.
What the control and its ISO/IEC 27002 guidance look for, and the record MopokeHQ keeps for each.
| What 8.8 looks for | MopokeHQ evidence |
|---|---|
| Software inventory: application, version, where deployed | An SBOM for every build, deployment reports per environment, and an optional runtime check-in of live PHP, Node, extension and OS versions |
| Sources of vulnerability information | OSV, php.net security releases, CISA KEV and FIRST EPSS, with each match logged |
| Vulnerability scanning, including third-party libraries | Dependency, container, SAST, secrets, DAST, infrastructure as code and licence scans from one pinned image. Every stored SBOM is re-matched when a new advisory lands. |
| Evaluate exposure | Each exposure marked Confirmed live, Likely or Possible. Priority from CVSS, KEV, EPSS, live confidence and project criticality. |
| Decide on action, including "not affected" | "Not affected" suggestions on P2 and P3 are confirmed by a person and stored as VEX statements |
| Defined timelines | SLA presets per priority, 48 hours, 14 days and 30 days by default. Unacknowledged P1s escalate after 4 hours. |
| Test before deploying, through change management | Fix merge requests open from your own runner and go through your normal pipeline and review |
| Verify the remediation worked | An exposure closes only when the fixed version is seen deployed |
| Keep an audit log | Append-only, hash-chained evidence log, exported as PDF and JSON per period |
Your vulnerability procedure says how quickly you act on each risk level. MopokeHQ’s presets give you a starting point to write into it. Each finding carries its deadline, and the evidence pack shows which deadlines were met.
The mapping MopokeHQ ships is for 8.8. The same records also support a few neighbouring controls.
An evidence pack for the audit period: what was found, when, the deadline, and when the fix reached production. The JSON copy carries the chain hashes, so anyone can check no entry was changed or removed.
If the auditor wants to see the system itself, open MopokeHQ and walk through a finding.
Security and dataMopokeHQ covers vulnerability management for the software you build. Your risk register, policies and Statement of Applicability stay where they are. MopokeHQ itself does not hold ISO 27001 certification.
That you get information about technical vulnerabilities in your systems, evaluate your exposure and take appropriate action. ISO/IEC 27002 adds guidance on inventory, roles, scanning, patching, verification and keeping an audit log.
The standard does not set a frequency. You define it and show you met it. MopokeHQ scans in every pipeline and re-matches every stored SBOM whenever a new advisory is published.
Control 8.8 in the 2022 edition replaces A.12.6.1 (management of technical vulnerabilities) and A.18.2.3 (technical compliance review).
No. MopokeHQ covers vulnerability management for the software you build. Keep your risk register, policies and Statement of Applicability where they are.
In Sydney, Australia, with all other MopokeHQ data.
One job in your CI pipeline. Your first SBOM is matched against every advisory we hold within minutes.