If you’ve been managing your information security using the 2013 version of ISO 27001, you’ll know that staying on top of software bugs and system weaknesses has always been a core requirement. However, in the 2022 update, the landscape of “Management of Technical Vulnerabilities” has shifted significantly. What used to be Control 12.6.1 is now Annex A 8.8, and it brings a much more proactive, modern approach to the table.
The 2022 version isn’t just a simple renumbering exercise. It reflects how much our technology has changed over the last decade, moving from static, on-premise servers to dynamic cloud environments and rapid software release cycles. Let’s dive into exactly what changed and how you can ensure your ISMS stays compliant.
Table of contents
The Structural Shift: From 12.6.1 and 18.2.3 to Annex A 8.8
In the 2013 standard, vulnerability management was primarily found in Control 12.6.1 (Management of technical vulnerabilities). However, there was also a separate control, 18.2.3 (Technical compliance review), which dealt with checking systems against security standards (like penetration testing).
In the ISO 27001:2022 update, these have been merged and refined into a single, comprehensive control: Annex A 8.8. It now lives within the Technological theme, one of the four new themes that replaced the old 14-domain structure. This consolidation makes it much easier to manage, as it brings the identification, evaluation, and remediation of vulnerabilities under one roof.
What Exactly is Annex A 8.8?
Annex A 8.8 requires that “information about technical vulnerabilities of information systems in use should be obtained, the organisation’s exposure to such vulnerabilities should be evaluated and appropriate measures should be taken to address the associated risk.”
In plain English, this means you need a system to:
- Discover what “windows” are open in your digital house (Identification).
- Decide how dangerous those open windows actually are (Evaluation).
- Close the windows or put bars on them (Remediation).
Key Changes and New Requirements in the 2022 Version
The 2022 update introduces several nuances that represent a significant departure from the 2013 “patch-as-you-go” mindset:
- Proactive vs. Reactive: While the 2013 version often felt like it was waiting for a bug to be found before acting, the 2022 version emphasizes proactive identification. This includes using Threat Intelligence (linked to the new Annex A 5.7) to anticipate vulnerabilities before they are exploited.
- The Role of Cloud Providers: The 2022 guidance specifically addresses the shared responsibility model. If you use cloud services, you must ensure your provider’s vulnerability management is compatible with your own. You can’t just “outsource” the risk.
- Vulnerability Disclosure: A new addition to the guidance is the concept of “Public Activities.” ISO now suggests that organisations should consider how they receive vulnerability reports from third parties, such as through “bug bounty” programmes or dedicated security contact points.
- Tighter Integration with Change Management: Annex A 8.8 is now more explicitly linked to Change Management (A 8.32). You can’t just throw a patch onto a live system; you need to test it, have a back-out plan, and document the process.
The Importance of Attributes in Annex A 8.8
Like all controls in the 2022 update, Annex A 8.8 now comes with “Attributes” to help you filter and manage your security efforts. According to Hightable.io, these tags are a lifesaver for risk assessments because they clearly define the control’s purpose:
- Control Type: Preventative and Detective.
- Information Security Properties: Confidentiality, Integrity, and Availability.
- Cybersecurity Concepts: Protect and Detect.
- Operational Capabilities: Information Protection and IT Operations Security.
Practical Steps for Compliance
Transitioning your ISMS to meet the new 8.8 requirements doesn’t have to be a nightmare, but it does require moving away from spreadsheets. Hightable.io suggests that the biggest mistake organisations make is treating vulnerability management as an annual “spring clean” rather than a weekly chore.
- Know Your Assets: You can’t patch what you don’t know you have. Start with a solid asset inventory (A 5.9).
- Establish Intelligence Sources: Sign up for vendor alerts (Microsoft, AWS, etc.) and monitor public databases like the CVE (Common Vulnerabilities and Exposures) list.
- Define Your Triage Timeline: Create a policy that dictates how fast you react based on severity. For example: Critical vulnerabilities must be patched within 48 hours; Low risk within 30 days.
- Automate Your Scanning: Manual checks are no longer enough. Use automated vulnerability scanners to sweep your network and applications regularly.
- Document Everything: Auditors will want to see the “before and after.” Keep your scan reports, your risk assessments for unpatched systems, and your change logs.
Why the Change Matters
In 2013, most vulnerabilities were found in the operating system. In 2022 and beyond, they are found in third-party libraries, container images, and cloud configurations. Annex A 8.8 recognizes this complexity. By requiring a more holistic, intelligence-driven approach, the standard helps you defend against modern threats like ransomware, which often relies on exploiting unpatched, known vulnerabilities to spread through a network.
Final Thoughts on the Transition
The jump from 12.6.1 to 8.8 is a move toward a more mature, systemised way of working. It stops being about “applying patches” and starts being about “managing risk.” As Hightable.io points out, a successful audit of A 8.8 isn’t about having zero vulnerabilities; it’s about proving you have a functioning process to find them and a rational, documented plan to deal with them.