Let’s be honest: software has bugs. From the operating system on your laptop to the firmware on your smart fridge, nothing is perfect. In the world of cybersecurity, these bugs are “technical vulnerabilities,” and hackers love them. They are the open windows in your otherwise locked house.
ISO 27001:2022 Annex A 8.8 is the control that tells you to close those windows. It requires you to obtain information about technical vulnerabilities, evaluate your exposure, and take appropriate measures. In plain English? Find the holes in your security and plug them before someone climbs through.
Here is a practical, step-by-step guide to getting this implemented without tearing your hair out.
Table of contents
Step 1: You Can’t Patch What You Don’t Know
Before you even think about running a vulnerability scanner, you need to look at your Asset Inventory (that’s Annex A 5.9). If you don’t know a server exists, you certainly aren’t patching it.
You need a complete list of:
- Hardware: Laptops, servers, firewalls, switches.
- Software: Operating systems (Windows, Linux, macOS) and applications (Adobe, Office, SQL Server).
- Versions: This is critical. Knowing you have “Windows” isn’t enough; you need to know if it’s Windows Server 2019 or the unsupported Windows 2008.
If your asset list is currently a messy spreadsheet from 2019, stop here and fix that first. You cannot implement Annex A 8.8 effectively without it.
Step 2: Establish Your Sources of Intelligence
How do you find out when a new vulnerability is discovered? You can’t rely on hearing about it on the news.
You need to define how you learn about new threats. This usually involves a mix of:
- Vendor Notifications: Sign up for email alerts from Microsoft, AWS, Cisco, or whoever supplies your critical tech.
- Vulnerability Databases: Keep an eye on public lists like the CVE (Common Vulnerabilities and Exposures) database.
- Specialist Forums: Industry newsletters or security groups often flag “zero-day” threats before vendors release a patch.
Step 3: Define Your Timeline (The Triage)
Not all vulnerabilities are created equal. A “Critical” flaw in your public-facing web server is an emergency. A “Low” risk flaw in a printer in the basement probably isn’t.
You need a timeline policy that dictates how fast you react based on the severity. For example:
- Critical Risk: Patch within 48 hours.
- High Risk: Patch within 14 days.
- Medium Risk: Patch within 30 days.
- Low Risk: Patch during the next maintenance window.
If you need help defining these timelines or creating the policy document itself, Hightable.io offers robust ISO 27001 toolkits that include pre-written Vulnerability Management policies ready to go.
Step 4: Detect and Assess
Now you move to the active phase. You need to regularly check your systems against the known vulnerabilities.
Automated Scanning
For most organizations, manual checking is impossible. You should use a vulnerability scanner (like Nessus, Qualys, or OpenVAS) to sweep your network regularly. These tools will spit out a report telling you exactly which devices are missing which patches.
Manual Penetration Testing
Scanners are great, but they lack human intuition. At least once a year (or after significant changes), you should have a professional “ethical hacker” test your systems to find the complex vulnerabilities that automated tools miss.
Step 5: The Remediation Process (Patching)
Once you have your list of holes, it’s time to fill them. But be careful—blindly installing every patch is a great way to crash your servers.
Your process should look like this:
- Test: Apply the patch to a non-production (test) environment first to ensure it doesn’t break your critical applications.
- Backup: Always take a snapshot or backup before applying updates (see Annex A 8.13).
- Deploy: Roll out the patch to live systems.
- Verify: Run your scanner again to prove the vulnerability is actually gone.
Step 6: What If You Can’t Patch?
Sometimes, you can’t install a patch. Maybe the software vendor has gone bust, or the patch breaks a legacy application you rely on. Does this mean you fail the audit?
No. But you must implement compensating controls. If you can’t close the window, you put bars on it.
Options include:
- Network Segregation: Isolate the vulnerable machine on a separate network (VLAN) so it can’t talk to the internet or other servers.
- Virtual Patching: Use a Web Application Firewall (WAF) or IPS to block the specific attack traffic that targets the vulnerability.
- Disable Services: Turn off the specific feature that is vulnerable.
Whatever you do, document it. You need to show the auditor that you assessed the risk and took action, even if that action wasn’t a standard patch.
Step 7: Roles and Responsibilities
Finally, make sure someone owns this process. It is a common mistake to assume “IT” is handling it. You need specific names against specific tasks:
- Who monitors the vendor alerts?
- Who authorizes the downtime for patching?
- Who reviews the scanner reports?
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Common Pitfalls
- Ignoring Third-Party Libraries: Developers often patch the OS but forget the open-source libraries inside their code. Ensure your scanning covers your applications too.
- The “One-Time” Clean Up: Patching is not a spring cleaning activity; it is a weekly chore. If your last scan was six months ago, you are vulnerable.
- Lack of Evidence: Keep your scan reports and your change requests. The auditor will want to see the “Before” and “After” picture.
Conclusion
Implementing Annex A 8.8 is one of the most effective ways to harden your organization against cyber attacks. By moving from a reactive “panic patching” mode to a structured, risk-based approach, you make life significantly harder for attackers.
If the documentation side of this feels overwhelming, remember that resources like Hightable.io can provide the templates and guidance you need to structure your vulnerability management process correctly from day one.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
