What counts as a major nonconformity in an IEC 62443-4-1 audit: the 31 SDLA minimum requirements

Ask what a major nonconformity is in an IEC 62443-4-1 audit and most people reach for the management-system instinct: a systemic failure is major, an isolated slip is minor, and the auditor's judgement fills in the rest. In the ISASecure SDLA scheme that instinct is only half right. The definition is written down, it has two limbs, and the second limb depends on a list of 31 rows that most suppliers have never seen as a list.

This article gives the two definitions in plain terms, the 31 rows by identifier and practice, their overlap with the separate list of rows that require proof of execution, and where in the lifecycle the classification actually changes an outcome.

Major, minor, and the word that separates them

ISASecure SDLA-300, the certification and maintenance requirements for the scheme, defines the two classes in terms of evidence rather than severity of consequence. In our own words:

• A nonconformity is major in two situations. The first applies to any requirement: the auditor finds nothing showing the requirement is being met at all. The second applies only to a requirement on the minimum-requirements list: evidence exists, and it shows the requirement being met in some places, but not consistently.
• A nonconformity is minor when a requirement is not met and neither of those conditions applies.

Notice what the second limb does. For a row outside the list, a process followed on some products and skipped on others is a genuine gap, but a minor one. For the 31 rows on the list, the same pattern is major. "Consistently" is the operative word: the list does not raise the bar on what a requirement asks for, it removes the tolerance for partial adoption.

The audit can see consistency because it looks past the written process: the certifier may examine execution artifacts from products under the SDL, chosen from the supplier's list of products with artifacts, and on the 21 mandatory-artifact rows a full evaluation must. A minimum requirement visible in the flagship product's records and nowhere else is exactly the case the second limb was written for.

For an initial certification the classification changes nothing about the result: SDLA-300 grants the certificate only when every row applicable to the declared scope has been assessed as passing, and the scheme has no partial grade and no level of any kind, so an open nonconformity of either class stands between the process and the certificate. The distinction earns its keep at recertification, covered at the end.

31 rows from 22 list entries

The minimum requirements live in an appendix to SDLA-300, not in the workbook, and the appendix names 22 entries. Three cover more than one assessable row: the known-vulnerability testing entry names two rows, the defence-in-depth guidance entry names three, and the hardening-guidelines entry covers every part of SG-3, which in the current workbook is seven rows (3A, 3B, 3C, 3D, 3E, 3G and 3H; there is no 3F). Resolved against SDLA-312 v6.4, the 22 entries become 31 rows.

Two practices stand out. Security guidelines holds ten of the 31, more than any other practice, even though it has no rows on the other SDLA-300 list discussed below. Secure implementation, the coding-standard and code-review practice, has none.

The full list

Every minimum-requirement row, its practice, what it is about in our own words, and whether it is also one of the 21 rows for which SDLA-300 makes execution artifacts mandatory in a full evaluation.

Two rows need a note. SVV-3A1 and SVV-3A3 sit in the group SVV-3A1 to SVV-3A5, which together cover the planning, artifact quality and results of fuzz and network-load testing; plan against the group rather than any single row. And SM-3, the row about deciding which products the process applies to, is itself a minimum requirement: an applicability decision made for some product lines and not others is major before any other row is examined.

Reading the list by practice

Security guidelines, ten. The three SG-1 rows are the product's defence-in-depth guidance and the seven SG-3 rows its hardening guidance. These are the documents an asset owner actually receives, so it is unsurprising that the scheme gives no tolerance to a supplier that writes them for some products and not others. No SG row is a mandatory execution artifact, so on this practice the pressure is entirely on consistency.

Verification and validation testing, eight. Testing is the practice SDLA is strictest about on both lists: eight of the 31 minimum requirements and ten of the 21 mandatory artifacts. Penetration testing (SVV-4) and tester independence (SVV-5) are on neither.

Defect management, five. The working parts of vulnerability handling. On Perseus's reading of the SDLA-312 activity columns, nine of the ten defect-management rows are examined only in the SDLA audit, never in a product certification, so this is the one place these five are checked.

The rest. Security management contributes applicability, expertise, file integrity and externally sourced components; security requirements the threat model and the product's security requirements; secure by design attack-surface reduction; update management the qualification of updates. Secure implementation contributes nothing, although three of its rows are mandatory artifacts.

The ten-row hard core

SDLA-300 carries two lists that overlay the 102 rows, and they do different jobs. The 21 mandatory-execution-artifact rows are the only rows on which a full evaluation and a readiness evaluation differ, and so the list that decides whether a certificate is issued for 36 months or 12. The 31 minimum-requirement rows decide whether a nonconformity is major.

Ten rows appear on both: SM-3, SM-9, SD-4E, SVV-1A1, SVV-3A1, SVV-3A3, SVV-3C1, SVV-3C2, SVV-3D and DM-3A. On those ten the scheme asks for the most it ever asks: a full evaluation cannot pass without artifacts proving the activity was carried out, and once those artifacts are on the table, any inconsistency across them is major. Six of the ten are testing rows. This is the hard core of SDLA.

The two lists are not nested. Security guidelines has ten minimum requirements and no mandatory artifacts; secure implementation has three mandatory artifacts and no minimum requirements. Treat them as two independent flags a row may carry.

Where the classification does its work

The split becomes decisive at recertification. The scheme has no surveillance audits; a 36-month certificate is kept by a recertification audit before it expires, and SDLA-300's Table 1 gives three outcomes for that audit.

• No nonconformities. The certificate is extended for a further 36 months from its previous expiry.
• Minor nonconformities only. The certificate is extended provided none of them has been carried open since the previous recertification, and they are checked again at the next one.
• Any major nonconformity. The root cause must be corrected in the process and in the organization's internal audit function, and at least one instance of the corrected process verified in execution. The extension is granted only if that is done before the expiry date and no minor nonconformity has stayed open since the previous recertification; otherwise the certificate expires on its date.

A major finding at recertification is therefore one of the ways a running SDLA certificate can end on its own date rather than being renewed; the lifecycle article in this series covers the rest.

Preparing against the list

Three practical consequences follow.

1. Prepare evidence across the declared scope, not for the flagship. For each of the 31 rows, be able to show the activity applied to every product line the process covers. A polished example from one product is the pattern the second limb catches.
2. Treat the ten hard-core rows as artifact rows. A full evaluation on them needs proof of execution from at least one product, and that proof needs to agree with what the other products show.
3. Do not read the list as a level. Nothing in the scheme grades a process; the list only changes how a shortfall is classified. A row outside it still has to pass.

As an ISASecure certification body, we classify each nonconformity against the two SDLA-300 definitions, and the minimum-requirements list is what decides which limb applies.

Where to go next

The earlier articles in this series cover the two evaluation methods and the 36-month or 12-month consequence; the SDLA filter of the Insights index lists the whole set. For how an SDLA certificate feeds the product schemes, see why SDLA is the prerequisite for CSA and what SDA-C then checks.