How it is created — SDL-PROC-001 CRA-Aligned Software Development Process

1. Why this artifact exists

The SDL policy says what the company commits to. This process says when it happens, who does it, and which record proves it. Without that second document, every CRA obligation has to be re-discovered per project, and the predictable failure appears at the release gate: the product is finished, but the technical documentation is not — because the risk assessment version that had to be written before the architecture froze was never written.

It also answers the auditor's real question. An auditor does not ask "do you take security seriously"; they pick an obligation, ask which activity satisfies it, and ask to see the record. A process table with a CRA anchor, a responsible role and a record per row answers all three in one line.

2. Inputs

• The SDL policy (SDL-POL-001) — phases, roles, tailoring rules. This process refines it; it must not contradict it.
• The obligation list you are working from: Annex I Part I (product properties), Annex I Part II (vulnerability handling), Art. 13 (manufacturer duties, support period), Art. 14 (reporting), Art. 32/36 and Annex VII/VIII (conformity assessment, technical documentation).
• Your existing engineering reality: CI stages, review rules, release procedure, on-call. The process should describe what your team does — with the gaps made visible — not an idealised process nobody runs.
• The artifact templates you already have (classification record, threat model, checklists). Each becomes a "Record" cell.

3. Steps

1. Split by when, not by topic.* Company-level foundations (done once, maintained), pre-development (per product, before architecture freeze), during development (continuous), before release (per release), after release (for the whole support period). Topic-based structure hides the timing, and timing is what the CRA actually constrains.
2. Put the permanent duties in a phase of their own. Vulnerability handling, the disclosure policy and contact point, the support-period policy, SBOM tooling, reporting readiness — these must be in force before a project may start, not assembled at release.
3. Write one row per activity, with four columns: activity, CRA anchor, responsible role, record. A row without a named record is a claim, not a process. A row without a named role has no owner.
4. Define a gate per phase and say what it blocks. "Architecture freeze", "feature freeze", "placement on market" — each with the list of records that must exist. A gate that cannot stop a release is decoration.
5. Cover the post-release phase in the same detail as development. Roughly half of the CRA's obligations only start once the product ships: triage times, free security updates, advisories, SBOM upkeep, the 24 h / 72 h / 14-day reporting clocks, end-of-support notice.
6. Add a traceability table mapping each obligation to the phase activities that cover it. This is the sheet you hand an auditor first, and the one that shows you where nothing is covered.
7. Mark what forces a return to an earlier phase. A substantial modification re-opens classification and conformity assessment; a design change touching a trust boundary re-opens threat modelling. Processes that only run forwards silently go stale.
8. Approve it at management level and date it. The signature commits the resources the process assumes.

4. Done when

• Every obligation you are subject to appears in the traceability table with at least one activity covering it.
• Every activity row names a CRA anchor, a responsible role and a record.
• Each phase ends in a gate whose exit criteria are records, not opinions.
• Post-release duties have named owners and stated response times.
• No activity depends on a single person with no deputy.
• Management has signed a dated revision.

5. Keeping it alive

Review annually together with the SDL policy, and whenever an obligation date approaches, a role changes hands, or a tool in the chain is replaced. Note the dates that move on their own — the reporting obligations apply from September 2026 — and keep the revision history honest: a process document that never changed while the team did is evidence of a document, not of a process.

6. In TRA Studio

This document is the paper version of what the tool maintains as live data. Model each phase as an activity in your Secure Lifecycle under Workflow & Processes, record the responsible role and the artifact it produces on each activity, and map the requirements of your in-scope standards onto those activities. The traceability table above is then generated rather than typed: requirements with no activity are your open gaps, and the release gate refuses to sign off while a required one is still open.