Detecting a vulnerability has become relatively easy — the challenge lies in demonstrably and consistently turning that detection into a treated risk. This article describes a practical step-by-step plan that aligns with the risk approach of IEC 62443-2-1 and -3-2.
Step 1: Detection and initial triage
A new vulnerability is detected via a CVE, KEV entry, ICS advisory or vendor notice. The first question is a triage question: is this product or protocol in use in your own environment at all? This requires a current asset inventory.
Step 2: Determine industrial and organisational relevance
Not every vulnerability in an affected product is equally relevant to every organisation. Determine: is the device in a critical zone? Is it reachable from the internet? Is there a KEV entry? This platform supports this step with an industrial relevance score and an explicit IACS Radar assessment per vulnerability.
Step 3: Risk assessment
Translate the technical vulnerability into a risk estimate: what is the likelihood of exploitation (partly based on KEV and EPSS), and what is the impact on availability, integrity or confidentiality of the affected process? Explicitly include the context of the zone in which the device sits.
Step 4: Treatment choice
Based on the risk assessment, a treatment choice is made:
- Patch — remedy the vulnerability via a vendor update.
- Mitigate — reduce the risk via compensating measures, such as extra segmentation or increased monitoring.
- Accept — knowingly accept the residual risk, with a justification and a person responsible who takes this decision.
- Phase out — replace the device when patching or mitigating is not feasible, for example with end-of-life equipment.
Step 5: Implementation and verification
Carry out the chosen measure and verify that it actually has effect — for example by checking that a patch has been applied, or that a new firewall rule actually blocks the expected traffic.
Step 6: Documentation
Record which choice was made, why, by whom, and what evidence there is of implementation. This is not only useful for internal follow-up, but also the evidence with which you can demonstrate to supervisors, auditors or your own management that risks are actually being treated — not just detected.
Practical example
For a critical vulnerability in an RTU model without an immediate patch option, a grid operator decides on temporary mitigation via extra network segmentation, with a planned replacement of the device in twelve months. This decision, including justification and the person responsible, is recorded in the risk register.
Common mistake
Marking a vulnerability as "known" without an explicit treatment choice and documentation. Without this step it is afterwards not demonstrable whether, when and why a risk was actually treated.