Article 14 Ready · v1.0.2
Product-team readiness report
Generated via https://article14ready.com
Example Device Labs (fictional) · Atlas Gateway 4.x
Generated: 2026-09-09T12:00:00.000Z · 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.
5 Ready · 9 Partial · 6 Gap · 0 Unanswered · 0 N/A
24-hour: 67% · 72-hour: 36% · Final: 50% · Named roles: 6/6
All six roles have an entry. Naming a role does not prove availability or authorised access.
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 following incident 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 — Product Security Lead
Own the case, awareness record, trigger decision and evidence trail.
Primary SRP submitter — Regulatory Operations Lead
Maintain authorised submission access and retain submission records.
Backup SRP submitter — Engineering On-call
Cover absence and prove that the reporting handover works.
Engineering remediation lead — Release Engineering Lead
Maintain affected-release, technical-impact and corrective-measure evidence.
Regulatory review owner — Compliance Reviewer
Review the reporting position and sensitive-content decisions within the agreed review window.
User communications owner — Customer Communications Lead
Keep product-availability records and approved user instructions consistent.
4. Prioritised preparation plan
P1 covers early-warning preparation; P2 the notification stage; P3 final reporting and closure. Gaps come before partial capabilities within each group. The 30-day 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
P1 · Gap · 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
P1 · Gap · 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
P1 · Partial · 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
P1 · Partial · 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
P1 · Partial · 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
P2 · Gap · 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
P2 · Gap · 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
P2 · Gap · 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
P2 · Partial · 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
P2 · Partial · 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
P2 · Partial · 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
P3 · Gap · 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
P3 · Partial · 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
P3 · Partial · 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
P3 · Partial · 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
Ready · Product-security case owner — Product Security Lead
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
Partial · Product-security case owner — Product Security Lead
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
Gap · Primary SRP submitter — Regulatory Operations Lead
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
Ready · Product-security case owner — Product Security Lead
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
Ready · Engineering remediation lead — Release Engineering Lead
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
Partial · User communications owner — Customer Communications Lead
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
Gap · Regulatory review owner — Compliance Reviewer
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
Partial · Backup SRP submitter — Engineering On-call
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
Partial · Product-security case owner — Product Security Lead
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
Partial · Product-security case owner — Product Security Lead
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
Gap · Engineering remediation lead — Release Engineering Lead
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
Gap · Engineering remediation lead — Release Engineering Lead
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
Partial · Regulatory review owner — Compliance Reviewer
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
Gap · Regulatory review owner — Compliance Reviewer
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
Ready · User communications owner — Customer Communications Lead
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
Ready · Engineering remediation lead — Release Engineering Lead
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
Partial · Product-security case owner — Product Security Lead
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
Partial · Engineering remediation lead — Release Engineering Lead
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
Partial · Engineering remediation lead — Release Engineering Lead
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
Gap · Product-security case owner — Product Security Lead
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
- Assign any missing owner before accepting an action. Confirm the proposed preparation targets with the team; they are not incident-reporting deadlines.
- 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.
- Have a second authorised person repeat the relevant lookup, approval or handover. Record the date, elapsed time, outcome and remaining limitation.
- 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.
- 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.