In this ultimate how to implement guide to ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities, you will learn directly from an ISO 27001 Lead Auditor:
Table of contents
- 1. Establish a Complete Technical Asset Inventory
- 2. Configure Credentialed Vulnerability Scans
- 3. Subscribe to Vendor Security Advisories
- 4. Define a Risk-Based Patching Timeline
- 5. Implement a Patch Testing Environment
- 6. Address Software Composition (SCA) for Custom Code
- 7. Isolate Unsupported (Legacy) Systems
- 8. Enforce Mobile and Endpoint Updates
- 9. Verify Remediation via Rescanning
- 10. Maintain an Audit Trail of Patching Activities
1. Establish a Complete Technical Asset Inventory
Control Requirement: Information about technical vulnerabilities of information systems being used shall be obtained.
Required Implementation Step: Before you scan, you must know what exists. Run a network discovery scan (e.g., Nmap) to identify every active IP address, operating system, and open port on your subnet. Map these findings against your Asset Register; if you find a server that isn’t on the list, isolate it immediately.
Minimum Requirement: You cannot manage vulnerabilities for assets you do not know exist.
2. Configure Credentialed Vulnerability Scans
Control Requirement: Timely identification of vulnerabilities.
Required Implementation Step: Configure your vulnerability scanner (e.g., Nessus, Qualys, OpenVAS) with administrative credentials. An “uncredentialed” scan only sees the outside of the firewall; a “credentialed” scan logs in to check registry keys, DLL versions, and installed packages for true vulnerability status.
Minimum Requirement: Stop relying on external-only scans; they miss 80% of internal vulnerabilities.
3. Subscribe to Vendor Security Advisories
Control Requirement: The organisation shall evaluate its exposure to such vulnerabilities.
Required Implementation Step: create a dedicated email alias (e.g., security-alerts@domain.com) and subscribe strictly to the security bulletins for your critical vendors (Microsoft MSRC, Cisco Security, Red Hat Errata). Assign a specific engineer to triage these emails daily.
Minimum Requirement: Do not rely on the news; get the data from the source.
4. Define a Risk-Based Patching Timeline
Control Requirement: Appropriate measures shall be taken to address the associated risk.
Required Implementation Step: Write a standard that mandates patching speed based on CVSS (Common Vulnerability Scoring System) scores. For example: CVSS 9.0-10.0 (Critical) = Patch within 48 hours; CVSS 7.0-8.9 (High) = Patch within 7 days. Hardcode these SLAs into your ticketing system.
Minimum Requirement: Treating a Critical RCE vulnerability the same as a Low UI bug is negligence.
5. Implement a Patch Testing Environment
Control Requirement: Measures shall be tested before being applied.
Required Implementation Step: Create a “Pre-Production” group of servers that mirrors your live environment. Deploy patches to this group 24-48 hours before the general rollout. Verify that the patch does not break critical applications (e.g., IIS, SQL, custom apps).
Minimum Requirement: Never deploy patches to the entire fleet simultaneously (“The Big Bang”).
6. Address Software Composition (SCA) for Custom Code
Control Requirement: Vulnerabilities in custom software must be managed.
Required Implementation Step: Integrate Software Composition Analysis (SCA) tools (e.g., OWASP Dependency-Check, Snyk) into your CI/CD pipeline. These tools scan your proprietary code’s package.json or pom.xml files to find outdated, vulnerable third-party libraries (e.g., Log4j).
Minimum Requirement: Patching Windows is useless if your Java application runs a vulnerable library.
7. Isolate Unsupported (Legacy) Systems
Control Requirement: Manage risks where no patch is available.
Required Implementation Step: If a system (e.g., Server 2008, Windows XP) cannot be patched or upgraded, you must apply “Virtual Patching.” Move it to a segregated VLAN with strict ACLs, removing internet access completely. Document this as an accepted risk with a sunset date.
Minimum Requirement: “It’s too old to update” is not a defence; segregate it or kill it.
8. Enforce Mobile and Endpoint Updates
Control Requirement: Vulnerabilities on user devices must be managed.
Required Implementation Step: Configure your MDM (Mobile Device Management) or RMM (Remote Monitoring and Management) to force OS updates. Set a compliance policy: if a laptop is more than 30 days behind on security updates, revoke its VPN access automatically.
Minimum Requirement: Do not give users the option to “Remind me later” indefinitely.
9. Verify Remediation via Rescanning
Control Requirement: confirm that the vulnerability has been eradicated.
Required Implementation Step: Do not close the ticket just because you ran the installer. Trigger a specific re-scan of the affected host to confirm the registry key or file version has actually changed. Updates often fail silently or require a reboot to apply.
Minimum Requirement: The ticket is closed only when the scanner reports “Clean”.
10. Maintain an Audit Trail of Patching Activities
Control Requirement: Retain evidence of the vulnerability management process.
Required Implementation Step: Export monthly reports showing the “Time to Remediate.” Compare the date the patch was released by the vendor vs. the date it was installed on your systems. Use this delta to prove adherence to the timeline defined in Step 4.
Minimum Requirement: Auditors need to see the gap between “Release” and “Install”.
About the author
