ISO 27001 is a well-understood standard. It is also insufficient for operational technology environments — and not because it is poorly designed, but because it was not designed for them. ISO 27001 is built around information assets: the confidentiality, integrity, and availability of data and the systems that process it. In an industrial control system environment, the primary asset is a physical process — a power generation unit, a chemical reactor, a water treatment facility — and the consequences of a security failure are physical, not informational. IEC 62443 exists because industrial environments needed a security standard that started from that reality.
This article explains what IEC 62443 is, how it is structured, who it applies to, and what an implementation actually involves. It is written for teams investigating the standard before committing to a program — and for those who need to justify that investment internally.
Why IEC 62443 Exists
Industrial control systems were originally designed as isolated, purpose-built systems. A Distributed Control System managing a refinery process ran on proprietary hardware, used proprietary protocols, and had no connection to the outside world. Security was provided by physical isolation, not by software controls.
That model was eroded over decades by legitimate operational pressures: remote monitoring to reduce site visits, integration with enterprise ERP systems for production data, vendor remote access for maintenance, and eventually cloud connectivity for analytics. By the time most organizations recognized the security implications, the isolation assumption was already gone.
The result is an installed base of industrial control systems that were designed without security in mind, are now networked, and cannot simply adopt IT security practices because their operational constraints — no unplanned downtime, no disruptive patching, no software agents on embedded devices — make standard IT controls inapplicable. The full picture of why OT and IT environments face fundamentally different security constraints is worth reading before diving into the standard — these constraints are not organizational failures; they are the engineering reality that IEC 62443 was built to address.
IEC 62443, developed jointly by ISA (the ISA99 committee) and the International Electrotechnical Commission (IEC TC65/WG10), is the only internationally recognized security standard built specifically for Industrial Automation and Control Systems (IACS).[1] It addresses the full ecosystem — the asset owner who operates the facility, the service provider who designs, integrates, and maintains the control system, and the product supplier who manufactures the components. Most other security standards address only one of these actors. IEC 62443 addresses all three, with separate requirements for each role, which is why it has become the primary reference for regulators, insurers, and procurement specifications in industrial sectors.
Structure of the Standard
IEC 62443 is organized in six Groups. The first four were developed by ISA and IEC jointly. Groups 5 and 6 are newer additions that address security profiles and conformity evaluation respectively — and any reference to 62443 that doesn't include them is out of date.[1]
Groups 1 — General
Foundational concepts, terminology, and the overall security model. Part 1-1 defines terms and concepts used across the entire standard. Part 1-3 defines system security conformance metrics. Part 1-4 covers the IACS security lifecycle and use cases. Part 1-5 provides the scheme for creating security profiles for specific industries or use cases (analogous to how NIST CSF uses profiles). Part 1-6 addresses application of 62443 to the Industrial Internet of Things (IIoT). These parts establish the vocabulary and conceptual framework that the rest of the standard builds on.
Groups 2 — Policies and Procedures
Guidance focused on security management programs, primarily for asset owners and service providers. Part 2-1 sets requirements for establishing and sustaining an IACS security program — the foundational document for any asset owner beginning a 62443 journey. Part 2-2 provides a methodology for rating an operational IACS security program. Part 2-3 addresses patch management specifically — a critical operational constraint in OT environments where patching cannot follow IT timelines. Part 2-4 specifies security program requirements for IACS service providers, including system integrators and maintenance contractors. Part 2-5 provides implementation guidance for asset owners operating an existing security program.
Groups 3 — System
Technical requirements for the IACS as an integrated system. Part 3-1 covers applicable security technologies for IACS environments. Part 3-2 defines the risk assessment methodology — how to identify zones and conduits, assess risk, and determine target security levels for each segment. Part 3-3 defines the system-level security requirements mapped to those security levels. Groups 3 drives the bulk of the technical implementation work.
Groups 4 — Component
Requirements for individual products and the organizations that build them. Part 4-1 defines the Secure Development Lifecycle (SDL) requirements for product suppliers — what a manufacturer must do during design and development to build a secure product. Part 4-2 defines the technical security requirements for IACS components at each security level. This group is most relevant to product manufacturers seeking certification, but asset owners use it when specifying procurement requirements for new equipment.
Groups 5 — Security Profiles
This group defines security profiles — curated subsets of 62443 requirements tailored to specific sectors, use cases, or deployment contexts. Profiles allow industries such as nuclear, rail, or building automation to apply 62443 requirements in a way that reflects their specific threat environment and operational constraints without reinterpreting the base standard from scratch. The framework for creating profiles is defined in Part 1-5.
Groups 6 — Evaluation Methods
This group provides the criteria and methodology that auditors and certification bodies use to assess conformity with specific 62443 standards. Part 6-1 covers evaluation methodology for conformity with Part 2-4 (service provider requirements). Part 6-2 covers evaluation methodology for conformity with Part 4-2 (component requirements). Groups 6 is what makes third-party certification rigorous and consistent across accredited assessment bodies.
Who IEC 62443 Applies To
IEC 62443 defines three primary roles, and the applicable parts of the standard differ by role.[1] Understanding which role your organization occupies — or whether it occupies more than one — is the first step in identifying which parts of the standard are relevant.
Asset Owners
An asset owner is the organization accountable for the IACS — the industrial operator who runs the facility and is responsible for the security of the control systems it contains. Asset owners are the primary audience for Groups 2 (security program and patch management) and Groups 3 (risk assessment and system security requirements). The relevant standards for an asset owner are Part 2-1 (establishing the security program), Part 2-3 (patch management), Part 2-4 (requirements to place on service providers), Part 3-2 (risk assessment for the system), and Part 3-3 (security requirements mapped to security levels). These five parts define what a mature asset owner security posture looks like under 62443.
Asset owners span every industrial sector: power generation and distribution, oil and gas, chemical manufacturing, water treatment, food and beverage, pharmaceuticals, and others. Facility size and criticality determine target security levels, but the program structure is the same.
Service Providers
Service providers include system integrators and maintenance contractors — organizations that design, install, configure, commission, or maintain the automation solution on behalf of the asset owner. Integration service providers are the primary audience for Part 2-4 (the security program requirements they must meet to work on IACS systems) and Parts 3-2 and 3-3 (because integration providers often perform the risk assessment and design the system architecture). Maintenance service providers must also meet Part 2-4 requirements for their maintenance activities, including patch management under Part 2-3.
Product Suppliers
A product supplier is any organization that manufactures hardware or software used in an IACS — from PLC and DCS vendors to software application developers. Product suppliers are the primary audience for Groups 4: Part 4-1 (the Secure Development Lifecycle requirements that govern how products are designed and built) and Part 4-2 (the technical security requirements the products themselves must meet at each security level). Asset owners and integration service providers use Groups 4 when specifying and procuring equipment.
What Implementation Involves — The Asset Owner Path
For an asset owner seeking to formally implement IEC 62443, the most useful framing is the one used by the ISASecure ACSSA (Automation and Control System Security Assurance) certification program — the only formal third-party certification program for asset owner IACS security posture. ACSSA evaluates against four specific 62443 parts: 2-1, 2-4, 3-2, and 3-3.[2] Those four parts represent the core of what a structured asset owner implementation looks like in practice.
Step 1 — Establish the security program (Part 2-1)
Before any technical work begins, Part 2-1 requires the asset owner to establish a cybersecurity management system for the IACS. This includes defining the security governance structure, assigning responsibilities, establishing policies and procedures, and developing a security plan that covers the entire IACS lifecycle — from design through decommissioning. Part 2-1 is the organizational foundation. Nothing else holds without it.
Step 2 — Define requirements for service providers (Part 2-4)
Most asset owners rely on third-party contractors for integration, maintenance, and support. Part 2-4 defines what security program requirements those service providers must meet. An asset owner implementing 62443 must assess existing service providers against these requirements and incorporate them into procurement specifications for future contracts. This step is often underestimated — supply chain security failures are a significant source of OT incidents, and Part 2-4 is the mechanism for addressing them contractually and operationally.
Step 3 — Assess risk and design the zone/conduit model (Part 3-2)
Part 3-2 drives the core risk assessment. The asset owner identifies the System Under Consideration (SuC), partitions it into security zones and conduits based on criticality and function, assesses the risk for each zone, and defines a Target Security Level (SL-T) for each. The output is a Cybersecurity Requirements Specification (CRS) that documents the security requirements for the IACS — the authoritative reference for all implementation decisions that follow. This is where ICS-specific operational context matters most: an IT risk assessment methodology does not transfer cleanly to an environment where availability failures have physical consequences and patch windows are measured in months, not days.
Step 4 — Implement controls to meet target security levels (Part 3-3)
Part 3-3 defines the technical security requirements mapped to each security level. Once Target Security Levels are established via Part 3-2, Part 3-3 specifies what controls must be in place. These include requirements across the seven Foundational Requirements (access control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability). Implementation typically involves segmentation projects, authentication upgrades, monitoring deployments, and policy formalization — running in parallel across multiple facility zones.
The total implementation timeline for a mid-complexity industrial facility running all four phases formally is typically two to four years, depending on existing security maturity and the gap between current state and target security levels. Organizations seeking formal ACSSA certification should plan for an additional six to twelve months for the third-party evaluation process.
Relationship to NIST CSF, NIS2, and ISO 27001
IEC 62443 does not exist in isolation. For organizations navigating multiple frameworks, the relationships matter — and the most important thing to understand is that 62443 is a voluntary standard. No regulation makes it mandatory as a standalone requirement.
NIST Cybersecurity Framework (CSF): NIST CSF and IEC 62443 are complementary. CSF organizes security activities into six functions (Govern, Identify, Protect, Detect, Respond, Recover) and serves as a governance overlay applicable across sectors and technologies. IEC 62443 is more technically specific and OT-focused. NIST explicitly references 62443 as an informative reference for the Protect function in IACS contexts, but does not mandate it.[3] US organizations often use CSF as the overarching program structure with IEC 62443 providing the OT-specific technical requirements underneath. IEC 62443 was also developed in consultation with ISO to maintain consistency with the ISO/IEC 27000 series — meaning organizations already following ISO 27001 for IT can extend that governance structure into OT using 62443 without switching frameworks entirely, retaining familiar terms and processes.
NIS2 Directive: NIS2 requires appropriate technical and organizational security measures for networks and information systems in scope.[4] For OT environments, regulators and guidance documents acknowledge IEC 62443 as a recognized approach for demonstrating NIS2 compliance. However, NIS2 is implemented at the national level across EU member states — organizations must comply with their country's specific transposition of the Directive, not NIS2 itself. IEC 62443 alignment is not sufficient on its own to satisfy NIS2 obligations. What it provides is a structured, recognized methodology that makes the technical side of NIS2 compliance easier to demonstrate and document. NIS2 OT cyber risk compliance efforts that are already aligned with IEC 62443 will find the mapping to Article 21 security requirements significantly more tractable than those starting from scratch.[4]
NERC CIP and sector-specific frameworks: In the US, NERC CIP cyber risk management requirements for bulk electric system operators are enforceable — operators must comply or face penalties.[5] NERC CIP does not require IEC 62443, but the frameworks are compatible because cybersecurity is based upon the same fundamental controls & safeguards. Organizations subject to NERC CIP increasingly reference 62443 as a structural guide for the OT security program that sits alongside their CIP compliance activities. Similar patterns apply in other regulated sectors: the sector-specific mandate defines the floor; IEC 62443 provides the engineering methodology to meet it.
Aligning Compliance With Security Investment
The organizations that execute IEC 62443 implementations most effectively treat the standard not as a compliance checkbox but as a structured approach to reducing the actual risk their operations face. The compliance mandate provides the external pressure and the timeline; the risk reduction provides the internal business case.
Translating that business case into financial terms — what is the expected loss reduction from reaching maturity level (ML) 2 versus ML1 in the primary control zone? — requires connecting the standard's security requirements to the financial consequences of the attack scenarios they mitigate. That OT security investment ROI calculation — expressed as expected reduction in cyber risk AEL, VaR, and TVaR for OT environments against the cost of the control program — converts the IEC 62443 implementation from a compliance line item into a defensible capital allocation. Connecting the compliance program to a quantified risk model is what separates organizations that can defend their IEC 62443 investment from those that can only describe it. The DeRISK Platform is built precisely for that connection — mapping control investment to expected loss reduction in financial terms.
Planning your IEC 62443 implementation?
Download the IEC 62443 Compliance Roadmap — a practical guide for asset owners working through the 62443 program structure: security program setup, service provider requirements, risk assessment, and target control implementation.
References
[1] International Society of Automation (ISA), "ISA/IEC 62443 Series of Standards." URL: https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
[2] ISASecure, "ACSSA Certification." URL: https://isasecure.org/acssa-certification
[3] National Institute of Standards and Technology (NIST), "Informative Reference Details — IEC 62443," National Online Informative References (OLIR) Program, CSRC. URL: https://csrc.nist.gov/projects/olir/informative-reference-catalog/details?referenceId=101
[4] European Parliament and Council, "Directive (EU) 2022/2555 (NIS2 Directive), Article 21." URL: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022L2555
[5] North American Electric Reliability Corporation (NERC), "CIP Standards." URL: https://www.nerc.com/standards/reliability-standards/cip