IEC 62443-4-1 process audit: the 23 SDLA rows no product evaluation examines

Two opinions about the ISASecure SDLA process audit circulate among suppliers, and they contradict each other. The first is that SDLA is paperwork: the auditor reads the lifecycle manual, ticks 102 boxes and leaves. The second is that the process audit is redundant, because the CSA or ICSA evaluation of each product goes over the same IEC 62443-4-1 ground. Both are wrong, and the evidence sits in the structure of the evaluation workbook.

What follows: how SDLA-312 splits each row, which 23 rows no product evaluation re-checks on Perseus's reading of its activity columns, how the three views of the catalogue compare, and what that means for your evidence.

One catalogue, two validation columns

ISASecure SDLA-312 catalogues the 47 IEC 62443-4-1 requirements as 102 assessable rows across the standard's eight practices. Each row has two validation columns, not one. One column describes how the SDLA auditor evaluates the row at process level: does the documented lifecycle cover it and, for a full evaluation, do execution artifacts show it being followed. The other describes how the same row is checked for an individual product in a product certification's development-artifact stream: SDA-C in CSA, SDA-IC in ICSA, SDA-S in SSA.

Not every row has both. On Perseus's reading of the SDLA-312 activity columns, the 102 SDLA rows split four ways:

That gives 96 rows with a process-level activity: the audit is a wide examination of the lifecycle, not a formality laid over the product reviews. The one row with no activity on either side, SM-1F, is a placeholder and is left out below.

Myth 1: SDLA is all paperwork

The 23 rows that have a process-level activity and no product-level one are the strongest reply to this myth, because they describe things an organisation does rather than documents a product ships with.

Grouped by practice, in our own words:

The defect-management block stands out. Nine of the practice's ten rows are here; the exception is DM-4, addressing security-related issues, which is also the one SDLA row whose validation depends on the product's capability security level. Everything else about how a supplier receives, triages, analyses and discloses vulnerabilities is examined by the SDLA auditor and not in any product certification's artifact review (the ICSA maintenance audit later revisits DM-1 and SUM-5); a product certification takes it on trust from the SDLA certificate.

Secure implementation follows the same pattern. Six of its 13 rows concern what the coding standard says and how far the static-analysis tooling reaches into it; that content is checked once, in the process audit. The per-product review checks only that code review and static analysis happened for that product, which is why the practice drops from 13 rows in the SDLA audit to 6 in a CSA evaluation.

Then the two verification rows. Penetration testing, SVV-4, and the independence of the people who test, SVV-5, carry a process-level activity and nothing on the product side: a CSA evaluation runs its own vulnerability scan and hands-on tests of flagged functional requirements, but the supplier's penetration-testing regime is examined in the SDLA audit alone. The CSA testing article walks through where each kind of test lives.

None of this is paperwork in the dismissive sense: the auditor looks for a reporting channel that exists and is reachable, a tracking system with issues in it, a coding standard with real content, and penetration-test results that were acted on.

Myth 2: the product certification goes over the same ground

The second myth fails on the arithmetic. A product certification does not re-examine the process; it re-checks, for one product, the rows that leave a product-specific artifact behind. Read that way, the same catalogue produces three views.

The left column is the SDLA audit: 102 rows. The middle column is what a CSA evaluation re-checks for a specific component: 77 of them. The right column, ICSA at 93, needs one explanation. ICSA counts against the combined SDLA-312 and ISDLA-312 workbook, which adds 16 IIoT-only rows to the 102. Those 16 belong to ICSA product certification and are not required for an SDLA certificate, which is why the ICSA column exceeds the SDLA column in security requirements (19 against 13), secure design (7 against 5) and security guidelines (19 against 17), and why defect management (DM-4 plus four IIoT rows) and update management (two CSA rows plus two IIoT rows) sit between the CSA and SDLA counts. Strip the 16 out and the ICSA view is the CSA view: 77 rows. The ICSA lifecycle-artifacts article covers the IIoT rows.

What a product certification re-checks shows where the product-side evidence effort goes:

• Security guidelines: all 17 rows. Examined in the process audit and read again for every product, because each product ships its own guidance, so there is a product-specific artifact to read.
• Verification and validation: 18 of 20 rows. Everything except penetration testing and tester independence: test plans, abuse-case results, fuzz and network-load coverage, known-vulnerability results.
• Security requirements and secure design: every row. The threat model, the requirements traced to it and the design that answers them exist per product.
• Security management 15 of 19, secure implementation 6 of 13. The rows that leave a per-project record.
• Defect and update management: 1 and 2. DM-4, and the two update rows about documenting and delivering an update. No product evaluation re-checks the other 12 rows in those practices.

Five rows go the other way, with a product-level activity only, among them two of the SVV-3A1 to 3A5 fuzz and network-load rows (SVV-3A2, SVV-3A4), whose Appendix B artifact-quality criteria are product-side only, and the certifier's option to witness supplier-run vulnerability tests (SVV-3).

Why the product schemes lean on SDLA

The ISASecure product programs treat the development process as a single evaluation element, SDLPA, which an SDLA certificate satisfies for CSA, SSA and ICSA; the CSA prerequisite article explains the gate from the product side. The 23 rows are the operational content of that arrangement: the part of IEC 62443-4-1 a product evaluation does not examine because someone already has.

Two consequences follow. An organisation's vulnerability-handling and update-delivery machinery is inspected in the SDLA audit and not when a product is certified, so a weak intake process or a slow update pipeline surfaces there. And the product schemes come back to these practices when they maintain a certificate: the ICSA security maintenance audit re-examines DM-1, DM-2, DM-4 and SUM-5, with later audits falling at each SDLA recertification.

What this changes about preparing evidence

Two SDLA-300 overlays cut across the 23 rows. Six are minimum requirements: DM-1A, DM-3, DM-3A, DM-3D, DM-5 and SUM-1. For those, evidence that the row is not consistently applied is a major nonconformity, so a reporting channel that is documented but not reachable from the supplier's public site, or a triage step skipped under schedule pressure, is a serious finding. Only one of the 23, DM-3A, is among the 21 rows where proof of execution is mandatory for a full evaluation; for the other 22 a full and a readiness evaluation ask for the same thing, so the choice of method does not soften them.

Evidence for the audit-only rows is organisational rather than product-bound:

• The vulnerability intake, live. The public reporting route as a customer would find it, the tracking system with real issues in it, and records showing triage, criticality rating, related-version analysis and root-cause work on closed issues.
• Disclosure and review records. How and when issues were disclosed, and the output of the periodic review of the mechanism itself.
• The coding standard as a document. What it prohibits and what it requires, its revision history, and the configuration of the static-analysis tooling against it.
• Penetration-test process and results, with the issues they raised and where those went, plus the rule that sets tester independence by test type.
• Update qualification and delivery records, including how third-party and operating-system updates are handled.
• Records under the three security-management rows, SM-1B-1 (a sub-row of SM-1), SM-7, SM-13.

As an ISASecure certification body, Perseus examines these rows in the SDLA audit and not again in any product certification's artifact review, so this is the occasion to have them ready. The SDLA series index has the rest of the series, and the CSA index and ICSA index cover the product side.