IEC 62443 evidence pack: one-page version

Picture a Stage-2 audit at a 120 MW solar park. Three minutes in, the auditor asks the quiet part out loud: "That's interesting — now show me the evidence." The programme manager opens a SharePoint folder labelled 62443_compliance. Inside are eleven PDFs. Nine are vendor marketing brochures with the words "62443-ready" splashed across the top. One is a screenshot of a CSV. The eleventh is the signed contract with the EPC. The auditor closes the laptop, smiles politely, asks for a coffee, and writes seventeen non-conformities into the follow-up letter.

This post exists so that does not happen to you.

TL;DR

If you cannot produce a specific document on demand, you are not actually IEC 62443 compliant — regardless of what your supplier's glossy says. This is the one-page evidence pack: a tight, opinionated checklist of the artefacts an auditor will ask for under each of the four numbered groups of the standard (IEC 62443-2-x, -3-x, -4-x), plus a small set of cross-cutting items. Pick the pack that matches your role, print it, and walk into your next project with it in hand. The five-question pre-audit self-test at the end is the most useful 100 words in this post.

Who this is for

The ISA/IEC 62443 series defines four principal roles — asset owner, integrator, service provider, and product supplier — and every artefact below maps to one of them. If you have not already read the IEC 62443-1-x foundations post , start there: the role definitions and the Industrial Automation and Control System (IACS) lifecycle model in IEC TS 62443-1-1:2009 are the scaffolding everything else hangs from.

• Asset owners (the operators — utilities, generators, plant owners): your pack is -2-1 + -3-2.
• Integrators and service providers (EPCs, system integrators, maintenance contractors): your pack is -2-4.
• Product suppliers (PLC, RTU, gateway, HMI, inverter, BMS vendors): your pack is -4-1 + -4-2.
• Everyone owes the cross-cutting artefacts in section 5.

A deeper walkthrough of each lives in the -2-x management-system post , the -3-2 and -3-3 post , and the -4-1 and -4-2 post . This one is the cheat sheet.

1. The hierarchy of 62443 evidence

Auditors — the good ones, anyway — think in three tiers. You should too.

• Tier 1: policy and procedure documents. What you intend to do. Security programme charter, risk-assessment procedure, change-management policy. Cheapest to produce, easiest to fake, weakest as evidence.
• Tier 2: records and operational evidence. What you actually did. Signed minutes, training attendance lists, ticket exports, test reports, patch logs, audit findings with closure dates. This is where audits are won or lost.
• Tier 3: independent certifications. What an accredited third party verified. ISASecure CSA / SSA / SDLA certificates, IECEE CB Scheme test reports, or accredited-body audits against IEC 62443-2-4 for service providers. Most expensive, hardest to argue with.

A mature programme has all three. A defensible programme has at least Tiers 1 and 2 across the board, with Tier 3 sitting under the highest-risk components. A "marketing PDF" programme has none of the above and several brochures.

For product-side Tier 3 in particular, ISASecure operates the three product/process schemes most often cited in tenders — CSA to IEC 62443-4-2, SSA to IEC 62443-3-3, and SDLA to IEC 62443-4-1 — all under ISO/IEC 17065 . The IECEE CB Scheme provides the parallel international conformity-assessment route through IEC 62443 and is the one most European buyers will recognise.

2. Asset-owner evidence pack — for IEC 62443-2-1:2024 and IEC 62443-3-2:2020

The 2024 edition of IEC 62443-2-1 replaced the old Cyber Security Management System (CSMS) language with eight Security Programme Elements (SPEs) and added a maturity model. Risk methodology still lives in IEC 62443-3-2:2020 , which defines the System under Consideration (SuC), the zone and conduit drawing, and the Target Security Level (SL-T) derivation.

Group your evidence by SPE. If an auditor cannot find any of the following on demand, expect a finding.

Most of the artefact map above sits inside SPEs 1 through 8 — organisational security, configuration management, network and communication protection, component protection, data protection, user access control, event-and-incident management, and system integrity and availability. The ISA Global Cybersecurity Alliance (ISAGCA) Quick Start Guide is the cleanest free reference to the SPE structure if you do not have the IEC text in front of you.

