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-POL-001 Security Development Lifecycle Policy
| Produces | SDL-POL-001 — Security Development Lifecycle Policy |
| Type | Company-level policy (one per organisation, not per product) |
| Owner | Product Security Lead |
| Approves | Managing Director |
| Trigger | Once, before the first CRA-relevant development starts; then annually and after any significant incident |
| CRA reference | Art. 13(1); Annex I Part I — conformity is demonstrated through a documented process, not through the finished product alone |
1. Why this artifact exists first
Every other document in this collection references the SDL policy by ID and revision. Without it, each product dossier has to re-argue how the company develops securely, and an auditor has nothing to sample against. Write it once, keep it short enough that people actually follow it, and let the product records carry the detail.
A common failure mode is the opposite: a 60-page policy nobody applies. The test is whether a release can be blocked by it.
2. Inputs
- The regulatory obligations that apply to your products (CRA Annex I Part I as the baseline; sector legislation if applicable).
- An orientation standard if you want one — IEC 62443-4-1 practices (SM, SR, SD, SVV, DM, SG) are the usual choice for industrial products, ISO/IEC 27034 or the NIST SSDF for software-only products. Using a standard for structure does not require certification.
- How your team actually develops today: branching model, review rules, CI stages, release procedure.
3. Steps
- Name the roles first. Product Security Lead, development lead, verification lead, vulnerability manager, management. Assign them to real functions and name deputies. A process without an owner cannot be audited.
- Draw your phases from your reality, then check them against the standard — not the other way round. Six to seven phases is typical: requirements, design, implementation, verification, release, maintenance, end-of-life.
- Per phase, write three things only: what must be produced, who approves it, and what blocks progression. Everything else belongs in a template or checklist referenced from the policy.
- Add the [tailoring rule](/resources/examples/sdl-std-021). Define explicitly what a minor release may skip and who signs that off. Without it, teams either over-document or quietly skip steps.
- Point to the templates and records by ID (requirements sheet, threat model template, release-gate record, checklists). The policy stays stable while the templates evolve.
- Set retention and review. Retention runs to the end of the support period plus the statutory period; review is annual and tied to the management review.
- Approve at management level. The signature matters: it is the evidence that resources were committed.
4. Done when
- Each phase names an output, an approver, and an exit criterion.
- No phase can be approved by the person who performed the work.
- Every phase output referenced by ID exists as a template or a record.
- Vulnerability handling and the support period are covered — Annex I Part II duties do not stop at release.
- Management has signed a dated revision.
5. Keeping it alive
Review annually and after any significant security incident. Record changes in the revision history — a policy with a single revision after three years is a signal to an auditor, not a sign of stability.
6. In TRA Studio
Model these phases as the activities of your Secure Lifecycle under Workflow & Processes, then map the requirements of your in-scope standards onto those activities. Requirements that stay unassigned are your open gaps; the coverage view is the working version of what this policy claims on paper.