Management of technical vulnerabilities

Plain-language summary

Finding out about weaknesses in the software, systems and devices you use, judging how exposed you are, and fixing or containing them in time — by patching, changing configuration or adding compensating controls — before someone else uses them against you.

What the clause is really asking

Exploiting unpatched systems, especially those facing the internet, is one of the most common ways attackers get in. The control asks for a process with four parts. First, know what you have: an asset inventory detailed enough to show which software and versions run where, and who owns them. Second, get information about vulnerabilities from vendor advisories, your MSP, scanning tools and penetration tests. Third, evaluate the exposure in your environment and decide the response and timeframe: patch, change a configuration, add a compensating control, or accept the risk formally. Fourth, act, test and verify the fix. Unsupported software that will never be patched has to be identified and planned out. The guidance also expects a way for outsiders to report vulnerabilities to you. The common misunderstanding is that Windows Update equals vulnerability management; firewalls, VPN appliances, the ERP, website plugins, printers and networked production equipment carry vulnerabilities too. Lapsed security licences sat behind the Information Regulator's first POPIA fine, and financial-sector clients working under the FSCA/PA Joint Standard 2 of 2024 will ask suppliers how they patch.

What auditors look for

Auditors ask for the vulnerability management procedure and the latest scan or patch-compliance report, then pick a critical vulnerability from the past few months and trace it: when did you learn of it, which assets were affected, what was decided, when was it fixed, and how was the fix verified? They compare the timeframes in the procedure with what actually happened. They look for unsupported operating systems and applications and ask for the risk acceptance. They check that firewalls and network devices are in scope, not just Windows machines. The hard question: what is the oldest unpatched critical vulnerability in your environment, and who accepted it?

Typical evidence

Vulnerability management procedure with severity-based remediation timeframes; software and asset inventory with versions and owners; vulnerability scan reports; patch compliance reports for endpoints, servers and network devices; penetration test reports and remediation tracking; risk acceptances for unpatched or unsupported systems; register of end-of-life software; published vulnerability-reporting contact; records of vendor advisories reviewed.

How to comply — recommendations

Set remediation timeframes by severity in a short procedure — for example, critical internet-facing issues within 14 days, sooner if actively exploited, and high within 30 days — and make them realistic enough to meet. Make sure the inventory captures software versions, including firewalls, VPN appliances, printers and line-side PCs. Run authenticated vulnerability scans monthly, through your MSP if needed, plus an external scan of your internet-facing addresses. Subscribe to security advisories from your key vendors. Track every critical and high finding to closure in one list with owner and date. Where you cannot patch, as with much legacy production equipment, isolate the system and record the risk acceptance. Commission a penetration test annually or after major change. Publish a security contact address.

Common nonconformities

No defined remediation timeframes, or timeframes routinely missed; vulnerability scanning not performed or limited to Windows endpoints; firewalls and network devices never patched; unsupported operating systems in use with no risk acceptance; penetration test findings left open; inventory too incomplete to identify affected assets; vendor security advisories not monitored.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.