Fictitious example. ACME Embedded GmbH, its products, records and document IDs are invented for illustration. Use this as a structural model, not as a template to adopt unchanged — and not as legal advice.
SDL-PROC-001 — CRA-Aligned Software Development Process
| Document ID | SDL-PROC-001, rev. 1.0 |
| Owner | Product Security Lead (PSL) |
| Approved by | Managing Director, 2026-07-29 |
| Scope | All ACME Embedded GmbH products with digital elements (embedded firmware and companion software) |
| Relationship | Operationalises SDL-POL-001; references the artifact templates established there (REG-REC-, SEC-RA-, SEC-TM-, ENG-REC-, SDL-CHK-, SDL-STD-) |
| Legal anchors | CRA (EU) 2024/2847: Art. 13, 14, 32, 36; Annex I Parts I & II; Annex VII |
This process is organised in five phases. Each phase lists its activities, the responsible role, the CRA anchor, and the record produced. A product may not pass a phase gate until the listed records exist.
Phase 0 — Company-level foundations
Done once, maintained continuously. Every product inherits these; no project re-invents them.
| # | Activity | CRA anchor | Responsible | Record |
|---|---|---|---|---|
| 0.1 | Maintain the documented SDL (phases, roles, deputies, tailoring rules) | Art. 13(1), Annex I Pt I | PSL / MD | SDL-POL-001 |
| 0.2 | Establish vulnerability handling (Item 3): documented process to find, fix and disclose vulnerabilities across the support period | Annex I Pt II | Vulnerability Manager | PSM-PROC-002 |
| 0.3 | Publish the coordinated vulnerability-disclosure (CVD) policy and the public contact point (security@…, security.txt, PGP key); acknowledge reports ≤ 48 h | Annex I Pt II | Vulnerability Manager | CVD policy page + intake SOP |
| 0.4 | Define the support-period policy: default ≥ 5 years (7 for industrial lines), security updates free of charge, separated from feature updates | Art. 13(8), Annex I I(2) | MD | SDL-STD-022 (support & update policy) |
| 0.5 | Third-party & OSS component policy incl. EOL and vuln-response obligations for suppliers | Annex I Pt II | PSL | SDL-POL-005 |
| 0.6 | Default credential policy (no universal defaults, per-device or forced first-use setup) | Annex I I(2)(c) | PSL | SDL-STD-034 |
| 0.7 | SBOM tooling: CycloneDX generation wired into CI, feeding the vulnerability analyzer/CVE watch | Annex I II(1) | DevOps Lead | CI config + component registry |
| 0.8 | Reporting readiness: on-call rule, ENISA/CSIRT single reporting platform account, notification templates, 24 h/72 h drill once a year | Art. 14 | Vulnerability Manager | Incident-reporting SOP + drill record |
| 0.9 | Annual internal SDL conformity review (substitutes for external certification) | Annex I Pt I | QA | SDL-REC-002 |
Gate G0 (permanent): a product project may only start if 0.1–0.8 are in force.
Phase 1 — Pre-Development
Per product/major variant, before architecture freeze.
| # | Activity | CRA anchor | Responsible | Record |
|---|---|---|---|---|
| 1.1 | Classify the product (Item 1): Default / Important Class I–II / Critical against Annex III & IV; record the reasoning, incl. a sensitivity note on planned features that could shift the class | Annex III/IV | Product Manager + PSL | REG-REC-020 |
| 1.2 | Select the conformity assessment route (feeds Item 7): Module A self-assessment for Default; harmonised-standard check for Class I; Notified Body (B+C or H) for Class II/Critical — plan 4–10 months NB lead time and set a "classification re-confirmed" gate | Art. 32, Annex VIII | Product Manager | REG-REC-021 |
| 1.3 | Pre-development cybersecurity risk assessment (start of Item 1 "security by design"): performed before design decisions freeze; v0.x retained unchanged as part of the technical documentation; all later versions retained | Annex I I(1) | PSL | SEC-RA-\<product\> v0.1 |
| 1.4 | Threat modelling: attack surface, threat actors, vectors, derived security requirements; methodology documented | Annex I I(1) | PSL + team | SEC-TM-\<product\> |
| 1.5 | Derive the Security Requirements Sheet covering the Annex I Pt I essential properties (authentication/access control, encryption in transit & at rest, integrity, availability, data minimisation, logging, secure updates) | Annex I Pt I | PSL | SR sheet |
| 1.6 | Feasibility checks that can force hardware change: storage-encryption capability of target silicon; EOL screening of key tools, kernels and libraries against launch + support period | Annex I I(4)(e), Pt II | HW Eng / DevOps | ENG-REC-032, ENG-REC-031 |
| 1.7 | Minimal attack-surface design plan: keep/disable/remove decision per interface, service, port, protocol; consequences pushed into mechanical, silicon and production planning | Annex I I(2)(b) | FW Lead | ENG-DES-033 |
Gate G1 — Architecture freeze: classification recorded, route selected, RA v0.x and threat model approved, feasibility passed, attack-surface plan approved.
Phase 2 — During Development
Iterative; controls run continuously in CI and review.
| # | Activity | CRA anchor | Responsible | Record |
|---|---|---|---|---|
| 2.1 | Build security in by design (Item 1): implement the SR sheet; every design change touching interfaces/trust boundaries triggers a delta threat-model workshop before implementation | Annex I Pt I | FW Lead | Delta TM records |
| 2.2 | Implement authentication and access controls per the credential policy; role separation on any management interface | Annex I I(2)(c)(d) | Dev team | Code + test evidence |
| 2.3 | Implement encryption in transit and at rest: TLS/AEAD on links with certificate validation on; hardware-backed key storage; encrypted persistent data | Annex I I(4)(e) | Dev team | Design notes, test evidence |
| 2.4 | Secure implementation controls: coding standard, mandatory peer review (PSL review for security-relevant changes), no hard-coded secrets, secrets scanning in CI | Annex I Pt I | Dev team | MR approvals, CI logs |
| 2.5 | Maintain the SBOM (Item 4): machine-readable (CycloneDX) generation on every build; components tracked in the registry with known-vulnerability watch (Vulnerability Analyzer); new components only via SDL-POL-005 approval | Annex I II(1) | DevOps | SBOM per build + registry |
| 2.6 | Continuous verification: SAST, dependency/CVE scan, fuzzing of externally reachable parsers; findings ≥ CVSS 7.0 block merge to release branch | Annex I Pt I | QA | CI reports |
| 2.7 | Guard against the common pitfall (Item 2): CI surface-audit fails the production build if debug shells, sniffer/test modes, verbose error output, RTT logging or vendor demo services are present | Annex I I(2)(b) | DevOps | CI gate config + logs |
Gate G2 — Feature freeze: SR sheet fully implemented or formally waived; SBOM current; no open blocking findings.
Phase 3 — Before Release
Per release; ends with CE-marked product ready to place on market.
| # | Activity | CRA anchor | Responsible | Record |
|---|---|---|---|---|
| 3.1 | Verify the secure-by-default configuration (Item 2) on a production-fused unit: only required services enabled, debug locked, no default credentials, encryption on by default, secure update on by default (or documented risk acceptance) | Annex I I(2)(3) | QA + PSL | SDL-CHK-030 (signed) |
| 3.2 | Finalise the risk assessment (v1.0) reflecting the as-built product; residual risks accepted by PSL | Annex I I(1) | PSL | SEC-RA v1.0 |
| 3.3 | Finalise release SBOM; resolve or risk-accept all known component vulnerabilities | Annex I II(1)(2) | DevOps | Release SBOM |
| 3.4 | Define and publish the support period for this product (Item 5): end date stated in user information and technical documentation | Art. 13(8) | Product Manager | Support statement |
| 3.5 | Assemble the technical documentation (Item 6) per Annex VII: product description & intended use, all risk-assessment versions, threat model, standards applied, SBOM reference, attack-surface document, test evidence, user information, support period | Annex VII | Product Manager | Annex-VII dossier (REL-DOS-*) |
| 3.6 | Carry out the conformity assessment (Item 7) per the route from 1.2: Module A internal control, or Notified Body procedure for Important/Critical; then draw up and sign the EU Declaration of Conformity (Annex V, simplified per Annex VI with the product) and affix the CE marking | Art. 32, 36; Annex V–VIII | MD (signature) | DoC + CE evidence |
| 3.7 | Security release gate: PSL chairs; checks 3.1–3.6 complete; firmware image signed; update channel verified end-to-end | Annex I Pt I | PSL | Release Gate Record |
Gate G3 — Placement on market: signed Release Gate Record + signed DoC. Without both, no shipment.
Phase 4 — After product release
For the entire declared support period, per product.
| # | Activity | CRA anchor | Responsible | Record |
|---|---|---|---|---|
| 4.1 | Operate vulnerability handling (Item 3): intake via the public contact point, triage ≤ 5 working days, remediate without undue delay, coordinate with reporters per CVD policy | Annex I Pt II | Vulnerability Manager | PSM-PROC-002 case records |
| 4.2 | Ship free, timely security updates (Item 5): security patches separated from feature updates, free of charge, delivered through the secure (signed, rollback-protected) update mechanism | Annex I I(2), Pt II | FW Lead | Patch release records |
| 4.3 | Disclose fixed vulnerabilities once the update is available: security advisory with affected versions, severity, remediation | Annex I Pt II | Vulnerability Manager | Advisories |
| 4.4 | Keep the SBOM current with each release (Item 4); continuous CVE watch on all shipped versions across all supported branches | Annex I II(1) | DevOps | Updated SBOMs, watch logs |
| 4.5 | Meet reporting obligations (Item 8), applicable from September 2026: for an actively exploited vulnerability or a severe incident — early warning to ENISA and the CSIRT within 24 hours, notification within 72 hours, final report within 14 days (vulnerability) / 1 month (incident); inform affected users where appropriate with mitigation guidance | Art. 14 | Vulnerability Manager (on-call) | Notification records |
| 4.6 | Maintain the product and its documentation: re-run the EOL check annually, execute planned LTS migrations, update the risk assessment on substantial modification — noting that a substantial modification can re-open Phase 1 (re-classification and new conformity assessment) | Art. 13, Annex I | PSL | Annual delta records |
| 4.7 | End-of-support: announce ≥ 12 months ahead, final advisory, archive the complete dossier (retention 10 years after last unit placed on market) | Art. 13(8) | Product Manager | EOL notice, archive record |
Item-to-phase traceability
| Item (input list) | Covered in |
|---|---|
| 1 — Classification + record reasoning; security by design | 1.1 (classify/record), 1.3–1.5 (design in), 2.1–2.3 (build in) |
| 2 — Secure-by-default, auth, encryption, minimal surface; pitfall | 0.6, 1.7 (plan), 2.2, 2.3, 2.7 (build + pitfall gate), 3.1 (verify) |
| 3 — Vulnerability handling, CVD policy, contact point, remediation, disclosure | 0.2, 0.3 (establish), 4.1, 4.3 (operate) |
| 4 — SBOM: machine-readable, tracked, updated per release | 0.7 (tooling), 2.5 (build), 3.3 (release), 4.4 (maintain) |
| 5 — Free, timely, separated security updates; published support period | 0.4 (policy), 3.4 (publish), 4.2 (deliver) |
| 6 — Technical documentation (Annex VII) | 3.5 (assembled from records produced in every prior phase) |
| 7 — Conformity assessment + DoC + CE | 1.2 (route), 3.6 (execute) |
| 8 — Reporting obligations & maintenance | 0.8 (readiness), 4.5 (notify), 4.6–4.7 (maintain) |
Revision history
| Rev | Date | Change | Approved |
|---|---|---|---|
| 1.0 | 2026-07-29 | Initial issue, consolidating existing artifacts into one phased process | MD |