Fictitious example. Durations, effort figures and role splits are illustrative estimates for a small manufacturer, not a commitment or a quotation, and not legal advice. Check every date against the regulation as it applies to your own product.
Project Plan A — Establish the CRA Processes (Foundations)
Scope: Bring the Foundations phase of the simplified workflow into force: #0.1 vulnerability handling & CVD, #0.2 SBOM tooling & component overview, #0.3 Art. 14 reporting readiness — plus the role assignments they depend on. Exit criterion is Gate G0 passed: all three activities in force with their records existing.
Duration: 6 weeks, part-time (SME assumption: nobody works on this full-time).
Total effort: ~19 person-days across three roles.
Timing anchor: Art. 14 reporting obligations apply from 11 September 2026 — for a manufacturer with products already on the market, WS4 (reporting readiness) is the hard-deadline workstream and should not slip. The remaining CRA obligations apply in full from 11 December 2027, which is what Plan B works toward.
Roles
| Role | Short | Typical availability assumed |
|---|---|---|
| Product Manager | PM | ~1 day/week |
| Product Security Lead | PSL | ~2 days/week |
| Technical Lead Software | TLS | ~1.5 days/week |
One person may hold several roles; the plan only requires that each role has a named holder and a deputy before G0 (the Art. 14 clock does not wait for vacations).
Workstream 1 — Kickoff & role assignment (Week 1)
| # | Task | Resp. | Effort | Output |
|---|---|---|---|---|
| 1.1 | Assign role holders and deputies for PM, PSL, TLS; record in a one-page role matrix | PM | 0.5 d | Role matrix |
| 1.2 | Decide document numbering/storage: where process documents, records and evidence live (repo, wiki, DMS) | PSL | 0.5 d | Storage decision note |
| 1.3 | Import the workflow template into TRA Studio and assign the roles | PM | 0.5 d | Configured workspace |
Milestone M0 (end of week 1): roles named, storage decided, workspace live.
Workstream 2 — Vulnerability handling & CVD (#0.1) (Weeks 1–3)
| # | Task | Resp. | Effort | Output |
|---|---|---|---|---|
| 2.1 | Draft the vulnerability-handling procedure: intake → triage (with deadlines per severity) → remediation → disclosure; write against the PSM-PROC-002 example | PSL | 2 d | VH procedure v0.9 |
| 2.2 | Draft the CVD policy: scope, safe-harbour wording, expected reporter conduct, credit rules, coordination timelines | PSL | 1 d | CVD policy v0.9 |
| 2.3 | Set up the contact point: security@ mailbox with monitored routing to PSL + deputy, publish /.well-known/security.txt | TLS | 0.5 d | Live contact point |
| 2.4 | Internal review of 2.1–2.2 with TLS and PM, resolve comments, release v1.0, publish CVD policy on the website | PSL | 1 d | Both documents v1.0, published |
Milestone M1 (end of week 3): CVD policy public, contact point answering, procedure in force.
Workstream 3 — SBOM tooling & component overview (#0.2) (Weeks 2–4)
| # | Task | Resp. | Effort | Output |
|---|---|---|---|---|
| 3.1 | Choose SBOM format (CycloneDX vs SPDX) and generator matched to the build system; record the decision | TLS | 0.5 d | Tooling decision |
| 3.2 | Integrate SBOM generation into CI so every build emits one automatically | TLS | 1.5 d | CI job, sample SBOM |
| 3.3 | Build the component overview: all third-party/OSS components with version, source, licence | TLS | 1 d | Component overview |
| 3.4 | Write the due-diligence checklist for adopting new components (maintenance status, known CVEs, licence) and apply it retroactively to the existing components | PSL | 1 d | Checklist + filled records |
Milestone M2 (end of week 4): every build produces an SBOM; component overview complete.
Workstream 4 — Art. 14 reporting readiness (#0.3) (Weeks 3–5) — hard deadline 11 Sep 2026
| # | Task | Resp. | Effort | Output |
|---|---|---|---|---|
| 4.1 | Register access to the single reporting platform (ENISA/CSIRT); identify the competent national CSIRT | PSL | 0.5 d | Working platform access |
| 4.2 | Pre-fill the three templates: 24 h early warning, 72 h notification, final report | PSL | 1 d | Template set |
| 4.3 | Write the one-page trigger decision tree: what counts as "actively exploited" / "severe incident", who decides, within what time, who is deputy | PSL | 0.5 d | Decision tree |
| 4.4 | Brief everyone who could plausibly be first to learn of an incident (support, sales, developers): recognise → escalate to PSL immediately | PSL | 0.5 d | Briefing record |
Milestone M3 (end of week 5): a report could be filed within 24 h starting from any working day.
Workstream 5 — Pilot run & Gate G0 (Weeks 5–6)
| # | Task | Resp. | Effort | Output |
|---|---|---|---|---|
| 5.1 | Tabletop exercise: inject one fictitious vulnerability report; run intake → triage → (simulated) fix decision → advisory draft → Art. 14 trigger check, against the clock | PSL | 1 d (all roles ~0.5 d) | Exercise log, findings |
| 5.2 | Fix what the exercise broke (unclear handovers, missing template fields, dead mailbox rules) | PSL | 1 d | Updated documents |
| 5.3 | G0 review: walk #0.1–#0.3 in TRA Studio, confirm each record exists, mark the gate passed | PM | 0.5 d | G0 record |
Milestone M4 / Gate G0 (end of week 6): Foundations in force. Plan B may start.
Dependencies & risks
- WS2–WS4 all depend on WS1 task 1.1 (no named PSL, no progress). Everything else can run in parallel.
- Risk: single-person bottleneck. In an SME the PSL likely does 70 % of this. Mitigation: the deputy shadows the tabletop exercise (5.1), and PM owns the schedule, not the PSL.
- Risk: platform access delays (4.1). Registration processes outside your control — start WS4 in week 3, not week 5.
- Risk: over-engineering. The exit bar is "in force and exercised once", not "perfect". Documents are versioned; v1.0 is allowed to be thin.