3. Integrator and service-provider evidence pack — for IEC 62443-2-4:2023

IEC 62443-2-4:2023 — Edition 2.0, published December 2023 — defines the security capabilities a service provider offers an asset owner during integration and maintenance, organised into Security Programme (SP) topics SP.01 through SP.12 (staffing, assurance, architecture, wireless, configuration management, hardening, malware protection, patch management, backup/restore, monitoring, event management, account management, remote access). The 2023 revision converted many former "capabilities" into required processes with documented outputs — meaning evidence is now non-negotiable.

SP.05 (assurance) and SP.12 (event management) sit underneath the above as cross-cutting controls and should be picked up by the cross-cutting pack in section 5.

4. Product-supplier evidence pack — for IEC 62443-4-1:2018 and IEC 62443-4-2:2019

IEC 62443-4-1:2018 defines a Secure Development Lifecycle (SDL) built around eight practices: Security Management (SM), Specification of Security Requirements (SR), Secure by Design (SD), Secure Implementation (SI), Security Verification and Validation Testing (SVV), Management of Security-related Issues (DM), Security Update Management (SUM), and Security Guidelines (SG). IEC 62443-4-2:2019 then defines the technical Component Requirements (CRs) per Foundational Requirement, with capability Security Levels SL-C 1 to SL-C 4.

For IEC 62443-4-2:2019, add a per-FR test evidence pack mapping each CR claim to a result, summarised by an accredited certification body's report. A clean way to do this is to attach the ISASecure CSA certificate plus the underlying Functional Security Assessment (FSA-C) and Vulnerability Identification Testing (VIT-C) reports, or the equivalent under the IECEE CB Scheme . For development-process certification only — without a product certificate — ISASecure SDLA or an IECEE IEC 62443-4-1 assessment is the equivalent. Note that the SDLA scheme allows a supplier to scope out individual sub-practices, so always read the certificate's scope statement, not just the logo.

5. Cross-cutting artefacts

These are the ones programmes routinely forget — and they are the ones auditors enjoy asking for, because they reveal whether the programme is actually run or merely written down.

1. Risk acceptance log signed by the management body. Not a project manager. Not a "responsible engineer". The accountable executive named in the SPE 1 charter, with a date and a residual-risk value.
2. Compensating-countermeasure register. Where a control could not be implemented natively, the compensating measure is named, its rationale documented per the IEC TS 62443-1-1:2009 definition, and its effectiveness reviewed on a stated cadence. IEC 62443-2-1:2024 explicitly allows compensating controls for legacy systems — but only if they are documented.
3. Exception / deviation register. Every deviation from a policy or baseline, with an owner, an expiry, and a compensating control.
4. SL-T → SL-C → SL-A traceability matrix per zone. The asset owner derives SL-T per -3-2. The product supplier publishes SL-C per -4-2. The integrator delivers SL-A (achieved) in the as-built configuration. Auditors love this matrix because gaps fall out of it visually.
5. Evidence-pack version-control log. The evidence itself needs version control. If the audit folder is "live SharePoint" with no revision history, your evidence has no integrity.
6. Time-synchronisation evidence. Often missed. IEC 62443-3-3:2013 SR 2.11 (Timestamps) requires components to provide reliable, synchronised timestamps for audit records. If your PLC, jump host, and SIEM clocks drift, your audit trail is not legally usable. NIST SP 800-82 Rev. 3 makes the same point in OT terms.

6. What does NOT count as evidence

A short, opinionated red-flags list. None of the following will survive an audit on its own:

• Marketing PDFs that say "62443 compliant" without a part number. IEC 62443 is a series, not a single standard. "Compliant" with which of the thirteen-plus documents? At what edition year? Against which SL? Without those, the claim is decorative.
• Single-number SL claims. "We're SL 3" is meaningless. IEC 62443-3-3 and -4-2 express security levels as a seven-element vector — one per FR (Identification & Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, Resource Availability). A vector like SL-C (3,2,3,1,3,2,3) is the proper form.
• Vendor certificates without a scope statement. The ISASecure SDLA certificate, for example, only tells you the process was assessed for the sub-practices in scope — which can legitimately be a subset. Always read the scope annex.
• Compliance matrices that are not signed, dated, or version-controlled. A Word document that has been edited by six people with track-changes off is not evidence; it is a rumour.
• Test reports from before the most recent major firmware update. A penetration-test report against firmware v4.2 does not certify v4.7. The supplier owes a delta assessment or a re-test.

