Article 14 reporting begins on 11 September 2026. A readiness exercise should prove that one product-specific signal can move through intake, trigger assessment, the correct staged sequence, user communication, and retained evidence under realistic time pressure.
The exercise is not a legal conclusion about a real vulnerability and must not create an external notification. Mark every artefact as exercise material.
Choose a scenario that tests the system
Use a real product architecture but synthetic facts. A strong vulnerability scenario includes an external exploitation signal, an integrated component, ambiguous version scope, a weekend arrival, and a mitigation that becomes available before a full patch.
A strong incident scenario includes a compromised release or update path, uncertain product effect, multiple Member States, sensitive technical detail, and possible overlap with another reporting regime.
Pick one track for the primary run and inject evidence that tests whether participants wrongly switch tracks or combine them.
Establish rules and observers
Name a controller who releases evidence, an observer who records times and decisions, and participants for product security, incident response, engineering, legal, privacy where relevant, communications, customer support, distribution, and the assigned reporting representative.
Publish the stop rule: nobody submits to an authority, contacts real users, or changes production. Use a clearly isolated workspace and synthetic contact details.
Define success measures before starting: time to acknowledge, identify the manufacturer and product, decide the trigger, record awareness, select the coordinating route, prepare each stage, approve user communication, and close the evidence record.
Run the decision phase
Release the first signal without a conclusion. Require the team to preserve the source, map it to product versions, distinguish exploitation from exploitability or test product impact, identify missing evidence, and name the decision owner.
Observe whether uncertainty is recorded or hidden. Inject a conflicting source and an unavailable primary responder. The decision should still reach an approved outcome and a specific reopen condition.
Exercise the reporting handoffs
For a triggered case, have the team assemble an early-warning packet, 72-hour packet, and final-report plan using the correct track. Verify product identity, Member State record, sensitivity review, approval, representative handoff, and simulated submission evidence.
Advance the scenario to a corrective or mitigating measure for the vulnerability track, or to the submitted 72-hour notification for the incident track. Require the team to calculate the correct final trigger and preserve its evidence.
Exercise user and parallel duties
Identify impacted users, select proportionate channels, draft actionable measures, and capture simulated delivery evidence. Introduce one distributor-owned audience and one unreachable group.
Ask legal and privacy leads to identify other regimes or contracts requiring separate assessment. They should link the facts without treating the CRA exercise packet as a universal filing.
Close with evidence, not impressions
Collect the timeline, decisions, drafts, approvals, route analysis, access results, user-audience map, and observer notes. Convert every gap into an owner, corrective action, proof requirement, and due date. Retest the failed segment rather than waiting for the next annual exercise.
The exercise passes when a reviewer can reconstruct what the team knew, who decided, which sequence it followed, how it protected users and sensitive information, and what proves every simulated handoff.
Continue this workflow with the after-hours escalation chain and the stage-handoff packet.