Illustrative sample — fictional organisation and answers. # Article 14 Ready — 24h Dry Run v1.0.2 Generated via: https://article14ready.com Generated: 2026-09-09T12:00:00.000Z Organisation: Example Device Labs \(fictional\) Product: Atlas Gateway 4\.x Exercise time: 00:34:00 ## 1. Decision brief Example Device Labs \(fictional\) scored 54/100 for Atlas Gateway 4\.x\. The reported workflow is not ready to rely on during a reportable event\. 15 of 20 checks need follow\-up; 0 are marked not applicable\. - Overall: 54/100 (Not ready) - 24-hour readiness: 67% - 72-hour readiness: 36% - Final-report readiness: 50% - Named roles: 6/6 - Ready: 5; Partial: 9; Gap: 6; Unanswered: 0; N/A: 0 All six roles have an entry; availability and authorised access still require demonstration. ## 2. Scope and exercise conditions Delivery model: Connected hardware / IoT Participants: Product Security Lead, Regulatory Operations Lead, Engineering On\-call, Release Engineering Lead, Compliance Reviewer, Customer Communications Lead Scope notes: Fictional worked example, not a customer assessment\. One EU\-facing connected\-product team; releases 4\.0–4\.2\.1; Germany, France and the Netherlands\. Ratings represent hypothetical preparation gaps\. No live customer data, incidents or credentials were used\. The incident below is synthetic. Ratings describe the team's reported preparation, not investigation of a real incident. ### T+00:00 — 24-hour stage At 09:10 UTC, two customers and a trusted source report malicious exploitation of an authentication bypass in a component embedded in fictional Atlas Gateway 4\.0–4\.2\.1\. The product is available in Germany, France and the Netherlands\. No patch exists; a network\-isolation workaround appears viable\. Exercise question: Can the team establish the clock, record the reporting decision, identify the product and route, approve the known facts and cover an absent submitter? ### T+30 hours — 72-hour stage A vulnerability identifier is assigned\. Two supported releases and one legacy release are exposed\. Exploitation attempts are visible; the number of successful compromises remains under investigation\. A patch candidate is being tested\. Exercise question: Can the team produce one evidence\-backed case, a bounded initial assessment and consistent mitigation instructions while facts are still changing? ### Day 5 — Final-report stage Fictional release 4\.2\.2 removes the vulnerable path\. Three customer instances show unauthorised access affecting configuration integrity\. The scenario has no evidence of broader data extraction\. Exercise question: Can the team preserve the externally available fix milestone, support its final impact and cause statements, and retrieve the complete case record? ## 3. Accountable roles ### Product-security case owner Owner: Product Security Lead Own the case, awareness record, trigger decision and evidence trail\. ### Primary SRP submitter Owner: Regulatory Operations Lead Maintain authorised submission access and retain submission records\. ### Backup SRP submitter Owner: Engineering On\-call Cover absence and prove that the reporting handover works\. ### Engineering remediation lead Owner: Release Engineering Lead Maintain affected\-release, technical\-impact and corrective\-measure evidence\. ### Regulatory review owner Owner: Compliance Reviewer Review the reporting position and sensitive\-content decisions within the agreed review window\. ### User communications owner Owner: Customer Communications Lead Keep product\-availability records and approved user instructions consistent\. ## 4. Prioritised preparation plan P1: early-warning preparation; P2: notification; P3: final reporting and closure. Gaps come before partial capabilities within each group. Targets are proposed preparation windows before an incident, not statutory deadlines or permission to defer an active report. ### 1. 24-srp — A working EU Login and assigned representative exist Priority: P1 | Current rating: Gap Proposed target: Days 1–7 of preparation Accountable role: Primary SRP submitter — Regulatory Operations Lead Action: Validate the primary and backup representatives' EU Login and SRP access during an out\-of\-hours drill\. Evidence to close: The primary and backup submitters each complete an authorised access check for the correct manufacturer\. Record the date and outcome, without storing passwords or credentials\. ### 2. 24-summary — A concise, factual early-warning summary can be approved Priority: P1 | Current rating: Gap Proposed target: Days 1–7 of preparation Accountable role: Regulatory review owner — Compliance Reviewer Action: Pre\-approve an early\-warning skeleton and a four\-hour review service level\. Evidence to close: A factual draft is reviewed and approved within the team's agreed internal target\. It distinguishes what is known from what remains under investigation and records the approver and time\. ### 3. 24-trigger — Reportability can be decided without waiting for root cause Priority: P1 | Current rating: Partial Proposed target: Days 1–7 of preparation Accountable role: Product-security case owner — Product Security Lead Action: Approve a one\-page trigger decision record with escalation criteria and a named decision owner\. Evidence to close: A completed decision record separates confirmed facts, assumptions and unresolved questions, names the decision owner and records the reason for the reporting decision\. ### 4. 24-countries — Member States of product availability can be identified Priority: P1 | Current rating: Partial Proposed target: Days 1–7 of preparation Accountable role: User communications owner — Customer Communications Lead Action: Map sales/distribution data to an exportable country list per supported product family\. Evidence to close: A reproducible product\-availability extract names the relevant countries, source system, coverage limits, update date and maintenance owner\. ### 5. 24-cover — A backup owner can act outside business hours Priority: P1 | Current rating: Partial Proposed target: Days 1–7 of preparation Accountable role: Backup SRP submitter — Engineering On\-call Action: Name a backup submitter and test one handover outside ordinary office hours\. Evidence to close: With the primary person unavailable, the backup finds the case, current draft, review contacts and authorised submission route\. Keep the timed handover result and unresolved access issues\. ### 6. 72-measures — Completed mitigation and user measures are documented Priority: P2 | Current rating: Gap Proposed target: Days 8–14 of preparation Accountable role: Engineering remediation lead — Release Engineering Lead Action: Make mitigation timestamps and user\-facing instructions required fields in the response workflow\. Evidence to close: The case records each completed measure, its timestamp and evidence, plus the exact approved steps users can take\. Support can retrieve the current instructions\. ### 7. 72-versions — Third-party component exposure maps to supported and legacy releases Priority: P2 | Current rating: Gap Proposed target: Days 8–14 of preparation Accountable role: Engineering remediation lead — Release Engineering Lead Action: Link component\-inventory records to shipped releases and support status, including legacy versions\. Evidence to close: An exposure matrix links the component and version to shipped product releases and support status\. Unresolved coverage is labelled explicitly rather than treated as unaffected\. ### 8. 72-legal — Legal or regulatory review fits inside the remaining clock Priority: P2 | Current rating: Gap Proposed target: Days 8–14 of preparation Accountable role: Regulatory review owner — Compliance Reviewer Action: Set and rehearse an incident\-review SLA measured in hours, with a documented bypass for unavailability\. Evidence to close: A timed review demonstrates that the primary or designated backup reviewer can return a decision within the agreed internal window\. Record escalation and unresolved blockers\. ### 9. 72-evidence — Technical evidence is assembled into one case Priority: P2 | Current rating: Partial Proposed target: Days 8–14 of preparation Accountable role: Product-security case owner — Product Security Lead Action: Define a single incident case record and mandatory links to logs, the software bill of materials \(SBOM\), release records and remediation evidence\. Evidence to close: One case index links the exploitation evidence, component inventory, release records and mitigation record\. An authorised colleague can open those links and identify the latest version\. ### 10. 72-assessment — An initial severity and impact assessment can be produced Priority: P2 | Current rating: Partial Proposed target: Days 8–14 of preparation Accountable role: Product-security case owner — Product Security Lead Action: Adopt a short severity/impact template with confirmed, suspected and unknown sections\. Evidence to close: A dated initial assessment separates confirmed, suspected and unknown impact, references its supporting evidence and identifies who reviews the next update\. ### 11. 72-sensitive — Sensitive information has a specific handling decision Priority: P2 | Current rating: Partial Proposed target: Days 8–14 of preparation Accountable role: Regulatory review owner — Compliance Reviewer Action: Define who can approve sensitivity statements and when a separate Article 16\(2\) PEC review is escalated to counsel\. Evidence to close: A reviewed disclosure note identifies the specific sensitive information, the stated harm, the handling decision and the next review point\. An unqualified confidentiality label is insufficient\. ### 12. final-close — The case preserves filing, remediation and review evidence Priority: P3 | Current rating: Gap Proposed target: Days 15–30 of preparation Accountable role: Product-security case owner — Product Security Lead Action: Archive submission receipts, field versions, approvals, remediation evidence and lessons learned together\. Evidence to close: A colleague can retrieve the submitted versions, receipts, approvals, remediation evidence and lessons learned from one controlled case archive\. Retention and access owners are named\. ### 13. final-severity — Final severity rationale is evidence-backed Priority: P3 | Current rating: Partial Proposed target: Days 15–30 of preparation Accountable role: Product-security case owner — Product Security Lead Action: Attach the final severity calculation, affected versions and reviewer approval to the case\. Evidence to close: The final assessment states the severity method, relevant factors, affected releases, evidence references and reviewer approval\. A bare severity label does not close this action\. ### 14. final-impact — Actual and potential impact are bounded Priority: P3 | Current rating: Partial Proposed target: Days 15–30 of preparation Accountable role: Engineering remediation lead — Release Engineering Lead Action: Complete an impact inventory and explicitly document where no evidence was found\. Evidence to close: An impact record distinguishes actual from potential effects on products, functions, data and users\. Statements that no evidence was found include the investigation's coverage limits\. ### 15. final-cause — Root cause and actor statements distinguish fact from inference Priority: P3 | Current rating: Partial Proposed target: Days 15–30 of preparation Accountable role: Engineering remediation lead — Release Engineering Lead Action: Use confirmed / likely / unknown labels for cause, actor and exploitation narrative\. Evidence to close: The cause and actor narrative labels statements as confirmed, inferred or unknown and links material factual assertions to evidence\. Unsupported attribution is removed\. ## 5. Complete assessment — 20 checks ### 24-awareness — Awareness time is captured and defensible Rating: Ready Accountable role: Product-security case owner — Product Security Lead Why it matters: The statutory clock starts at awareness; the team can point to a timestamp and supporting record\. Evidence to retain: A dated intake record identifies the awareness time in UTC, the source evidence and the person who recorded it\. A second reviewer can reconstruct the starting point\. ### 24-trigger — Reportability can be decided without waiting for root cause Rating: Partial Accountable role: Product-security case owner — Product Security Lead Why it matters: The owner can distinguish an actively exploited vulnerability from a severe incident and record uncertainty\. Follow-up and closure evidence: action 24-trigger in section 4. ### 24-srp — A working EU Login and assigned representative exist Rating: Gap Accountable role: Primary SRP submitter — Regulatory Operations Lead Why it matters: At launch, submission is through the SRP interface rather than an API\. Follow-up and closure evidence: action 24-srp in section 4. ### 24-csirt — The coordinating CSIRT is pre-identified Rating: Ready Accountable role: Product-security case owner — Product Security Lead Why it matters: The coordinating CSIRT is normally determined from the manufacturer's main EU establishment; the team has recorded the correct route and fallback\. Evidence to retain: The runbook identifies the coordinating authority, the route\-selection rationale, a fallback and the reviewer\. The submitter can locate that record without asking another team\. ### 24-product — Product name and affected version range are available in under four hours Rating: Ready Accountable role: Engineering remediation lead — Release Engineering Lead Why it matters: Both are required in the early warning and should match controlled product records\. Evidence to retain: A timed lookup produces the controlled product name and affected release range, including the source record and its owner, within the team's four\-hour exercise target\. ### 24-countries — Member States of product availability can be identified Rating: Partial Accountable role: User communications owner — Customer Communications Lead Why it matters: The SRP uses known product availability to determine concerned CSIRTs\. Follow-up and closure evidence: action 24-countries in section 4. ### 24-summary — A concise, factual early-warning summary can be approved Rating: Gap Accountable role: Regulatory review owner — Compliance Reviewer Why it matters: The team can state known facts without adding speculative attribution or unnecessary sensitive detail\. Follow-up and closure evidence: action 24-summary in section 4. ### 24-cover — A backup owner can act outside business hours Rating: Partial Accountable role: Backup SRP submitter — Engineering On\-call Why it matters: The clock does not pause for leave, weekends or internal approval queues\. Follow-up and closure evidence: action 24-cover in section 4. ### 72-evidence — Technical evidence is assembled into one case Rating: Partial Accountable role: Product-security case owner — Product Security Lead Why it matters: Affected versions, exploitation evidence, mitigations and unresolved questions remain traceable\. Follow-up and closure evidence: action 72-evidence in section 4. ### 72-assessment — An initial severity and impact assessment can be produced Rating: Partial Accountable role: Product-security case owner — Product Security Lead Why it matters: The 72\-hour notification needs an initial assessment that separates confirmed findings from investigation\. Follow-up and closure evidence: action 72-assessment in section 4. ### 72-measures — Completed mitigation and user measures are documented Rating: Gap Accountable role: Engineering remediation lead — Release Engineering Lead Why it matters: Corrective measures taken and measures users can take are required at the notification stage\. Follow-up and closure evidence: action 72-measures in section 4. ### 72-versions — Third-party component exposure maps to supported and legacy releases Rating: Gap Accountable role: Engineering remediation lead — Release Engineering Lead Why it matters: A component vulnerability can affect the final product manufacturer and older products may still be in scope for reporting\. Follow-up and closure evidence: action 72-versions in section 4. ### 72-sensitive — Sensitive information has a specific handling decision Rating: Partial Accountable role: Regulatory review owner — Compliance Reviewer Why it matters: A generic confidentiality label is not enough; identify the sensitive detail and the harm from premature or wider disclosure\. Follow-up and closure evidence: action 72-sensitive in section 4. ### 72-legal — Legal or regulatory review fits inside the remaining clock Rating: Gap Accountable role: Regulatory review owner — Compliance Reviewer Why it matters: A review queue that takes days makes the reporting procedure unusable\. Follow-up and closure evidence: action 72-legal in section 4. ### 72-comms — User communications and customer support share one approved message Rating: Ready Accountable role: User communications owner — Customer Communications Lead Why it matters: Mitigation instructions should be consistent across SRP fields, advisories and support responses\. Evidence to retain: One versioned advisory is approved and used by the reporting, customer\-support and communications owners\. Workaround wording and known limitations agree across copies\. ### final-fix — Corrective-measure availability time is recorded Rating: Ready Accountable role: Engineering remediation lead — Release Engineering Lead Why it matters: For an actively exploited vulnerability, this timestamp anchors the 14\-day final\-report deadline\. Evidence to retain: A controlled milestone records when the corrective or mitigating measure first became available externally, with a UTC timestamp and supporting release or publication record\. ### final-severity — Final severity rationale is evidence-backed Rating: Partial Accountable role: Product-security case owner — Product Security Lead Why it matters: The final report needs more than a rating; it needs classification and supporting factors\. Follow-up and closure evidence: action final-severity in section 4. ### final-impact — Actual and potential impact are bounded Rating: Partial Accountable role: Engineering remediation lead — Release Engineering Lead Why it matters: The report should identify affected products, data, functions, users and connected systems\. Follow-up and closure evidence: action final-impact in section 4. ### final-cause — Root cause and actor statements distinguish fact from inference Rating: Partial Accountable role: Engineering remediation lead — Release Engineering Lead Why it matters: Unconfirmed attribution should not be presented as fact\. Follow-up and closure evidence: action final-cause in section 4. ### final-close — The case preserves filing, remediation and review evidence Rating: Gap Accountable role: Product-security case owner — Product Security Lead Why it matters: A defensible record connects the submission stages to remediation and post\-incident improvement\. Follow-up and closure evidence: action final-close in section 4. ## 6. Retest and acceptance 1. Assign any missing owner before accepting an action\. Confirm the proposed preparation targets with the team; they are not incident\-reporting deadlines\. 2. For each open action, retain the evidence described in its closure criterion in your own controlled case or runbook\. This tool does not collect or verify that evidence\. 3. Have a second authorised person repeat the relevant lookup, approval or handover\. Record the date, elapsed time, outcome and remaining limitation\. 4. Change a rating to Ready only when the capability, named owner and current evidence can be demonstrated\. A higher aggregate score must not conceal an unresolved reporting blocker\. 5. Save the dated exercise JSON and report\. Re\-run the scenario after material product, staffing or process changes and compare the open action IDs\. ### How to interpret the score Ready = 2; Partial = 1; Gap or unanswered = 0; N/A is excluded from the stage denominator\. The 24\-hour score is 75% capability score and 25% named\-role coverage\. Overall weighting: 24\-hour 50%, 72\-hour 32%, final 18%\. Stage values are rounded before aggregation\. If every check in a stage is N/A, that stage scores zero\. Bands: below 60 Not ready; 60–79 At risk; 80–100 Operationally ready\. No answers means Not assessed\. These are self\-reported indicators, not independent verification or proof of compliance\. --- Independent technical preparation aid. Not legal advice, an official filing, certification or conformity assessment. Verify against current official CRA and ENISA material.