7. The five-question pre-audit self-test

The most useful 100 words in this post. Run this five-question test before the auditor crosses your threshold. If you cannot answer "yes, here it is" to all five, fix that first.

1. Can you produce the SL-T vector for every zone, derived per IEC 62443-3-2, signed within the last 24 months?
2. Can you produce a complete asset inventory whose firmware versions match what is actually deployed at the plant today?
3. Can you produce an internal-audit finding from the last 12 months that resulted in a corrective action that is now formally closed?
4. Can you produce evidence that a maintenance service provider has been assessed against IEC 62443-2-4 in the last contract cycle?
5. Can you produce the residual-risk acceptance log, signed by the relevant management-body member, dated and current?

Five "yes" answers is not compliance — but five "no" answers is definitely non-compliance.

8. How to use this as a project tool

Three concrete uses, in order of how often each typically surfaces:

• On a new project. Pick the pack that matches the role you are playing — owner, integrator, or supplier — and use it as a deliverables list in your project plan. Each row becomes a work-package output.
• On an audit. Produce the right pack and check the age of each artefact. Anything older than 12 months is a question waiting to be asked; anything older than 24 months is a finding waiting to be written.
• On procurement. Hand the supplier a tailored version of the product-supplier pack as a tender annex. "Submit each of items 1–10 with your bid, or the bid is non-responsive." This single tactic raises the floor of supplier responses faster than any contractual clause.

The same logic underpins the NIS2 mapping post — where the NIS2 Directive (EU) 2022/2555 requires "appropriate and proportionate technical, operational and organisational measures", these are the artefacts that demonstrate them. And for products placed on the EU market after December 2027, the Cyber Resilience Act applicability post walks through where the product-supplier pack here doubles as a CRA conformity dossier.

FAQ

What's the difference between a -4-1 certificate and a -4-2 certificate? -4-1 certifies the process — the supplier has a documented, audited Secure Development Lifecycle. -4-2 certifies the product — a specific component, at a specific firmware version, meets the technical Component Requirements at a stated capability Security Level. You need both; a supplier with -4-2 only has a tested product but no guarantee the next release will be developed the same way. A supplier with -4-1 only has a clean process but no certified product on the shelf.

How long should I retain evidence for? Match the longer of: the IACS lifetime (typically 15–25 years for a renewables plant), the regulator's retention period (under NIS2 transposition this often lands at six years post-incident), and the group records-retention policy. Time-stamped audit logs from SR 2.11-relevant systems should be retained at least three years on warm storage, longer on cold storage. Never delete an artefact while an open finding references it.

Do I need ISASecure or IECEE CB to comply with -4-1? No. IEC 62443-4-1 compliance can be self-declared, second-party assessed (by a customer), or third-party certified. Self-declared evidence is acceptable to many auditors if it is tier-2-grade: SBOMs, test reports, traceability matrices, training records. Third-party certification via ISASecure SDLA or an IECEE CB Scheme IEC 62443-4-1 assessment simply shortcuts the conversation. For products sold into critical-infrastructure tenders in Europe, third-party is increasingly the de facto requirement.

Where does NIS2 evidence sit in this pack? NIS2 evidence is a superset that consumes the 62443 pack, not a replacement. The NIS2 applicability post covers who's in scope; the NIS2 mapping shows which 62443 artefacts satisfy which Article 21 measures. Practically: an asset owner's -2-1 pack covers most of NIS2 Article 21(2)(a)–(j); the integrator's -2-4 pack covers (d) supply-chain security; the product-supplier's -4-1/-4-2 pack underpins the rest. Add NIS2-specific items — the 24-hour early-warning template, the competent-authority registration record, and the management-body cyber training attestation — and you have a NIS2-defensible position built on a 62443 foundation.

If this checklist saved you one finding, the post has paid for itself. To argue with item 6 in any of the tables, LinkedIn is the way to find me.