IEC 62443 Documentation: The Complete 2026 Asset Owner Guide

IEC 62443 documentation is the set of policies, procedures, registers, specifications and records an asset owner uses to show that its industrial automation and control system (IACS) security program is defined and actually running. The series does not hand you a numbered list of mandatory documents. You derive them from the requirements in parts 2-1, 2-4, 3-2 and 3-3, and from what an assessor expects to see.

In practice, the core set looks similar from site to site: a cybersecurity policy and program charter, roles and responsibilities, an asset inventory, architecture diagrams, a zone and conduit register, the 3-2 risk assessment report, a cybersecurity requirements specification (CRS), a target security level register, procedures for the eight security program elements (SPEs) in IEC 62443-2-1:2024, service provider requirements, and records that prove each process operates.

This guide organizes those IEC 62443 documents by part and by SPE, with a typical owner and review trigger for each. The evidence an assessor samples is covered separately in our IEC 62443 audit checklist.

Why IEC 62443 Documentation Has No Mandatory List

ISO/IEC 27001 calls out specific documented information across its clauses, so consultants can build a tidy mandatory list. IEC 62443 works differently. Most parts set requirements for a role (asset owner, service provider or product supplier) and largely leave the form of evidence to you. If the role split is new to you, start with IEC 62443 parts explained.

Some requirements are plainly about documentation. IEC 62443-3-2 has a step (ZCR 6) for documenting cyber security requirements, assumptions and constraints, and the IEC 62443-2-1:2024 publication page describes that standard as policy and procedure requirements for the asset owner’s security program. Most other requirements describe an activity: you need a procedure that defines it and a record that shows it happened.

• There is no official document count. A template count describes a product, not the standard.
• Assessors work back from requirements. The ISASecure ACSSA scheme assesses an operating IACS against 2-1, 2-4, 3-2 and 3-3, so if you pursue it, your IEC 62443 documentation needs coverage across all four parts.
• Exceptions must be written down. The 2-1:2024 abstract recognizes that legacy systems may meet only a subset of requirements, with policies and procedures covering the gaps. Undocumented compensating measures read as gaps.

Documents vs Records: Defined Versus Operating

Every item in your IEC 62443 documentation falls into one of two kinds.

• Documents show a process is defined: policies, procedures, standards, specifications and plans. They are controlled, with an owner, version, approval and review date.
• Records show the process operates: change tickets, signed access reviews, restore test results, incident tickets, training logs and approved risk assessments. Records are retained, not revised.

Registers sit in between. The asset inventory and zone and conduit register are living documents, but each dated, approved snapshot is a record. Keep the current version for operations and the baselines for the audit trail.

The split matters more under the 2024 edition of 2-1, which defines a maturity model for evaluating requirements. In our experience, a well-written procedure with no records behind it rates poorly, because assessors want to see a process practiced repeatedly, not just described.

Core IEC 62443 Documentation by Part

Program documents from IEC 62443-2-1

These set the frame for everything else and, in our mapping, mostly sit under SPE 1, organizational security measures.

• Cybersecurity policy for the IACS environment, approved by senior management.
• Security program charter covering scope, objectives, authority and reporting lines.
• Roles and responsibilities, ideally a RACI naming OT, IT, engineering, operations and service provider roles.
• Training and competence requirements for anyone who operates, maintains or connects to the IACS.

System documents from IEC 62443-3-2 and 3-3

• System under consideration (SUC) description and asset inventory, supporting ZCR 1.
• Network and architecture diagrams showing as-built data flows, not the design-intent drawing.
• Zone and conduit register with drawings and characteristics for each zone and conduit (ZCR 3 and ZCR 6). See our guide to IEC 62443 zones and conduits.
• Risk assessment report covering the initial assessment (ZCR 2), risk comparison (ZCR 4), detailed assessment (ZCR 5) and asset owner approval (ZCR 7).
• Cybersecurity requirements specification (ZCR 6.1), with the other ZCR 6 content such as threat environment and tolerable risk.
• Target security level register recording SL-T per zone and conduit, SL-C of installed systems against the 51 system requirements in IEC 62443-3-3, and SL-A once verified.

Procedures for Each SPE in IEC 62443-2-1:2024

The eight SPEs give the procedure layer of your IEC 62443 documentation a natural structure. The procedures below are typical of mature programs; the standard sets requirements rather than naming documents, so structure procedures to suit your organization.

1. SPE 1 Organizational security measures: program management, personnel security, training and awareness, periodic security reviews.
2. SPE 2 Configuration management: inventory maintenance, baseline configurations, change management with security impact assessment.
3. SPE 3 Network and communications security: segmentation, firewall and conduit rule review, remote access, wireless.
4. SPE 4 Component security: hardening, malware protection, patch management (IEC TR 62443-2-3 is useful input), removable media.
5. SPE 5 Protection of data: classification of IACS data such as recipes, setpoints and configuration files, encryption, secure disposal.
6. SPE 6 User access control: account lifecycle, privileged and shared accounts, default credentials, access reviews.
7. SPE 7 Event and incident management: logging and monitoring, an OT incident response plan, reporting.
8. SPE 8 System integrity and availability: backup and restore, recovery, continuity for the IACS.

Keep procedures short. A two-page procedure a shift engineer follows beats a 30-page document nobody opens.

IEC 62443 Documentation Map: Owners and Review Triggers

The mapping below is practical, not normative, and one document often supports several SPEs.

