IEC 62443 Audit Checklist 2026: The Essential Prep Guide

An IEC 62443 audit checklist is only useful if it tells you what an auditor will ask to see, not just which clauses exist. This one is built for asset owners: use it to run an IEC 62443 internal audit of an operating IACS, or as ACSSA audit preparation before an accredited ACSSA inspection or certification body arrives.

The short answer to “what will they check?” is your 62443-3-2 risk assessment first, then your security program against the eight security program elements (SPEs) of IEC 62443-2-1:2024, your zone controls against 62443-3-3 and your service providers against 62443-2-4. At every step, the auditor wants records showing the process actually runs.

If you need a refresher on how those parts fit together, start with our guide to the IEC 62443 parts explained.

What an IEC 62443 audit checklist needs to cover

For an asset owner, four parts define the audit scope. IEC 62443-2-1 Edition 2.0, published in August 2024, sets the security program requirements and restructures them into eight SPEs, from SPE 1 Organizational security measures to SPE 8 System integrity and availability. IEC 62443-3-2 sets the risk assessment and zone and conduit process, IEC 62443-3-3 lists 51 system requirements under seven foundational requirements, and IEC 62443-2-4 covers integration and maintenance service providers.

Because 2-1:2024 also defines a maturity model, an auditor asks two things of each requirement: is it in place, and how consistently is it practiced? Supplier requirements in 4-1 and 4-2 sit outside an asset owner audit, although product supplier security documents can serve as supporting evidence.

How ACSSA assesses an operating IACS

ISASecure’s Automation and Control System Security Assurance (ACSSA) program evaluates an asset owner’s IACS against 62443-2-1, 2-4, 3-2 and 3-3. Version 1.0.0 took effect on 17 February 2026. Before you plan ACSSA audit preparation, check these points against the ISASecure ACSSA certification program page and the ACSSA-101 planning guide for asset owners.

• Eligibility. The IACS must be in operation or near transition to operation, and the asset owner must be fully accountable for managing, operating and maintaining all hardware and software within it.
• Entry inputs. A system asset inventory under change control and a risk assessment performed to 62443-3-2. ACSSA-101 also expects the equipment under control list and security program documents under change control, plus a list of all service providers that interact with the IACS, with delegated responsibilities documented in agreements.
• Exclusions. ACSSA-101 excludes cases where cloud-based functionality can directly or indirectly make changes to the equipment under control.
• Order. ISASecure calls a conformant 3-2 risk assessment the first requirement for any ACSSA inspection or certification.
• Outcomes. An inspection body (ISO/IEC 17020) issues a point-in-time inspection report. A certification body (ISO/IEC 17065) can grant a three-year certificate.

Scope is site and system specific, so two near-identical plants need two evaluations. Fix the IACS boundary before you apply the IEC 62443 audit checklist below, or your samples will not line up with the auditor’s.

The IEC 62443 audit checklist: questions and evidence

Work through this IEC 62443 audit checklist row by row. The questions are ours, grouped under the SPE or part we would file them under, not text from the standard. The third column doubles as your evidence request list.

Area	Checklist question	Evidence an auditor may sample
Program governance (SPE 1)	Is the security program approved, owned by named roles and reviewed by management in the last 12 months?	Approved program, role assignments, management review minutes
Program governance (SPE 1)	Has everyone who interacts with the IACS, including contractors, been trained for their role?	Training matrix checked against current staff and contractor lists
Asset inventory and configuration (SPE 2)	Is the asset inventory complete, current and under change control?	Inventory version history; devices picked on site traced to the inventory and back
Asset inventory and configuration (SPE 2)	Does every IACS change pass an approved change process with a security review?	Change tickets from the period with approvals and updated baselines
Risk assessment (3-2)	Is the system under consideration (SUC) defined, with initial and detailed risk assessments complete and current?	SUC description, architecture and data flow drawings, dated risk register
Risk assessment (3-2)	Is the cybersecurity requirements specification (CRS) documented and approved by the asset owner?	Version-controlled CRS, sign-off record, tolerable risk statement
Zones, conduits and SL-T (3-2, 3-3)	Is every asset in a zone, and does every conduit match an approved data flow?	Zone and conduit drawings compared with firewall and switch configurations
Zones, conduits and SL-T (3-2, 3-3)	Does each zone have a target security level (SL-T), with the achieved level checked against 3-3?	SL-T rationale, SL-T/SL-A gap analysis, justified compensating countermeasures
Network and remote access (SPE 3)	Does all remote access use a controlled path with strong authentication, approval and session logging?	Sampled sessions matched to approval tickets; jump host configuration
Network and remote access (SPE 3)	Are inter-zone firewall rules reviewed and each tied to a business need?	Latest rule review; sampled rules with justification
Hardening and patching (SPE 4, SPE 8)	Are hardening baselines defined per component type and verified on installed devices?	Configuration checks on sampled hosts, HMIs and network devices
Hardening and patching (SPE 4, SPE 8)	Is every security patch assessed, then applied or formally deferred with a compensating measure?	Patch assessment log, deferral approvals, vendor compatibility confirmations
Hardening and patching (SPE 4, SPE 8)	Are backups protected and restore-tested?	Backup records; latest restore test result
Data protection (SPE 5)	Are project files, configurations and credentials classified and protected in storage and transit?	Classification scheme, encryption settings, removable media logs
Access control (SPE 6)	Are accounts individual, role-based and reviewed, with shared and default accounts controlled?	Accounts checked against leavers, last access review, privileged account register
Event and incident management (SPE 7)	Are security events logged, monitored and escalated?	Log source list; sampled alerts with triage notes
Event and incident management (SPE 7)	Has the OT incident response plan been exercised and lessons applied?	Exercise report, closed actions
Service providers (2-4)	Are integration and maintenance providers listed, with security responsibilities in agreements?	Provider register, contract clauses, provider-raised change tickets
Records and evidence	Can every requirement be traced to a current document and to operating records?	Evidence index by requirement, document control history

