Die Beispieldokumente und Projektpläne sind bewusst nur auf Englisch veröffentlicht: Sie sind Vorlagen zum Übernehmen, und eine Übersetzung wäre nicht die Fassung, mit der Sie am Ende arbeiten.
Fiktives Beispiel. Dauern, Aufwandszahlen und Rollenaufteilungen sind illustrative Schätzungen für einen kleinen Hersteller, keine Zusage und kein Angebot, und keine Rechtsberatung. Prüfen Sie jedes Datum an der Vorschrift, wie sie für Ihr eigenes Produkt gilt.
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.