A Holistic View of the Standard ISA/IEC 62443

In this post, I want to put together all the concepts we have been covering so far and look at the ISA/IEC 62443 series from a slightly different angle. The goal is not to introduce new requirements, but to connect the dots and structure the standard in a way that makes sense.

To do that, we will look at IEC 62443 from three complementary views:

• a holistic view of the industrial automation and control system,

• a hierarchical view of the documents and how they relate to each other,

• and a lifecycle view that explains where each part of the standard applies.

The intention is simple: once these three views are clear, the standard becomes much easier to understand and navigate.

A Holistic View: Roles and the Industrial Automation and Control System

Let’s start with the big picture. The standard defines what an Industrial Automation and Control System (IACS) is, and it clearly separates two environments. On the top, we have the industrial facility itself — the factory or plant where the system is installed and operated. Below that, there is another environment that is completely independent from the facility: the place where products are designed and developed by the product supplier.

This distinction is fundamental. The product supplier develops and supports a product. That product can be a single component, such as an embedded device, a hosted device, or a network device, or it can be a combination of several components forming a system. In our usual example, this could be something as concrete as a smart water valve.

This product is then sold to another company. In order for it to be certified against IEC 62443, the supplier must provide not only the product itself, but also the necessary documentation, configuration guidance, and security-related information.

Once the product arrives at the facility, it becomes part of an automation solution. The role responsible for designing and deploying that solution is the integration service provider. After deployment, the solution needs to be operated and maintained over time, which is the responsibility of the maintenance service provider.

At this point, we have a certified product that has been integrated into a real industrial environment. But the standard goes one step further. For this to truly be considered an industrial automation and control system, security policies and procedures must be defined, applied, and maintained. Accountability for those policies sits with the asset owner.

This is how IEC 62443 connects products, systems, and organizational responsibility into a single model.

A Hierarchical View: How the Documents Relate to Each Other

Another useful way to understand the series is to look at the hierarchical relationship between its documents.

IEC 62443 consists of 14 documents, and they are not independent. They build on each other. Everything starts with Part 1-1, which defines terminology, concepts, and models. This is the foundation of the entire series.

From there, Part 2-1 is derived, which focuses on establishing an industrial cybersecurity program. These are high-level requirements related to governance, policies, and organization.

To support those high-level requirements, more specific and technical guidance appears in other parts of the series, from Part 2-3 through Part 4-1. These documents explain how the principles defined earlier can be implemented in practice.

Some documents are especially relevant when working with product certification and system design. For example, Part 3-3 defines system security requirements and security levels. It describes the technical security requirements that systems must meet.

If we go one level deeper and start talking about specific component types — such as embedded devices or network devices — Part 4-2 builds on Part 3-3 and defines more detailed technical requirements at the component level.

This hierarchical structure explains why it rarely makes sense to read or apply a single document in isolation.

A Lifecycle View: Products and Automation Solutions

The last view I want to highlight is the lifecycle perspective.

IEC 62443 clearly describes two different but related lifecycles:

• the product development lifecycle, and

• the automation solution lifecycle.

The product development lifecycle takes place at the product supplier. This is where components and systems are designed, implemented, tested, and maintained over time.

If you are working as a product supplier and your focus is on IEC 62443-4-1, this is usually the point where theory meets reality. Understanding the structure of the standard is necessary, but at some stage you need a documented, repeatable development process that aligns with these requirements. For that reason, I’ve made available a practical IEC 62443-4-1 secure product development lifecycle that can be used as a starting point and adapted to your organization.

The automation solution lifecycle takes place at the facility. It includes integration, operation, and maintenance of the system in a real industrial environment.

Some parts of the standard span across both lifecycles. A good example is Part 3-3. While its primary audience is the product supplier, because security requirements must be embedded into the system design, it also affects the integration phase. Integrators often combine multiple components from different suppliers, and they must ensure that system-level security requirements are still met.

Imagine a facility that already has a SCADA system and later integrates a new component from another supplier. Once these elements are combined, they form an automation solution, and the security requirements defined in Part 3-3 still apply.

This lifecycle view reinforces an important idea: industrial cybersecurity does not stop at product delivery. It continues through integration, operation, and maintenance.

Bringing It All Together

Looking at IEC 62443 through these three views — holistic, hierarchical, and lifecycle — helps to clarify its intent. The series is not a checklist and not a single standard. It is a structured framework designed to connect roles, documents, and lifecycles in a consistent way.

I hope that once this structure is clear, it becomes much easier to understand where each document fits, which parts apply to which role, and how secure products and systems are expected to be designed, deployed, and maintained.