Document	IEC 62443 part / SPE	Typical owner	Review trigger
Cybersecurity policy	2-1, SPE 1	CISO or OT security lead	Annual; major organizational or regulatory change
Security program charter	2-1, SPE 1	Operations or plant director	New site, acquisition or SUC change
Roles and responsibilities (RACI)	2-1, SPE 1	OT security lead with HR	Reorganization; key staff turnover
Asset inventory	3-2 ZCR 1; SPE 2	Control systems engineering	Every approved change; periodic reconciliation
Network and architecture diagrams	3-2 ZCR 1 and 6; SPE 3	OT network engineer	Any network change; annual walkdown
Zone and conduit register	3-2 ZCR 3 and 6	OT security architect	New connection, zone or conduit
Risk assessment report	3-2 ZCR 2, 4, 5 and 7	Risk owner with OT security	Significant change, incident or new threat intelligence
Cybersecurity requirements specification	3-2 ZCR 6.1	OT security architect; asset owner approves	Change to zones, SL-T or tolerable risk
Target SL register (SL-T, SL-C, SL-A)	3-2 and 3-3	OT security architect	Risk reassessment; system replacement
Change and configuration procedure	SPE 2	OT engineering manager	Annual; unauthorized change
Segmentation and remote access procedures	SPE 3	OT network engineer	New remote vendor; annual
Hardening, malware and patch procedures	SPE 4	Control systems engineer	Relevant vendor advisory; annual
IACS data protection procedure	SPE 5	OT security lead	New data flow to IT or cloud
Access control procedure	SPE 6	OT security lead with system owners	Access review findings; new system
OT incident response plan	SPE 7	OT security lead with operations	After each incident or exercise
Backup, recovery and continuity procedures	SPE 8	Control systems engineering	Failed restore test; major system change
Service provider security requirements	2-4 (applied by asset owner)	Procurement with OT security	New contract, renewal or provider change
Records index	All SPEs	Document controller	Before each assessment; procedure change

Service Provider Requirements Under IEC 62443-2-4

IEC 62443-2-4:2023 sets security program requirements for IACS service providers such as integrators and maintenance contractors. Unless your own engineering team acts as integrator or maintainer, you use 2-4 to specify what providers must do and to evaluate them.

• Service provider security requirements listing the 2-4 capabilities you expect, scaled to the risk of each service.
• Contract clauses covering remote access, credentials, patch and malware handling, incident notification and return of data.
• Provider evaluation records, including any maturity rating. 2-4 uses maturity levels from ML1 (Initial) to ML4 (Improving).
• Component procurement requirements referencing IEC 62443-4-2 and the SL-C you need.

Reference the edition you mean in contracts. The IEC edition is IEC 62443-2-4:2023, while the US version listed on the ISA/IEC 62443 series page is still ANSI/ISA-62443-2-4-2018.

Records That Prove the Program Operates

Records are where most IEC 62443 documentation sets fall short. As you write each procedure, ask how you would prove it ran.

• Approved risk assessment and CRS sign-off (ZCR 7)
• Training and awareness completion logs
• Change tickets with security impact assessment
• Firewall and conduit rule review records
• Patch evaluation decisions, including reasons for deferral
• Access review sign-offs and leaver tickets
• Incident tickets, exercise reports and lessons learned
• Backup restore test results
• Provider evaluations and remote access session logs

Set retention for each record type in your document control procedure, aligned with your regulatory, contractual and insurance obligations.

How to Build the Document Set in the Right Order

Writing procedures before you know your zones is the sequencing mistake we see most often. Build the IEC 62443 documentation in dependency order:

1. Scope: charter and SUC definition.
2. Know what you have: asset inventory and as-built diagrams.
3. Draw the boundaries: zones and conduits, then the 3-2 risk assessment.
4. Specify: CRS and SL-T register, then the SL-C gap against 3-3.
5. Operate: SPE procedures written around how the plant actually works.
6. Extend to providers: 2-4 requirements and contract clauses.
7. Prove it: a records index showing the record each procedure produces and where it lives.

Put every document under control from day one: owner, version, approval and next review date. One register of IEC 62443 documents with those four fields answers the first question most assessors ask.

If you would rather start from structured drafts than blank pages, the IEC 62443 Toolkit ($149) provides 117 editable templates (82 Word, 35 Excel) in 16 sections, written against IEC 62443-2-1:2024. It covers program and governance, asset inventory, zones and conduits, the 3-2 risk assessment and CRS, an SL-T/SL-C/SL-A gap workbook, procedures for SPE 1 to 8, service provider requirements, and conformance, maturity and evidence tracking. It is built for asset owners and service providers, not product suppliers pursuing 4-1. It cannot certify anyone: your team still runs the processes and keeps the records.

IEC 62443 Documentation FAQs

Does IEC 62443 have a list of mandatory documents?

No. The series does not publish a consolidated list of required documents. Your IEC 62443 documentation is derived from the requirements in 2-1, 2-4, 3-2 and 3-3, and a few steps, such as documenting the CRS under 3-2, are explicitly documentation steps.

Can we reuse ISO 27001 documents for IEC 62443?

Often, for the generic parts. Edition 2.0 of IEC 62443-2-1 removed duplication with an information security management system, so in our experience enterprise governance, HR security and supplier processes can be referenced rather than rewritten. The zone and conduit register, risk assessment, CRS and IACS procedures still need to be written for the plant.

Do IEC 62443 policy templates make us compliant or certified?

No. IEC 62443 policy templates give you the documented layer and save drafting time, but conformance depends on operating the processes and keeping records. Certification is voluntary; for an operating IACS, the ISASecure ACSSA scheme assesses against 2-1, 2-4, 3-2 and 3-3.

How often should IEC 62443 documentation be reviewed?

Use event triggers and a periodic cycle together. Changes to the network, zones, threat environment or service providers should trigger an immediate review of the affected documents, and a yearly review of everything else is common practice. Record each review, because the review itself is evidence.