How auditors sample evidence

No auditor reads everything, and your IEC 62443 audit checklist should not try to. ACSSA-101 lets the inspection or certification body select a sample of systems under consideration and zones, provided the sample is representative of the whole IACS. Within each zone, auditors sample populations: change tickets, accounts, patch decisions, remote sessions and alerts.

ACSSA-101 lists three artifact types: D (document), O (observe) and T (test). Its evaluation activities also include interviewing personnel and inspecting systems and networks, so expect policies and drawings to be read, staff to be interviewed, and settings, rules and account lists to be checked on the live system.

Good auditors trace in both directions. Top-down, they follow a requirement from procedure to record to live configuration. Bottom-up, they pick a switch or HMI on the floor and ask for its inventory entry, zone, hardening baseline and last patch decision. In our experience, bottom-up traces find the most gaps, because inventories drift faster than anyone updates them.

Any scanning that could affect the IACS must be risk justified and approved by the asset owner; ACSSA-101 warns that network scanning has caused some IACS components to fail. For your own IEC 62443 internal audit, choose the samples yourself rather than letting process owners hand-pick examples. We typically suggest 10 to 25 items per population, more than a gap analysis needs, scaled to its size and risk.

The operating-evidence trap: why documents alone fail

In our experience, a common reason organizations stumble is a well-written document set with no proof that it runs. ACSSA evaluates implemented controls and evidence, not design intent. ISASecure describes the path as risk assessment, then documented policies and procedures, then evidence they are followed plus verification of technical controls, then reporting. A binder only clears the second step.

Typical failures we see when we run an IEC 62443 audit checklist against a new program:

• Quarterly access reviews are required, but the only review on file was done while writing the procedure.
• Deferred patches have no recorded decision or compensating measure.
• The incident response plan has never been exercised.
• Service provider contracts mention security, but nothing shows the provider followed your remote access procedure.

We found no minimum record period in ACSSA-101. In our experience, at least one full cycle of every recurring process, typically three to six months of records, is what convinces an auditor a process is practiced rather than freshly drafted. Our IEC 62443 documentation guide covers what to write; an IEC 62443 audit checklist tests whether it operates.

Readiness timeline for an IEC 62443 internal audit and ACSSA

These ranges are practitioner estimates for a single mid-sized site, not a published benchmark, and they match the 9 to 15 months we typically see for a full single-site program. Brownfield sites with weak inventories often need longer at the first step.

1. Months 1 to 3, scope and inventory. Define the IACS boundary and SUC, put the inventory and equipment under control list under change control, list service providers and check for excluded cloud functionality.
2. Months 3 to 6, risk assessment. Complete 3-2 from ZCR 1 (identify the SUC) to ZCR 7 (asset owner approval). If you have not measured where you stand, run an IEC 62443 gap analysis first.
3. Months 4 to 12, close gaps and operate. Fix SL-A shortfalls or document compensating countermeasures, and start generating records.
4. Months 10 to 12, internal audit. Run the IEC 62443 audit checklist with someone independent of the process owners, then close findings with evidence.
5. Month 12 onward, external evaluation. Engage an inspection or certification body. Certification bodies typically perform a gap analysis first, so leave room for one more round of fixes.

If your program documents are the gap, the IEC 62443 Toolkit from Governance Docs provides 117 editable templates (82 Word, 35 Excel) in 16 sections, written against IEC 62443-2-1:2024. It includes procedures for SPE 1 to SPE 8, the 3-2 risk assessment and CRS, an SL-T/SL-C/SL-A gap workbook, service provider templates for 2-4 and a Conformance, Maturity and Evidence section that pairs with this IEC 62443 audit checklist. It costs $149 and cannot certify anyone: your team still has to run the processes and keep the records.

IEC 62443 audit checklist FAQs

What is the difference between an IEC 62443 internal audit and an ACSSA evaluation?

An internal audit is run by your own people or a party you appoint, against a scope you choose. An ACSSA evaluation is run by an accredited inspection or certification body against the ACSSA specifications. Treat the internal audit as the rehearsal and ACSSA as the formal result.

Can our own team use this IEC 62443 audit checklist?

Yes, provided nobody audits their own work. ISASecure also describes an internal self-evaluation path for members with qualified staff, but it produces no formal inspection, certificate or official ACSSA conformity claim.

Does the IACS have to be running before an ACSSA evaluation?

It must be in operation or near transition to operation. ACSSA-101 treats a system as operations-ready once commissioning, security program documentation and personnel training are complete. The criteria are the same either way, but the evidence available for some requirements will differ.

How long does an ACSSA certificate last?

Three years. ACSSA-101 describes annual surveillance in the first and second years, then recertification to extend it for another three. An inspection, by contrast, is a one-time evaluation with no validity period.