What it takes to move a zone from SL 2 to SL 3 in ISASecure SSA

A zone certified at SL 2 has cleared 76 of the 116 rows in the ISASecure SSA functional assessment. What SL 3 would cost that zone has a precise answer: a list of 30 rows from IEC 62443-3-3, the same for every zone of every system, two of which the certification lab exercises on the reference system itself. In SSA the capability security level belongs to a security zone, not to the product.

The step in one number

Applicability in the SSA-311 workbook is cumulative: a zone at SL 3 is assessed against every row that applies at SL 1, SL 2 or SL 3. The cumulative set runs 48, 76, 106 and 116 rows across the four levels, so the three steps add 28, 30 and 10.

The middle step is the largest, if only just, and its composition is distinctive: of the 30 rows a zone gains between SL 2 and SL 3, only two are base system requirements, FSA-S-UC-7 and FSA-S-UC-12, corresponding to SR 2.7 and SR 2.12 of IEC 62443-3-3. The other 28 are requirement enhancements.

Where the base requirements run out

IEC 62443-3-3 is built from 51 base system requirements and 49 requirement enhancements. A base requirement introduces a capability; an enhancement asks for a stronger, wider or more automated form of it at a higher level. In the SSA-311 identifier, the number before the dot names the base requirement an enhancement belongs to.

The base requirements enter early. Thirty-seven of the 51 apply at SL 1, twelve more enter at SL 2, and the last two, SR 2.7 and SR 2.12, enter at SL 3. The 16 enumerated items the workbook splits out of four base requirements follow suit: 11 at SL 1, five at SL 2, none later. Once a zone reaches SL 3, every base requirement and enumerated item is in scope for it, and the 10 rows left for SL 4 are all enhancements: FSA-S-IAC-1.3, IAC-7.2, UC-1.4, UC-11.2, UC-12.1, SI-3.2, SI-8.3, SI-9.1, DC-1.2 and RDF-1.3.

The enhancements arrive late and mostly at once: none at SL 1, 11 at SL 2, 39 at SL 3, all 49 at SL 4, so 28 of the 49 enter at this step. Reaching SL 3 is mostly deepening capabilities the zone already needed at SL 2, plus two new ones in use control.

Where the 30 land, by foundational requirement

Use control, 9 added. The biggest slice, and the only one containing base requirements. FSA-S-UC-7 and FSA-S-UC-12 are new capabilities at this level; seven enhancements join them, including those of the split requirements SR 2.3 and SR 2.4. FSA-S-UC-2.1 is on the lab's hands-on list.

Identification and authentication control, 6 added. All enhancements, with FSA-S-IAC-3.1 lab-tested. FSA-S-IAC-5.5 and IAC-9.6 enhance the other two split requirements, SR 1.5 and SR 1.9.

System integrity, 6 added. Enhancements across five base requirements; SR 3.8 contributes two and holds a third for SL 4.

Restricted data flow, 4 added. All enhancements; SR 5.2 contributes two at once.

Resource availability, 3 added. All enhancements.

Data confidentiality and timely response to event, 1 each. FSA-S-DC-2.1 enhances SR 4.2; FSA-S-TRE-1.1 enhances SR 6.1.

The full list

The 30 rows in workbook order. Every dotted identifier here is an enhancement, because all 16 enumerated items are already in scope by SL 2.

Two reading notes. FSA-S-UC-2.1 is classed as an enhancement of SR 2.2 by its position in the workbook, because its source-clause cell is blank. And the workbook's Tree sheet gives FSA-S-SI-4 and FSA-S-RDF-1.3 different levels from its FR sheets, which would put SL 1 at 49 rows, SL 3 at 107 and this step at 31, with FSA-S-RDF-1.3 entering here rather than at SL 4; IEC 62443-3-3 Annex B arbitrates. The counts here follow the FR sheets, the operative evaluation sheets.

The two the lab tests itself

Eleven of the 116 rows carry the workbook's independent-test flag: the certification lab exercises them on the reference system rather than relying on the supplier's test records. SSA-300 requires test-based validations to be run on the reference system; the workbook's independent-test flag is the natural, if unstated, marker of which rows those are. Nine are already in scope at SL 2 (cumulatively 4, 9, 11 and 11 across the levels); FSA-S-IAC-3.1 and FSA-S-UC-2.1 arrive with this step, so from SL 3 upward every lab-tested row applies to the zone.

For the other 28 the certifier works from the supplier's documentation and its own inspection of the system, zone by zone, and records each as S or N/S; N/E is reserved for rows the zone's level does not call for. As an ISASecure certification body, these two rows are where we spend bench time when a zone moves to SL 3. Why the lab's own testing stops at the flagged rows and the scan is explained in the CSA independent-testing article.

The scan threshold moves with the zone

The VIT-S vulnerability scan is run the same way for every IP-addressed component, but its pass threshold is applied per component at the level of the zone the component sits in. For a zone at SL 2, every critical and high finding must be fixed or carry a written justification that it does not apply; at SL 3 the same holds for medium findings. A pass never requires zero findings, but a zone moving to SL 3 loses its tolerance for medium ones. The CSA vulnerability-threshold article walks through the same ratchet for a component.

The lifecycle-artifact review, SDA-S, barely moves: its 74 assessable rows are level-independent except for SDLA-DM-4, whose check is applied to the parts of the system supporting each zone at that zone's level.

One zone at a time

Raising a control zone to SL 3 while an adjacent zone stays at SL 2 means the first is assessed against 106 rows and the second against 76, with the 40 rows the second zone's level does not call for recorded as N/E. The certificate lists each zone with its own level; ISCI's own example is a system with two zones at SL 1 and a safety zone at SL 2.

The applicant names the maximum level wanted for each zone, and the certifier awards each zone the highest level it qualifies for, up to that maximum. A zone that supports all 76 SL 2 rows but not all 30 additions can be awarded SL 2, provided it also qualifies at that level in the other elements of the evaluation, while a neighbouring zone reaches SL 3.

How the climb compares with CSA

ISASecure CSA adds 56 requirements between SL 1 and SL 2, 23 between SL 2 and SL 3 (one base requirement and 22 enhancements) and 6 for SL 4, so a component at SL 2 has most of the climb behind it. SSA adds 28, then 30, then 10: the step ahead of an SL 2 zone is slightly larger than the one behind it, and 10 more rows remain for SL 4. Two structural differences explain the shape. CSA's row set varies with the component type; SSA has no type dimension: every zone faces the same 116 rows and the only variable is the zone's level. And where CSA carries scheme-specific constraints alongside the standard's clauses, SSA's 116 rows add nothing to IEC 62443-3-3: every sourced row traces to one of its 100 clauses. The CSA step row by row is in the CSA SL 3 article.

Planning the step

1. Treat the 30 as a gap list for one zone. Sort each row against that zone's SL 2 implementation: met with headroom, met after a configuration or documentation change, or needs redesign. The third bucket is the schedule.
2. Start with use control. FSA-S-UC-7 and FSA-S-UC-12 have no SL 2 predecessor, so they have the least existing design to build on.
3. Rehearse FSA-S-IAC-3.1 and FSA-S-UC-2.1 on the reference system, where the lab will exercise them.
4. Rerun your own scan of the zone's components with medium findings counted, and fix or justify each one before the lab's scan finds them.
5. Decide zone by zone. A zone that cannot reach SL 3 in time need not hold the others back, and can still be certified at SL 2 if it qualifies there.

The rest of the series is on the SSA filter of the Insights index.