How the example artifact on the other tab is produced: trigger, inputs, steps, and what "done" means. Guidance based on the CRA text — a starting point for your own process, not legal advice.

How it is created — SDL-CHK-030 Secure-by-Default Release Checklist

Produces	SDL-CHK-030 — the checklist template, and one completed instance per release
Type	Company-level template; completed record filed in the release conformity dossier
Owner	Product Security Lead (template), Verification Lead (completion)
Trigger	Template written once with the SDL policy; completed at every security release gate
CRA reference	Annex I I(2) generally, and I(2)(3) in particular — secure by default, without configuration by the end user

1. Two different activities

Writing the template is a policy activity. Completing it is a verification activity performed per release, on a specific firmware version, on a production-fused unit. Keep them apart: the template changes rarely and is approved by the security owner; the completed instance is evidence and is never edited after sign-off.

2. Inputs

The attack-surface decision table and the Attack Surface Document — the checklist verifies reality against what those documents claim.
The default credential policy and its per-product application table.
The actual shipping artefacts: production image, fuse configuration, factory-default configuration.

3. Building the template

Group the checks by property, in the order an auditor thinks: attack surface as shipped, credentials and access, communication and data, updates and recovery.
Write every check so it can be answered by observation, not by opinion. "Only required services enabled" becomes "port scan of a factory-default unit matches the Attack Surface Document".
Demand evidence per row. A scan report, a boot log, a test case ID, a capture, a video of the first-boot flow. A checklist of ticks without evidence references is worth nothing at a market surveillance inspection.
State the completion rule at the top: factory-default configuration as shipped, production-fused unit, not a development build. This single sentence is what makes the record credible.
Define what a "No" means — a fix before release, or a documented risk acceptance approved by the security owner. Never a silent tick.

4. Completing it per release

Provision a unit exactly as it will ship, including production fuses.
Work through the checks, attaching the evidence reference for each. Where a check fails, stop and route it: fix, or deviation record.
Write the deviation record properly if one is needed: the reason grounded in the intended use, the mitigation, the risk-acceptance ID, the approver, the date, and when it will be re-evaluated. The worked example shows a real one — automatic updates off by default in an industrial setting, with the reasoning and a re-evaluation commitment.
Sign off with two roles — the person who verified and the person who approved.
File in the release conformity dossier and reference it from the Release Gate Record.

5. Done when

Every row has a result and an evidence reference.
Every "No" has an approved deviation with a re-evaluation date.
The sign-off names two different people.
The record is filed and referenced, not stored in someone's mailbox.

6. Common mistakes

Running the checklist on an engineering build, where debug interfaces are open and the fuse state differs from production. Recording "Yes" without evidence. Letting the same deviation ride from release to release without ever re-evaluating it.

7. In TRA Studio

Model the release gate as an activity in your Secure Lifecycle with this checklist as its output, and assign the Annex I I(2) requirements to it. The coverage view then shows the secure-by-default duty as verified per release rather than asserted once.