Resources
Example process descriptions
Worked examples of the documents a CRA audit expects to see — written the way a small manufacturer would actually write them.
How the documents fit together
The set is layered: the processes at the top state what has to happen, the policies below them fix the rules once for the whole company, and everything further down is a record produced by following them. The arrows are the documents' own cross-references — select any document to see what it rests on and what rests on it.
SDL-PROC-001
CRA-Aligned Software Development Process
Five phases and four gates: every CRA obligation mapped to an activity, a responsible role and the record it produces — plus the traceability table that shows what is not yet covered.
References (12)
Referenced by (9)
Document ID conventions
Every document carries an ID, and they cite each other by it — which is what lets the set be read as a whole. The scheme is ACME's own document control; the CRA prescribes the content of the technical documentation, not how you number it.
DOMAIN–TYPE–NUMBERSDL-STD-022 · REG-REC-020 · SEC-RA-S300Domain — which management system owns it
- SDL
- Secure Development Lifecycle — how products get built
- PSM
- Product Security Management — vulnerability handling and support after release
- SEC
- Security artefacts for one specific product
- ENG
- Engineering records and decisions taken during development
- REG
- Regulatory determinations — classification, conformity route, representative
- QM
- Quality management — organisation and roles
- CON
- Contracts and purchasing
- LEG
- Legal
Type — what kind of document it is
- POL
- Policy — binding rules, no steps
- PROC
- Process — ordered steps with roles and gates
- STD
- Standard — technical rules to comply with
- TMP
- Method and template — how a document is produced, plus the blank form
- CHK
- Checklist — completed per release
- REC
- Record — evidence that something happened, at a date
- LST
- Register — living data, updated continuously
- ORG
- Organisational matrix — roles and deputies
- CLS
- Clause set — contract text for suppliers
- RA · TM · DES
- Risk assessment, threat model, design document — the product-level artefacts
Numbers, products and revisions
- Numbers are assigned per domain, in blocks by type; the gaps are ACME's documents that are not published here. The full ID identifies a document, not the number on its own.
- Product artefacts end in the product code instead of a number — SEC-RA-S300 is the risk assessment for the SensorNode S300, because there is exactly one per product line. Their lifecycle lives in the version: v0.1 is the pre-development baseline, v1.0 the release version, and every version is retained because v0.1 is itself part of the Annex VII technical documentation.
- The revision tells you how a document behaves: rev. 1.0 is a controlled document whose changes are approved events, a living register carries an integer revision, and an annual record is reissued rather than revised.
Complete, realistic documents from a fictitious 45-person manufacturer. Each has its own page, so you can link to it from inside TRA Studio.
Start here: the processes
The development process end to end — once as a CRA phase-and-gate plan, once as an IEC 62443-4-1 V-model — plus the vulnerability handling that runs for the whole support period. Every other document below is a record one of them produces.
SDL-PROC-001
CRA-Aligned Software Development Process
Five phases and four gates: every CRA obligation mapped to an activity, a responsible role and the record it produces — plus the traceability table that shows what is not yet covered.
SDL-PROC-004
V-Model Secure Development Process
The same obligations drawn as a V, structured on the IEC 62443-4-1 practices: four specification levels down, four verification levels up, each one naming the test that closes it — with a diagram, gate criteria and the delta rules for when a change forces you back down the left leg.
PSM-PROC-002
Vulnerability Handling Process
Intake channels with response times, CVSS-based remediation classes, and the Art. 14 notification track — where the 24-hour clock starts on plausible evidence, not on finished analysis.
PSM-PROC-003
Vulnerability Handling — Detailed Operating Procedure
The step-level version of PSM-PROC-002: the standing capabilities that must exist before the first report arrives, then every step from intake to post-release with its output and the record kept as evidence.
Company-level policies & standards
Written once, referenced by every product dossier.
SDL-POL-001
Security Development Lifecycle Policy
The company-level SDL every product dossier references: six phases, roles, risk-based tailoring, and secure-by-default rules.
SDL-POL-005
Third-Party & Open-Source Component Policy
Components treated like suppliers: knock-out selection criteria, approval workflow, and the duties that run for the whole support period.
SDL-STD-022
Support Period & Security Update Policy
Seven years for the industrial lines, security updates free and kept separate from features, signed and rollback-protected delivery — plus what is owed at end of support.
SDL-STD-034
Default Credential Policy
No universal default passwords: per-device credentials or forced first-use setup — and what that demands of the production line.
SDL-STD-020
Secure Coding Standard
A MISRA subset with a real deviation procedure, banned constructs enforced by the pipeline rather than by memory, secret scanning across branch history — and a reviewer's brief for security-relevant changes.
SDL-STD-021
SDL Tailoring Rules
How much process each release type gets, decided before development starts — plus the short list that is never tailorable, and the five questions that decide whether a change is a substantial modification.
SDL-STD-025
Release Signing & Key Management
The key hierarchy, four-eyes signing with no emergency bypass, and why the second verification slot on the device is the difference between an over-the-air recovery and a recall.
CON-CLS-007
Supplier Security Clause Set
The contract terms that make a bought component supportable for the whole product life: 72-hour vulnerability notice, a patch term with a date on it, 24-month EOL notice, SBOM per release, and escrow you can actually trigger.
Supporting registers & templates
The documents the policies point to — where the scales, dates and lists actually live.
PSM-LST-001
Product & Support Register
Which products are still supported, per hardware revision, and which firmware branches still receive fixes — the lookup every triage starts with, and the record of what you published years ago.
SDL-TMP-010
Risk Assessment Method & Template
Anchored 4×4 scales, the thresholds that decide whether a risk gets a design measure or a paragraph, and the version rule that proves the assessment came before the design freeze.
SDL-TMP-011
Threat Modeling Method & Template
STRIDE per element on a data-flow diagram, with a hardware engineer in the room — because on embedded products most of the interesting findings are physical, and every threat row has to end in a requirement.
QM-ORG-003
Role Matrix & Deputies
Who holds each role, who deputises, and which combinations are forbidden — the document that makes every four-eyes rule elsewhere executable when one person is on holiday.
LEG-LST-002
Software Licence Whitelist
Yes, ask counsel, or no — in five minutes, at component-selection time. Including why LGPL and signed statically linked firmware are in direct conflict.
Per-product pre-development (SensorNode S300)
The decisions and assessments a manufacturer must document before the architecture is frozen.
REG-REC-020
CRA Product Classification Determination
A product assessed against Annex III and Annex IV, with the reasoning per category and the trigger for re-assessment.
REG-REC-021
Conformity Assessment Route Decision
Why Module A applies, what it obliges — and the Notified-Body contingency with its lead times.
SEC-RA-S300
Product Risk Assessment (v0.1, pre-development)
The pre-development risk baseline that constrains hardware selection — and the rule that every version is retained.
SEC-TM-S300
Threat Model (STRIDE, pre-development)
Documented methodology, trust boundaries, attack-surface inventory, threat actors, and the requirements derived from them.
ENG-REC-031
EOL Check: Tools and Dependencies
Every component checked against the support-period horizon, with conditions, migration cadence and one knock-out.
ENG-REC-032
Storage Encryption Feasibility (Data at Rest)
A measured comparison of two MCUs against an essential requirement — and the record that forces the more expensive hardware before board layout.
ENG-DES-033
Minimal Attack-Surface Design Plan
Interface-by-interface remove/disable decisions taken early, plus their consequences for mechanics and production.
Release & conformity records
The evidence produced per release and per year.
SDL-CHK-030
Secure-by-Default Release Checklist
A completed release-gate checklist against the factory-default configuration, including a documented deviation and risk acceptance.
SDL-REC-002
Internal SDL Conformity Review
The annual record that demonstrates process conformity without an external certificate, plus the structure of a release conformity dossier.
REG-REC-019
EU Authorised Representative (Art. 19)
An applicability determination for an EU-based manufacturer, and a written AR mandate for the non-EU case.
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.