How it is created — SDL-REC-002 Internal SDL Conformity Review

1. What this replaces

Without an ISO 27001 or IEC 62443-4-1 certificate, nobody external has attested that your process works. This record is how you demonstrate it yourself: a sampled audit of your own releases against your own policy, with findings, corrective actions, and a management signature.

It is deliberately an internal audit. The value is in finding something. A review that reports full conformity every year reads as a review that was not performed.

2. Inputs

• The SDL policy revision that was in force during the period.
• The list of all CRA-relevant releases in the period, with their conformity dossiers.
• Merge-request history, CI reports, release gate records, and the vulnerability process log.

3. Steps

1. Fix the period and the sample. For a small manufacturer, sampling all CRA-relevant releases is usually feasible and far easier to defend than a partial sample. List them in a table with product, release type and dossier ID.
2. Check phase by phase, in the order of the policy. Requirements and threat modelling, implementation controls, verification, release gate, vulnerability management. Per area, state what was examined — "a sample of 20 merge requests across three releases" — before stating the verdict.
3. Record verdicts as "conform" or as a finding, with an ID. Distinguish a documentation gap from a technical gap and say which it is; the example's finding is a missing waiver for a legitimately skipped activity, which is a documentation gap and should be labelled as such.
4. Separate findings from observations. Findings require corrective action with an owner and a due date. Observations are improvements that do not indicate a breach of the process.
5. Close the loop in the table itself — corrective action, owner, due date, and status when the record is signed.
6. Write a conclusion that says something. Whether the process is assessed as implemented and effective, and with which limitations.
7. Have management approve it, then reference it from the technical documentation of the products released in the period.

4. The dossier annex

The example carries an annex worth copying: the standard structure of a release conformity dossier — requirements sheet or delta assessment, threat model, review evidence, CI reports, completed checklists, signed release gate record, SBOM, build provenance. Defining that structure once means the complete evidence package for any release can be handed to a market surveillance authority as it is, with no assembly work under time pressure.

5. Done when

• Every policy phase is covered by a check with a stated method.
• Findings have IDs, owners, due dates and a status.
• The conclusion names limitations honestly.
• The record is approved, dated and referenced by the product technical documentation.

6. Common mistakes

Auditing the policy against itself instead of against real release evidence. Recording only conformity. Leaving corrective actions without a due date, which turns the finding into a permanent note.

7. In TRA Studio

The coverage view of your Secure Lifecycle is the working input to this review: it shows which requirements are assigned to which activities and which are still open, so the annual review starts from evidence rather than from a blank page. Approvals recorded in the tool give you the dated sign-offs the review samples.