What does it, seen from an EN IEC 62443-4-1:2018/A11:2026 auditor’s point of view, take to cross the finishing line?
You know it from product and project management: Start with the end, and have that understanding guide your work in the right direction. It is the common North Star for teams in the organization to navigate towards. When it comes to auditing, the same principle applies.
Based on the (not yet cited in the OJEU) EN IEC 62443-4-1:2018/A11:2026© harmonized standard, I’m working on a tool to help guide my customers prepare for a coming audit (with a similar tool for 4-2 underway). The purpose of this article is to share my reflections on the tool.
Sure, it is lightweight (and still at the MVP level) compared to what a formal auditor (e.g., TÜV) would bring, but the point is not to be TÜV-like. The point is to gain a decent understanding of what an audit will expect, and for that understanding to provide direction, transparency, and alignment.
DISCLAIMER: EN IEC 62443-4-1:2018/A11:2026© has not yet been cited in OJEU and is still in the works. This article is based on draft insights and should not be considered legal advice or technical recommendations.
The Standards Sandwich
You may recall where EN IEC 62443-4-1:2018/A11:2026© is placed in the Sandwich, see Infographics #1. 4-1 is about the process, where 4-2 is about the product.
4-1 is linked to (not yet cited in OJEU) EN 40000-1-2© (Cyber Resilience Principles) and to (not yet cited in OJEU) EN 40000-1-3© (Vulnerability Handling), which is evident in Annexes F (Mapping of EN 40000-1-2 to EN IEC 62443-4-1) and G (Mapping of EN 40000-1-3 to EN IEC 62443-4-1) in EN IEC 62443-4-1:2018/A11:2026.
See also EN IEC 62443-4-1/A11©: A closer look.
Infographics #1.
The audit tool
Such a tool must be as close as possible to the actual standard, here EN IEC 62443-4-1:2018/A11:2026, with exact and valid references to Clauses and Requirements, which is why I cannot share a link to the tool itself. However, I’ll share some screenshots illustrating the intention.
In designing the tool, I’ve assumed the role of an auditor. The tool is based on draft material, but it can, of course, be updated once EN IEC 62443-4-1:2018/A11:2026 is final and cited in OJEU.
The tool header
You may wonder why I’ve also chosen to include the CRA product profile, here set to Important Class I (Standard Product, Important Class 1, Important Class II, Critical). The rationale is to guide consistency. In the example below, the organization aims for ML-2 while having an Important Class I product, which is inconsistent.
See the note in EN IEC 62443-4-1/A11©: A closer look at the Maturity Model: If your product is categorized as an “Important” (Class I or II) or “Critical” product under the CRA, ML3 is non-negotiable. For unclassified (“Default”) products, although the law is slightly more flexible, following ML3 remains the safest legal harbor for avoiding liability.
The audit cards - one per requirement
The core design idea is to track the audit workflow and the compliance findings for each requirement in audit cards, here for SM-1:
Flow and findings
The sandwich link
This is an informational field illustrating the link from the EN IEC 62443-4-1:2018/A11 requirement to CRA. Here is an example from Practice 1, SM-9 (Third-party components):
SM-9 is, via EN IEC 62443-4-1/A11 Annex F, linked to EN 40000‑1‑2 clause 7.11, which is linked to CRA Annex I, but in this case through functional alignment. There is no explicit clause 7.11 to ESR mapping inside the draft standard EN 40000-1-2 Annex C. Some explicit mappings are found in Annex C, but do not explicitly cover all EN 40000-1-2 clauses, at least in the draft version I have access to.
Rationale for the functional SM-9 alignment:
- EN IEC 62443-4-1:2018/A11:2026 SM-9: Third-party components
- EN 40000-1-2 clause 7.11: Third-party component cybersecurity management (shortened to Third-party components in the remaining clause)
- Annex I, Part II, Point (6): Take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements
Filled audit card examples
Administration header
The tool includes features like
- Search
- Grouping
- Views
- Export (to PDF)
- Reset
- Random example fill-out
- session persistence (JSON)
View: Executive Matrix (Heatmap)
Wrap-up
The purpose of the article was to share my thoughts on how to help an organization pass an audit against (not yet cited in OJEU) EN IEC 62443-4-1:2018/A11:2026 facilitated by a relatively simple online tool. And I hope you collected some inspiration.
Graphics and tools created with AI support