Explanation
This lesson turns the previous five into a plan. The regulation sets what must be achieved; it does not prescribe a project method. The structure below is therefore a set of recommendations, each linked to the obligations it helps meet. Adapt it to your products and organisation.
Two horizons
What the text requires
Two dates frame the plan. The reporting obligations of Article 14 apply from 11 September 2026, including for in-scope products already placed on the market (Article 71(2), second subparagraph, Article 69(3)). The other requirements apply from 11 December 2027 (Article 71(2), first subparagraph) — for products placed on the market before that date, only if they undergo a substantial modification from that date (Article 69(2)).
As of November 2026, reporting readiness is therefore not a future project: if you manufacture in-scope products, Article 14 already applies.
Workstream 1 — Inventory and scoping
Good practice (recommendation, not a legal requirement)
List every product, software release and component you place or make available on the EU market, with its intended purpose, data connections, remote data processing and commercial context. For each, record your role (manufacturer, importer, distributor, authorised representative) and check the exclusions of Article 2. Flag products whose core functionality may match a category of Annex III or IV. Document the reasoning, including the uncertain cases. The CRA scoping checklist supports this step.
Workstream 2 — Reporting readiness (already due)
Good practice (recommendation, not a legal requirement)
Set up the Article 14 process now: an internal rule for when evidence of active exploitation or a severe incident is considered reliable; on-call ownership able to submit an early warning within 24 hours; templates for the 24-hour, 72-hour and final reports; identification of your main establishment and of the CSIRT designated as coordinator; access to the single reporting platform; and user communication templates (Article 14(8)). Run a tabletop exercise against a fictional scenario.
Workstream 3 — Gap analysis against Annex I
Good practice (recommendation, not a legal requirement)
For each in-scope product, carry out or update the cybersecurity risk assessment required by Article 13(2) and (3), then map each point of Annex I, Part I and Part II to existing controls, evidence and gaps. Treat the software bill of materials, coordinated vulnerability disclosure policy, security update mechanism and free security updates as early priorities, since they often require engineering and contractual changes.
Workstream 4 — Support period and product information
Good practice (recommendation, not a legal requirement)
Define a support-period policy: how you estimate expected use time, who approves it, where the reasoning is recorded and how the end date is shown at purchase (Article 13(8) and (19)). Review the information and instructions of Annex II and set up the single point of contact.
What the text requires
The single point of contact must allow users to choose their preferred means of communication and must not be limited to automated tools (Article 13(17), third subparagraph).
Workstream 5 — Documentation and conformity
What the text requires
Before placing a product on the market, the manufacturer must draw up the technical documentation referred to in Article 31 (Article 13(12), first subparagraph). It must be drawn up before placing on the market and continuously updated, where appropriate, at least during the support period (Article 31(2)).
Good practice (recommendation, not a legal requirement)
Build a documentation skeleton following Annex VII and decide the conformity assessment route for each product (lesson 5). Where a notified body will be needed, contact one early. Prepare the EU declaration of conformity and the CE marking process, including the website or declaration placement for software products.
Workstream 6 — Supply chain and components
Good practice (recommendation, not a legal requirement)
Update supplier requirements so that you can exercise due diligence on third-party components (Article 13(5)) and report vulnerabilities to component maintainers (Article 13(6)): ask for software bills of materials, security update commitments and contact points. Review the open-source components you depend on and how you will contribute fixes.
Workstream 7 — Governance and monitoring
Good practice (recommendation, not a legal requirement)
Appoint an owner for the programme, report progress to management, train the teams involved, and monitor the texts still to come: implementing and delegated acts, harmonised standards and Commission guidance. Review the plan whenever one of them is published. The CRA preparation action plan provides a template.
Uncertain / awaiting guidance
Several elements that affect planning were still pending when this lesson was written — for example harmonised standards and some implementing and delegated acts. Plan buffers and revisit the assumptions you make about them.
Practical case
Fictional example — A twelve-month plan at Orchard Devices
Orchard Devices, a fictional company with 120 staff, sells a smart irrigation controller (default category), a companion app and a router-like gateway (class I of Annex III). In November 2026 it adopts this plan:
| Period | Workstream | Deliverable |
|---|---|---|
| Month 1 | Reporting readiness | Article 14 procedure, on-call rota, report templates, tabletop exercise |
| Months 1–2 | Inventory and scoping | Product and role register, Annex III check, open questions log |
| Months 2–5 | Gap analysis | Updated risk assessments; Annex I gap list per product; SBOM pipeline |
| Months 3–6 | Support period | Policy, end dates on packaging and website, end-of-support notification design |
| Months 4–9 | Documentation | Annex VII technical files; notified body selected for the gateway |
| Months 6–12 | Supply chain | Supplier clauses, component inventory, CVD policy published |
| Ongoing | Governance | Monthly steering, monitoring of standards and implementing acts |
Orchard records which items are legal obligations and which are internal good practice, so that it can explain its choices to a market surveillance authority if asked.
Exercise
EXERCISE — DRAFT YOUR FIRST FIVE ACTIONS
For a product you know (or a fictional one), write five actions for the next three months. For each, indicate the provision it serves and whether it is a legal obligation or a recommendation.
Show a suggested answer
A possible answer for a manufacturer of a connected product:
- Adopt an Article 14 reporting procedure with 24-hour capability — serves Article 14 (obligation, already applicable).
- Complete the product and role inventory, including Article 2 exclusions — serves Articles 2, 3 and 21 (preparatory step; the scoping itself is a recommendation).
- Update the cybersecurity risk assessment — Article 13(2) and (3) (obligation applying from 11 December 2027).
- Generate a software bill of materials covering at least top-level dependencies — Annex I, Part II, point (1) (obligation).
- Decide and document the support period and how the end date will be displayed — Article 13(8) and (19) (obligation).
Key takeaways
KEY TAKEAWAYS
- Article 14 reporting already applies: make it the first workstream.
- Organise the rest of the preparation around scoping, Annex I gaps, support period, documentation, conformity route and supply chain.
- Keep obligations and recommendations visibly separate in your plan.
- Draw up the technical documentation before placing on the market and keep it updated during the support period.
- Monitor implementing acts, delegated acts, harmonised standards and guidance, and revise the plan when they are published.