How ACSSA assesses IEC 62443-2-1 requirements: 89 composite verdicts from four standards

An ACSSA evaluation works through 422 evaluation methods from four IEC 62443 standards, yet the verdicts an asset owner receives sit on 89 requirements, one result each. This article explains which requirements carry the verdicts, what is folded into each, how a verdict fails, and how the scheme keeps the four parts from contradicting one another.

The 89 requirements that carry the verdicts

IEC 62443-2-1:2024 describes the security program an asset owner runs for its installed IACS. It holds 87 requirements, as ACSSA-303 states, and the ACSSA-311 v1.3 evaluation workbook (February 2026) evaluates every one of them across the standard's eight security-program elements. The spread is uneven: user access control alone accounts for 23 and network and communications security for 15, while configuration management contributes 4.

ACSSA adds two requirements of its own. Two capabilities in IEC 62443-3-3, system-use notification and mobile-code control, have no requirement in 62443-2-1 that says how an owner's policies should govern them, so the scheme defines a support requirement for each: SR 1.12 Policy and Procedure Support for the first, SR 2.4 Policy and Procedure Support for the second. Both are evaluated under the same conditions as a 2-1 requirement. 87 plus 2 is 89, and ACSSA-303 treats those 89 as the complete set of verdicts an evaluation produces.

What the other three parts contribute

The remaining three standards are not evaluated for their own sake. IEC 62443-2-4 is applied to each service provider, but only for the tasks it performs on this IACS. IEC 62443-3-2 is applied to the asset owner's own risk assessment. IEC 62443-3-3 is applied to each sampled zone and device-bearing conduit, checking that the capabilities appropriate to the zone's target security level are configured and used. Each of their requirements receives its own result, recorded in the report, but not a verdict of its own: ACSSA-300 treats each as associated with one or more of the 89, and the associated composite is what passes or fails.

The workbook's 349 requirement items split as 89 security-program items, 123 service-provider items, 33 risk-assessment items and 104 system-capability items. Because some requirements carry one method per security level and a few are split into sub-clause children, the 349 items become 422 methods: 153, 123, 33 and 113 per part. Set aside the workbook's three grouping headers, rows that only point to their children, and 152 methods sit on the verdict side against 267 on the input side: 123 service-provider, 33 risk-assessment and 111 system-capability methods, figures derived from the workbook.

ACSSA-300's decision rule draws the consequence: it is sufficient for certification that all 89 composites pass at maturity level 3.

Anatomy of a composite

ACSSA-300 looks at each 2-1 requirement from three angles: the asset owner's own policies and procedures, the support its service providers give, and the way the associated technical capabilities are used in practice. The three are refined into five sub-aspects. Maturity level 2 covers the first two, maturity level 3 all five, so the composite at each level is built from different inputs.

The composite is a recorded result of its own, but ACSSA-300 ties it to the whole validation activity: the evaluator records a result on the owner's process aspect and on every associated requirement, and the composite cannot pass while any of them is Not met. Because level 2 asks whether the requirement is documented and level 3 whether it is practised, with the evaluator determining the level reached, a composite that passes at level 2 but not at level 3 locates the gap in how the program is executed rather than in how it is written down.

One requirement, several security levels

A security-program requirement inherits the security levels of the capabilities associated with it, and where those span several levels it carries one evaluation method per level. ACSSA-300's own example is USER 1.8, with four methods: one at each of two security levels, at each of the two maturity levels. The workbook counts these as two rows, one per security level, each carrying its level-2 and level-3 activities, which is the basis of the 422 figure above. AVAIL 2.1 carries methods at security levels 1 and 3 only.

A requirement therefore passes at a maturity level only when its methods at every applicable security level yield a passing result on every part of the IACS, zone or device-bearing conduit they were scored against. Where a level does not apply, the evaluator records a not-required result for the target security level, NR-S, rather than skipping the method: judged at level 2 against the target security levels present in the part of the IACS examined, at level 3 against the zone or conduit's own. That target level is an input from the owner's IEC 62443-3-2 risk assessment; ACSSA reads it and never awards one. For the contrast with SSA, which certifies a system product at a capability level, see the SSA article on capability security levels.

The nine requirements ACSSA-300's Table 1 scores once for the whole IACS

At maturity level 3 most security-program requirements are scored per sampled zone or device-bearing conduit. ACSSA-300's Table 1 names nine that instead receive a single result for the whole IACS: the organisational requirements ORG 1.1, ORG 1.2, ORG 1.3, ORG 1.4 and ORG 1.5, the security-program review requirement ORG 2.4, and the network requirements NET 1.1, NET 1.2 and NET 1.3. Each of Table 1's nine carries a single security-level-1 method, and each concerns the program as a whole rather than any one zone.

ORG 2.1: where the risk assessment enters

The 33 risk-assessment items of IEC 62443-3-2 need a security-program requirement to attach to, and ACSSA-300 associates all of them with ORG 2.1; a handful also associate with NET 1.1 to NET 1.6 and COMP 1.2. ORG 2.1 is therefore the composite through which the quality of the owner's risk assessment reaches the verdict table. The sample report in ACSSA-303 evaluates it on three criteria: conformity of the risk assessment to 62443-3-2, service-provider support through SP.02.01 and SP.03.01 with its two enhancements, and the owner's execution and management of the resulting mitigations. A risk assessment can be a conformant document at level 2 and still fall short at level 3 if its mitigations are not carried through.

Only Not met fails

ACSSA records ten result types and only one, Not met (NM), is a failure. Met (M) passes, and so do the not-required results NR-A, NR-TI, NR-TZ and NR-S: a task not delegated to the provider, a technology not in use in the part or zone examined, a capability above the zone's target level. Three special circumstances, NR-R (a documented risk justification), CSM (a compensating security measure) and NF (not feasible or not permitted by law), pass only with documentation approved by the asset owner and every affected stakeholder. VIC, verified by independent certification, exists only for service-provider requirements at maturity level 2, and un-sampled entities receive no result.

For a composite this reduces to one rule: inputs that are anything other than Not met leave it eligible to pass, and one Not met anywhere among them makes it fail. A Not met is also, by definition, a nonconformity, whichever part it arises in. The report presents the composites in its results-by-requirement table, Table 12, the first place an asset owner should look; the individual inputs appear in the sections organised by responsibility area, from the owner's risk-assessment process and the hardware and software through each zone and conduit to each service provider.

Ten conditions that keep the parts honest

Folding four standards into one verdict creates room for contradiction, so ACSSA-300 requires the complete result set to satisfy ten consistency conditions before a decision is taken.

These are checks, not shortcuts: an evaluator may not use them to derive a result, except for the conditions linking the two maturity levels of the same requirement. Each part is evaluated on its own evidence, so a later result can confirm or contradict an earlier one.

What the sample report shows

ACSSA-303 illustrates the structure on a fictional small terminal facility with one system under consideration, three zones, three conduits and three service providers. Of its 89 composites, 75 pass. The figure is sample-specific, not a typical outcome. Under the certification scheme, run by ISO/IEC 17065 certification bodies, all 89 must pass at maturity level 3, and as an ISASecure certification body Perseus applies that rule when it decides. The sample itself is an inspection report; ACSSA's parallel inspection scheme attests conformity requirement by requirement without an overall pass.

Where to go next

The rest of the series is on the ACSSA filter of the Insights index. For the difference between certifying an installed IACS and a system as its supplier sells it, see the SSA article on systems as sold.