Full or readiness evaluation: the SDLA choice that sets your certificate at 36 or 12 months

Early in an ISASecure SDLA engagement, the supplier and the certification body agree how each requirement will be evaluated. The choice looks procedural. It is the one decision that fixes how long the certificate will be valid: 36 months, or 12.

This article covers the two methods, the 21 workbook rows on which they differ, the validity and extension rules that follow, and a preparation checklist keyed to those rows.

Two methods, agreed per requirement

SDLA certifies a development organisation and a specific, version-controlled version of its secure development process against IEC 62443-4-1. The ISASecure scheme catalogues the standard's eight practices and 47 requirements as 102 assessable rows, and every row applicable to the declared scope of the process must pass; there is no level, grade or percentage. The only per-requirement variable is the evaluation method.

The scheme rules, ISASecure SDLA-300, define two methods. Under a full evaluation the auditor examines the documented process and, on the rows where SDLA-300 makes it mandatory, proof that the process has actually run: artifacts from real products. Under a readiness evaluation the auditor examines the same documented process but, in place of execution artifacts, accepts evidence that the organisation could run the process: trained people, the tooling in place and the templates it will use, even if none of it has yet been applied to a product.

The method is agreed per requirement, not per audit. A supplier can present full evidence for most of the catalogue and readiness evidence for the handful of rows where no product has yet produced the artifact.

One exception: the workbook's Appendix A, 22 legacy configuration-management activities attached to the security-management row SM-1A, is always evaluated as written. The readiness alternative does not apply there.

The 21 rows where the methods diverge

For most of the 102 rows the two methods coincide, because the validation activity does not make an execution artifact mandatory; artifacts may still be examined there, but the readiness alternative changes nothing. They diverge only where SDLA-300 makes an execution artifact mandatory: exactly 21 rows.

The distribution is lopsided. Verification and validation testing holds ten of the 21: test plans and results are the largest single share of what the scheme insists on seeing executed. Security management contributes four, secure implementation three, secure design two, security requirements and defect management one each. Update management and security guidelines contribute none; guideline documents may be examined as artifacts but never must be.

The full list follows; the themes are our own summaries, not the wording of the standard or the workbook.

Ten of the 21 are also minimum requirements, where evidence of inconsistent application is a major nonconformity: SM-3, SM-9, SD-4E, SVV-1A1, SVV-3A1, SVV-3A3, SVV-3C1, SVV-3C2, SVV-3D and DM-3A.

On every testing row the supplier runs the test; the certification body reviews plans and results and never tests a product itself. The CSA testing article sets out that division of labour on the product side.

What one readiness row does to the certificate

If every applicable requirement passes by full evaluation, the certificate runs to the end of the 36th month after grant. If any requirement, even one, passes by readiness, it runs to the end of the 12th month. Validity belongs to the whole certificate: there is no per-practice expiry and no pro-rating for having 20 full rows and one readiness row.

The assessment report makes this visible: its results table records, for every requirement, that it passed and by which method, and conditional wording in the template spells out the shorter validity where readiness was used. Anyone reading the report can see which rows rest on readiness evidence.

The extension clock runs from the original grant

A 12-month certificate is not a dead end. SDLA-300 provides for extending it to 36 months once every requirement that passed by readiness has since passed a full evaluation, meaning the process has run on a real product and produced the missing artifacts.

The date is the detail most often got wrong. The extended certificate expires 36 months after the original grant, not 36 months after the extension. The year on readiness is not added back.

Miss the 12-month expiry and the certification lapses on its date, and there is no reduced-scope route back: the organisation starts again with an initial certification in which every requirement is evaluated again, not just the former readiness rows.

The scheme has no surveillance of any kind, so nothing is scheduled between grant and expiry; a 36-month certificate simply continues through a recertification audit before it expires. The 12-month certificate is the only case with an interim deadline built in.

When readiness is the right call

Readiness exists for a real situation: an organisation that has documented a process meeting IEC 62443-4-1 but has not yet taken a product all the way through it, or has done so for every practice but one activity. A new product line whose first security test campaign is months away is the typical case: readiness lets the organisation certify its process now and prove execution on a product from that line within the year.

Three considerations weigh against it. First, the expiry date is part of the public status information the scheme requires, so the shorter validity is visible. Second, CSA, ICSA and SSA certifications all depend on a valid SDLA certificate, so a 12-month SDLA certificate puts the product certificates' prerequisite on the same 12-month clock: a CSA certificate covers product updates only while the supplier holds SDLA certification, and later ICSA maintenance audits fall at each SDLA recertification. The CSA prerequisite article and the ICSA maintenance-audit article cover the dependencies. Third, the restart rule: if a product slips and the readiness rows cannot be fully evaluated inside the year, the whole certification is redone.

If the readiness rows are few and a product will produce their artifacts comfortably inside twelve months, readiness is a sound bridge. If the gap is wide, waiting for a full evaluation of everything usually costs less than a restart.

Preparation checklist: artifacts to have from at least one product

The supplier lists the products for which execution artifacts exist; the certification body chooses which to examine. To qualify every row for a full evaluation, have the following from at least one product that has been through the process, with product and version identified and each artifact traceable to the process step that produced it.

Security management (SM-3, SM-5, SM-8, SM-9)

• The record showing the process was determined to apply to that product.
• The product's process-scoping decision, including whether and where fuzz and penetration testing were applied.
• Evidence of the private-key controls applied for that product.
• The security requirements imposed on externally sourced components, and evidence they were applied.

Security requirements and secure design (SR-2i, SD-3, SD-4E)

• The threat model for that product, not the organisation's template.
• The security design review record.
• The attack-surface analysis from the design.

Secure implementation (SI-1, SI-1C-1, SI-2)

• Implementation review records against the criteria in the process.
• Static-analysis output for the reviewed code.
• The coding standard in force and evidence it was applied to the product.

Verification and validation (SVV-1A1, SVV-1A3, SVV-2-2, SVV-3A1, SVV-3A3, SVV-3A5, SVV-3C1, SVV-3C2, SVV-3D, SVV-3E)

• The security test plan and the documented results of security requirements testing.
• Abuse-case test results tied to the threat model.
• Fuzz and network-load test plans and results covering the product's data-parsing interfaces.
• The known-vulnerability test plan and the pre-release results.
• Binary composition analysis output and runtime-resource-management test results, where tooling exists for the platform.

Defect management (DM-3A)

• An impact analysis for a security-affecting change to that product.

For any row you intend to pass by readiness

• Readiness evidence, for example training records, the tooling in place and the templates the process will use.
• A dated plan naming the product that will produce the artifact inside the 12 months; that product's delivery date is now the certificate's deadline.

As an ISASecure certification body, we record the agreed method for every requirement before the evaluation starts, so the validity consequence is known up front rather than discovered in the report. The rest of the series is at the SDLA filter on the Insights index.