IEC 62443-2-1 Clause 4.2 – Maturity Levels | Automation Engineering Body of Knowledge

ISA/IEC 62443-2-1:2024 Clause 4.2 defines how asset owners score maturity levels (MLs) for Security Program (SP) process requirements. The normative benchmarks sit in Table 1; informative scoring guidance sits in Annex C (Evaluating MLs).

What a maturity level is

Reference: ISA/IEC 62443-2-1, Clause 3.1.7 (definition) and Clause 4.2

A maturity level (ML) is a qualitative characterisation of an organisation’s capability to implement security requirements according to documented policies and procedures, and of its historical performance in doing so.

SP requirements are written to be implementation independent: the standard states outcomes, not a single tool or procedure set. MLs give a shared language for how well process security measures meet each requirement — from early or ad-hoc practice through to measured improvement.

Score MLs per requirement (or per group the asset owner chooses to score together). Shared policies may cover many requirements, but each requirement is still judged on its own.
Choose the target ML using risk-management goals (see ISA/IEC 62443-3-2).
Use MLs to plan a phased SP: raise maturity for specific requirements over time as the organisation gains proficiency.
Related process parts of the series (for example IEC 62443-2-4 and ISA/IEC 62443-4-1) also use maturity levels.

The four maturity levels (Table 1)

Reference: ISA/IEC 62443-2-1, Clause 4.2 and Table 1

The model is based on CMMI for Services (CMMI-SVC), with deliberate IACS adjustments. Part 2-1 defines four maturity levels:

ML	This document	CMMI-SVC relationship	What it means in practice
ML 1	Initial	Initial (aligned)	Work happens case-by-case, often with little or incomplete written how-to. Consistency over time is hard to demonstrate. Here “documented” means a procedure people can follow — not merely a change log that something was altered.
ML 2	Managed	Managed, with a key difference	Written management of how the capability is delivered exists (procedures and/or written training). Part 2-1 deliberately separates “documented” (ML 2) from “proven on this IACS” (ML 3), because plants often write the procedure first and roll it out later. The discipline at ML 2 aims for repeatable behaviour under stress, guided by that written plan.
ML 3	Defined / Practiced	Defined, plus practiced execution	An ML 2 process that is now regularly used on this IACS. Performance can be shown as repeatable over time within that IACS.
ML 4	Improving	Combines Quantitatively Managed and Optimizing	Suitable metrics show the process is effective and/or improving. The SP then tunes technology, procedures or management based on that evidence.

Documentation from ML 2 up: Beginning with ML 2, processes must be documented (policies, procedures and training). SP requirements therefore generally do not restate “must be documented” — that is implied by the maturity claim. For conformance assessment, the asset owner must state whether each requirement is met and, if so, at which ML.

Each level is progressively more advanced than the previous one. Over time, for a given requirement, organisations typically move upward as proficiency grows.

Maturity levels versus Security Levels

Reference: ISA/IEC 62443-2-1, Clause 4.3

Do not confuse MLs with Security Levels (SLs). SLs describe the relative strength of technical security capabilities for Automation Solutions and components (ISA/IEC 62443-3-3 / 4-2). Zone and conduit SL methods live in ISA/IEC 62443-3-2. Part 2-1 uses MLs for organisational process capability; it does not redefine SL methodology.

In practice, owners often use Part 2-1 process requirements together with supplier/service cross-references (Annex A / linked parts 2-4, 3-3, 4-1, 4-2) so product and integration capabilities line up with the organisational programme.

Annex C – Evaluating MLs (informative)

Reference: ISA/IEC 62443-2-1, Annex C

Annex C is guidance for self-assessment and third-party support. It does not change the Clause 4.2 / Table 1 definitions.

C.1 Approach – scope and methodology

Scope follows how the SP is applied. If one IACS SP covers most plants, assess the organisational portion that uses that SP — because maturity asks how well required processes are applied across that footprint. Very large groups may assess separate business units that truly operate independently (for example different companies in different industries); each unit should still treat its whole organisation as in scope rather than chopping the assessment arbitrarily smaller.
Repeatable method. Clause 5 covers formal conformance. Separately, owners can run periodic maturity self-assessments (or engage third parties) to build an improvement roadmap. Because assessments happen again and again, the method should let you compare runs and see overall change.
Aggregation trade-off. Rolling every requirement ML into one plant number can hide truth; listing dozens of individual scores can overwhelm stakeholders. A common compromise: still score each requirement, then roll up to an SPE-level view for decision-makers.
Local language, controlled length. Teams may expand requirements into written questions in plant vernacular. Watch assessment duration and decide whether evidence is required for self-assessment versus third-party work.
Point-in-time / as-is. Score what is implemented now. Projects in flight can be acknowledged, but only currently implemented process and technical measures count for the ML judgment.

C.2 Scoring examples (teaching guidance)

Annex C stresses that ML wording can feel subjective; the examples below help distinguish levels. They are guidance, not redefinitions.

Score signal	Typical teaching interpretation
Not conformant (often scored 0)	No documentation and nobody performing even ad-hoc actions for that requirement. Different from a conscious, risk-based decision not to deploy a particular technology (which still needs justification under Clause 5).
ML 1 – Initial	Some related actions happen, often because people “just know”. New staff would lean on shadowing rather than procedures or formal training. Related technology may exist but be inconsistently applied or poorly documented.
ML 2 – Managed	Policies/procedures (and often training material) exist and can be produced, but consistent execution is not yet proven. Common when documentation is newly written and rollout is incomplete. Procedures may still need tailoring before ML 3.
ML 3 – Defined / Practiced	Documented practices are tailored to the environment and people can show they perform them in operations — including under stress (for example incident response).
ML 4 – Improving	Beyond steady performance: evidence of process improvement, or active cycles that evaluate and update policies/procedures/technology as conditions change — often proactive, using staff and technical feedback to trigger reviews.

IEC 62443-2-1 Clause 4.2 – Maturity Levels