Full sample, no email gate

A real sample CRA reporting pack

Generated on 2026-10-28 for Northwind Ledger, a fictional B2B SaaS manufacturer. The intake answers were written for this sample; the documents come from the same pipeline a paid order runs. It is not legal advice, not certification, and not a conformity assessment.

CRA Article 14 Reporting Runbook: Northwind Ledger Cloud

Based on answers provided by Northwind Ledger on 2026-10-28. Self-attested by the manufacturer; not audited, certified, a conformity assessment, or legal advice.

Notice: This runbook is not legal advice and not a conformity assessment. It organises Northwind Ledger's own intake answers into an operational sequence. Whether and how CRA Article 14 applies to a specific event should be confirmed with counsel.

1. Scope

This runbook covers Northwind Ledger Cloud, a B2B SaaS / web application made by Northwind Ledger. The product is available in the EU to customers in Germany and the Netherlands, and EU users are not blocked.

It covers two kinds of event:

Actively exploited vulnerabilities in Northwind Ledger Cloud.
Severe incidents affecting the security of Northwind Ledger Cloud.

Affected versions and releases are identified using Git tags, Vercel deployment IDs, and customer-visible release notes.

The security contact is security@northwind.example.

2. When to Open This Runbook

Open this runbook when any of the following sources raises a possible actively exploited vulnerability or severe security incident:

The security mailbox (security@northwind.example)
GitHub private advisories
Snyk
npm audit
GitHub Dependabot
Manufacturer advisories
Customer support escalations

The product security lead makes the first triage decision. The engineering manager approves severity.

Severity and exploitation likelihood are assessed using four inputs:

CVSS score
Known exploitation signals
Customer impact
Whether the affected component is internet-facing

Track all triage work in the Jira Security project. Apply the existing labels for customer-impacting issues.

If exploitation signals are present, or the event may be a severe incident, treat the reporting clock as potentially running. Proceed to Section 3 without waiting for full certainty.

3. First 24 Hours: Early Warning

The fixed timing for this stage is that an early warning is due within 24 hours.

Current practice:

The product security lead triages the event and records it in the Jira Security project.
The engineering manager approves the severity rating.
Record affected versions using Git tags and Vercel deployment IDs.
Note whether the affected component is internet-facing and what customer impact is known.
Check whether the affected component appears in the CycloneDX SBOM generated in GitHub Actions for the web app.
Use the Notion incident-response page for general incident coordination.

Open gaps at this stage:

No owner is documented for the 24-hour early-warning decision.
The Notion incident-response page has not yet been rehearsed for CRA Article 14 reporting.
Worker images are not covered by the SBOM, so component lookups for worker images cannot rely on it.

Until an owner is assigned, escalate the early-warning decision promptly. Record who made the decision, and when, in the Jira ticket. See the Gap Register (GR-1).

4. By 72 Hours: Full Notification

The fixed timing for this stage is that a full notification is due within 72 hours.

Current practice:

The product security lead drafts the 72-hour full notification.
Legal reviews the draft before submission, where time allows.
External counsel reviews regulatory language when available.
The founder approves urgent operational updates.
Update the Jira ticket with:
- Current severity
- Affected versions
- Exploitation status
- Fix status
When a fix is in progress, it follows the standard release process:
- Pull request review
- Preview deploy
- Production deploy
- Release notes
- Customer notification when needed

If legal or external counsel review cannot happen within the window, record that fact and the reason in the Jira ticket.

5. Final Report Timing

The fixed timing for this stage depends on the event type:

Event type	Final report due
Actively exploited vulnerability	No later than 14 days after a corrective measure is available
Severe incident	Within one month

Use these anchors to fix the deadline:

For a vulnerability, the production deploy recorded against a Vercel deployment ID, together with the corresponding release notes, shows when the corrective measure became available.
For a severe incident, record the date of the 72-hour notification in Jira so the one-month window can be tracked.

Open gaps at this stage:

No owner is assigned for the final report.
No final-report template exists.

See the Gap Register (GR-2 and GR-3).

6. Roles and Backups

Role	Responsibility	Current status
Product security lead	First triage; drafts 72-hour notification	In place
Engineering manager	Approves severity	In place
Legal	Reviews full notification before submission where time allows	In place
External counsel	Reviews regulatory language when available	In place
Founder	Approves urgent operational updates	In place
24-hour early-warning owner	Early-warning decision	Not yet assigned (GR-1)
Final report owner	Final report	Not yet assigned (GR-2)

Backups: The intake did not name backups for any role. Backup coverage is not yet defined and is recorded as GR-6.

7. Evidence to Collect

Store evidence in the locations Northwind Ledger already uses:

Location	What to keep
Jira Security project	Triage record, severity approval, timestamps of decisions and submissions, review notes
GitHub Actions artifacts	CycloneDX SBOM for the web app; build records for the fix
Snyk reports	Scanner findings for the affected component
Release changelog	Release notes for the corrective release; Git tag and Vercel deployment ID
Customer notification mailbox	Copies of any customer notifications sent

Also keep the originating alert from its source, for example the GitHub private advisory, the Dependabot alert, npm audit output, the manufacturer advisory, or the support escalation. Link it from the Jira ticket.

8. Gap Register

These items are not yet in place. They must not be presented as current practice.

ID	Gap	Current state	Owner
GR-1	24-hour CRA early-warning owner	No documented owner	Not yet assigned
GR-2	Final report owner	Not defined	Not yet assigned
GR-3	Final-report template	Does not exist	Not yet assigned
GR-4	Public support-period statement	No support or security-update period communicated to customers	Not yet assigned
GR-5	Reporting drill	No CRA Article 14 reporting drill has been rehearsed; the Notion incident-response page has not been exercised for this purpose	Not yet assigned
GR-6	Role backups	No backups defined for any reporting role	Not yet assigned
GR-7	SBOM coverage for worker images	CycloneDX SBOM covers the web app only; worker images are not yet covered	Not yet assigned

Planned work: Northwind Ledger has not set target dates for closing these gaps. Dates are not yet defined.

This runbook is not legal advice and not a conformity assessment. It reflects self-attested answers from Northwind Ledger and has not been independently verified.

24-Hour Early Warning: Draft Template

Based on answers provided by Northwind Ledger on 2026-10-28. Self-attested by the manufacturer; not audited, certified, a conformity assessment, or legal advice.

Notice: This document is not legal advice and not a conformity assessment. It is a working draft that organizes information Northwind Ledger provided about its own practices. Have qualified counsel review any regulatory submission.

Purpose

This template structures an early warning for an actively exploited vulnerability or a severe incident affecting Northwind Ledger Cloud. Under the CRA, the early warning is due within 24 hours of the manufacturer becoming aware.

Rule for incident facts: Leave unknown facts marked as unknown. Do not guess. Mark a field "Unknown at time of submission" rather than estimating.

Product and Manufacturer

Field	Value
Manufacturer	Northwind Ledger
Product	Northwind Ledger Cloud
Product type	B2B SaaS / web application
Security contact	security@northwind.example
EU availability	Customers in Germany and the Netherlands; EU users are not blocked.

Notification Type

Actively exploited vulnerability
Severe incident affecting the security of the product

Incident-Specific Details

Field	Value
Internal reference (Jira Security project)	[jira_ticket_id]
Vulnerability identifier, if any	[vulnerability_id]
Date and time Northwind Ledger became aware	[awareness_timestamp]
Source of the report or detection	[detection_source]
Brief description of what is known	[summary_known_facts]
Exploitation status	[exploitation_status]
Suspected unlawful or malicious cause (severe incidents)	[malicious_cause_status]
Affected versions or releases	[affected_versions]
Member States where the product is made available	[member_states]
Submission reference	[submission_reference]

Detection Source Options (from current intake)

The following channels can receive vulnerability or severe-incident reports today:

Security mailbox (security@northwind.example)
GitHub private advisories
Snyk
npm audit
Customer support escalations

Identifying Affected Versions

Northwind Ledger identifies affected versions or releases using:

Git tags
Vercel deployment IDs
Customer-visible release notes

Current Triage Practice

The product security lead performs the first triage.
The engineering manager approves severity.
Severity and exploitation likelihood are judged using CVSS, known exploitation signals, customer impact, and whether the affected component is internet-facing.
Triage work is tracked in the Jira Security project, with labels for customer-impacting issues.

Review Before Submission

External counsel reviews regulatory language when available.
The founder approves urgent operational updates.

Ownership of the Early-Warning Decision

See the Gap Register. No owner is currently documented for this decision.

Gap Register (Items Not Yet in Place)

Gap	Status
Owner of the 24-hour early-warning decision	Not yet assigned
Reporting drill for CRA reporting	Not yet performed
Incident-response process rehearsal for CRA Article 14	Not yet rehearsed. A Notion incident-response page exists.
Public support-period statement	Not yet defined

72-Hour Full Notification: Draft Template

Based on answers provided by Northwind Ledger on 2026-10-28. Self-attested by the manufacturer; not audited, certified, a conformity assessment, or legal advice.

Notice: This document is not legal advice and not a conformity assessment. It is a working draft that organizes information Northwind Ledger provided about its own practices. Have qualified counsel review any regulatory submission.

Purpose

This template structures the full notification that follows the early warning. Under the CRA, it is due within 72 hours of the manufacturer becoming aware.

Rule for incident facts: Leave unknown facts marked as unknown. Do not guess. If something is still being investigated, say so.

Ownership (from current intake)

The product security lead drafts this notification.
Legal reviews before submission where time allows.
External counsel reviews regulatory language when available.
The founder approves urgent operational updates.

Product and Manufacturer

Field	Value
Manufacturer	Northwind Ledger
Product	Northwind Ledger Cloud
Product type	B2B SaaS / web application
Security contact	security@northwind.example

Reference to Early Warning

Field	Value
Early-warning submission reference	[early_warning_reference]
Internal reference (Jira Security project)	[jira_ticket_id]
This submission's reference	[submission_reference]

Incident-Specific Details

Field	Value
Vulnerability identifier, if any	[vulnerability_id]
General nature of the vulnerability or incident	[nature_description]
Affected versions or releases (Git tag / Vercel deployment ID / release note)	[affected_versions]
Exploitation status and exploit details known	[exploitation_status]
Initial severity assessment	[severity_assessment]
Impact assessment	[impact_assessment]
Corrective or mitigating measures taken	[corrective_measure]
Measures users can take	[user_mitigation]
Sensitivity of information provided	[sensitivity_note]

Severity Basis (from current intake)

Severity was assessed using:

CVSS
Known exploitation signals
Customer impact
Whether the affected component is internet-facing

The engineering manager approves the severity rating.

Component Inventory Basis

A CycloneDX SBOM is generated in GitHub Actions for the web app. Worker images are not yet covered. If a worker image may be affected, state that the SBOM does not cover it.

Fix and Communication Status (from current release process)

Fixes ship through these steps:

Pull request review
Preview deploy
Production deploy
Release notes
Customer notification when needed

Step	Status
Pull request	[pr_reference]
Preview deploy	[preview_deploy_id]
Production deploy	[production_deploy_id]
Release notes entry	[release_note_reference]
Customer notification sent	[customer_notification_status]

Evidence Locations

GitHub Actions artifacts
Jira tickets
Release changelog
Customer notification mailbox
Snyk reports

Gap Register (Items Not Yet in Place)

Gap	Status
Owner of the 24-hour early-warning decision	Not yet assigned
Owner of the final report	Not yet assigned
SBOM coverage of worker images	Not yet in place
Reporting drill for CRA reporting	Not yet performed
Public support-period statement	Not yet defined

Final Report: Draft Template

Based on answers provided by Northwind Ledger on 2026-10-28. Self-attested by the manufacturer; not audited, certified, a conformity assessment, or legal advice.

Notice: This document is not legal advice and not a conformity assessment. It is a working draft that organizes information Northwind Ledger provided about its own practices. Have qualified counsel review any regulatory submission.

Purpose

This template structures the final report. Under the CRA, the deadline depends on the notification type:

Actively exploited vulnerabilities: no later than 14 days after a corrective measure is available.
Severe incidents: within one month.

Northwind Ledger reported that it had no final-report template before this draft. This document is a first draft only.

Rule for incident facts: Leave unknown facts marked as unknown. Do not guess. If root cause or impact is not established, state that plainly.

Ownership

No final-report owner is currently documented. See the Gap Register.

The review practice from current intake is:

External counsel reviews regulatory language when available.
The founder approves urgent operational updates.

Product and Manufacturer

Field	Value
Manufacturer	Northwind Ledger
Product	Northwind Ledger Cloud
Security contact	security@northwind.example

Report Type

Actively exploited vulnerability. The final report is due no later than 14 days after the corrective measure is available.
Severe incident. The final report is due within one month.

Prior Submissions

Field	Value
Early-warning reference	[early_warning_reference]
Full notification reference	[full_notification_reference]
This submission's reference	[submission_reference]
Internal reference (Jira Security project)	[jira_ticket_id]

Incident-Specific Details

Field	Value
Vulnerability identifier, if any	[vulnerability_id]
Description, including severity and impact	[final_description]
Malicious actor information, if known	[actor_information]
Root cause, if established	[root_cause]
Affected versions or releases	[affected_versions]
Corrective measure and date available	[corrective_measure] / [corrective_measure_date]
Security update or mitigation details	[mitigation_details]
Fixed release (Git tag / Vercel deployment ID / release note)	[fixed_release]
Customer communication summary	[customer_communication_summary]

Supporting Evidence

Attach or reference evidence from these locations:

GitHub Actions artifacts, including the CycloneDX SBOM for the web app
Jira tickets
Release changelog
Customer notification mailbox
Snyk reports

Gap Register (Items Not Yet in Place)

Gap	Status
Owner of the final report	Not yet assigned
Approved final-report template	Not yet defined. This draft has not been adopted or reviewed.
Owner of the 24-hour early-warning decision	Not yet assigned
Public support-period statement	Not yet defined
SBOM coverage of worker images	Not yet in place
Reporting drill for CRA reporting	Not yet performed
Incident-response process rehearsal for CRA Article 14	Not yet rehearsed. A Notion incident-response page exists.

Evidence Register: Northwind Ledger Cloud

Based on answers provided by Northwind Ledger on 2026-10-28. Self-attested by the manufacturer; not audited, certified, a conformity assessment, or legal advice.

Not legal advice. Not a conformity assessment. This register records only what Northwind Ledger stated in its intake answers. It does not establish whether any obligation under the EU Cyber Resilience Act (CRA) is met. Northwind Ledger should confirm its obligations with qualified counsel.

Scope

Manufacturer: Northwind Ledger
Product: Northwind Ledger Cloud (B2B SaaS / web application)
EU availability: Customers in Germany and the Netherlands. EU users are not blocked.
Security contact: security@northwind.example
Version identification: Git tags, Vercel deployment IDs, and customer-visible release notes.

Reporting Timing Reference

These are the only fixed CRA reporting timing points used in this register:

Early warning: within 24 hours.
Full notification: within 72 hours.
Final report for actively exploited vulnerabilities: no later than 14 days after a corrective measure is available.
Final report for severe incidents: within one month.

Current Evidence Register

"Not stated in intake" means the intake answers did not name an owner for that item. It does not mean no one does the work.

Evidence item	Source / location	Owner	When it is needed	Current gap
SBOM / component inventory	CycloneDX SBOM generated in GitHub Actions for the web app; stored as GitHub Actions artifacts	Not stated in intake	During triage, to identify affected components. Also supports the 24-hour early warning, the 72-hour full notification, and final reports.	Worker images are not yet covered by the SBOM.
Scanner alerts	Snyk, npm audit, GitHub Dependabot, and manufacturer advisories. Snyk reports are kept as evidence.	Product security lead triages. Engineering manager approves severity.	When an alert arrives and through triage. Supports all reporting stages.	None stated in intake.
Triage and severity records	Jira Security project, with labels for customer-impacting issues	Product security lead triages. Engineering manager approves severity.	From first triage onward. Supports the 24-hour, 72-hour, and final-report stages.	None stated for ticketing. The CRA early-warning decision owner is not yet assigned (see Gap Register).
Severity rationale	Jira tickets. The severity model uses CVSS, known exploitation signals, customer impact, and whether the affected component is internet-facing.	Engineering manager approves severity.	At triage. Feeds the decision on whether a vulnerability is actively exploited and whether the early warning applies.	The early-warning decision owner is not yet assigned.
Vulnerability and incident intake records	Security mailbox (security@northwind.example), GitHub private advisories, Snyk, npm audit, and customer support escalations	Product security lead (first triage)	On receipt. The receipt time may matter for the 24-hour early warning.	None stated in intake.
Advisories	GitHub private advisories (inbound). Manufacturer advisories (scanner source).	Product security lead (triage)	During triage and remediation. Referenced in the full notification and final reports.	No outbound advisory format or owner is described in intake.
Release and fix records	Pull request review, preview deploy, production deploy, Git tags, Vercel deployment IDs, and release changelog / release notes	Not stated in intake for release approval	When a corrective measure is available. This starts the 14-day final-report window for actively exploited vulnerabilities.	No owner is named for release evidence.
Customer notices	Customer notification mailbox. Customer notification is sent "when needed" according to the release process.	Founder approves urgent operational updates. External counsel reviews regulatory language when available.	When customer action or awareness is needed during or after remediation.	No criteria for "when needed" are stated in intake.
Support-period statement	None	Not yet assigned	Communicated to customers. Relevant to affected-version scope in reports.	No public support-period statement exists (see Gap Register).
72-hour full notification draft	Not stated in intake. Likely Jira or the notification mailbox, but this is unconfirmed.	Product security lead drafts. Legal reviews before submission where time allows.	Within 72 hours	The storage location for drafts is not defined. Legal review depends on time available.
Submission records (early warning, full notification, final report)	Not listed among the evidence locations in intake	Full notification: product security lead. Early warning: not yet assigned. Final report: not yet assigned.	At each submission: 24 hours, 72 hours, and the final-report deadlines	No defined location for submission records. Early-warning and final-report owners are not yet assigned.
Incident-response procedure	Notion incident-response page	Not stated in intake	Before and during any reportable event	Not yet rehearsed specifically for CRA Article 14 reporting.

Gap Register

These items are not yet in place. They are not current practice.

#	Gap	Status	Owner
G1	Owner for the 24-hour CRA early-warning decision	Not yet in place	Not yet assigned
G2	Owner for the final report after corrective measures or severe incidents	Not yet in place	Not yet assigned
G3	Final-report template	Not yet in place	Not yet assigned
G4	Public support-period / security-update period statement	Not yet in place	Not yet assigned
G5	Reporting drill (CRA Article 14 rehearsal)	Not yet in place. No drill history.	Not yet assigned
G6	SBOM coverage of worker images	Not yet in place	Not yet assigned
G7	Defined location for regulatory submission records	Not defined in intake	Not yet assigned
G8	Defined owner for SBOM and release evidence	Not defined in intake	Not yet assigned

Notes

Legal review of the 72-hour notification happens "where time allows." Reports may therefore be submitted without counsel review. This is a stated condition, not a resolved gap.
External counsel reviews regulatory language "when available." No backup reviewer is named in intake.

This register is a self-attested working document. It is not legal advice and not a conformity assessment.

Vulnerability Intake and Triage Policy: Northwind Ledger Cloud

Based on answers provided by Northwind Ledger on 2026-10-28. Self-attested by the manufacturer; not audited, certified, a conformity assessment, or legal advice.

1. Purpose and Status

This policy describes how Northwind Ledger receives, triages, and escalates vulnerabilities and severe security incidents affecting Northwind Ledger Cloud, a B2B SaaS / web application. It also describes how triage work is handed to the people responsible for reporting.

This document is not legal advice and not a conformity assessment. It records what Northwind Ledger says it does today and lists known gaps separately. It does not decide whether any specific obligation applies to Northwind Ledger or to any particular vulnerability or incident. That decision belongs with Northwind Ledger and its counsel.

EU market context (as reported): Northwind Ledger has customers in Germany and the Netherlands. EU users are not blocked.

2. Scope

This policy covers:

Vulnerabilities in Northwind Ledger Cloud and its components.
Severe security incidents affecting Northwind Ledger Cloud.

Section 7 describes component inventory coverage. The CycloneDX SBOM covers the web app. Worker images are not yet covered (see Gap Register, G5).

3. Intake Sources

Vulnerabilities and severe security incidents can currently arrive through the following channels:

Source	Description
Security mailbox	security@northwind.example receives vulnerability reports
GitHub private advisories	Privately reported advisories on GitHub
Snyk	Scanner findings
npm audit	Dependency audit findings
GitHub Dependabot	Dependency alerts
Manufacturer advisories	Advisories published by upstream component manufacturers
Customer support escalations	Security issues raised by customers through support

Snyk, npm audit, GitHub Dependabot, and manufacturer advisories are also the recorded sources of scanner and alert evidence.

4. Routing

Every item from any source in Section 3 is routed to the product security lead for first triage.
Triage work is tracked in the Jira Security project.
Issues that affect customers carry the customer-impacting label in that project.
Reports from the security mailbox and from customer support escalations should be recorded in Jira so the original report and triage history stay together.

5. Severity Assessment

Who decides

Product security lead: makes the first triage decision.
Engineering manager: approves the severity.

Factors considered

Severity is based on four factors:

CVSS score.
Known exploitation signals.
Customer impact.
Exposure: whether the affected component is internet-facing.

The intake does not define named severity tiers or CVSS thresholds, so this policy does not state any. The reasoning behind each factor should be recorded in the Jira ticket.

6. Exploitation Assessment

As part of triage, the product security lead assesses whether there are known exploitation signals for the vulnerability. The result should be recorded in the Jira ticket together with the evidence relied on. Examples of such evidence include manufacturer advisories, scanner data, and customer reports.

If a vulnerability appears to be actively exploited, or an incident appears to be severe, the ticket is escalated for a reporting decision under Section 8. Whether a given case meets a legal reporting threshold is not decided by this policy.

7. Version and Release Impact

Affected versions and releases are identified using three references:

Git tags.
Vercel deployment IDs.
Customer-visible release notes.

The Jira ticket should record which of these identifiers are affected and which contain the fix.

The CycloneDX SBOM generated in GitHub Actions can be used to check whether the web app contains an affected component. It does not cover worker images, so the SBOM alone cannot settle component exposure for those images (see Gap Register, G5).

8. Escalation and Handoff to Reporting Owners

Reporting timings

The CRA reporting timings referenced in this policy are:

Early warning: within 24 hours.
Full notification: within 72 hours.
Final report for actively exploited vulnerabilities: no later than 14 days after a corrective measure is available.
Final report for severe incidents: within one month.

Reporting owners

Reporting stage	Owner (as reported)
24-hour early warning decision	Not yet assigned (Gap G1)
72-hour full notification	Product security lead drafts. Legal reviews before submission where time allows.
Final report	Not yet assigned (Gap G2)

Review of notification language

Regulatory language: external counsel reviews it when available.
Urgent operational updates: the founder approves them.

Current handoff practice

The product security lead and engineering manager carry the triage outcome forward from the Jira ticket. Two parts of the handoff have no defined owner:

No one is designated to decide on the 24-hour early warning.
No one is designated to own the final report.

Both are recorded as gaps and are not described here as current practice.

9. Remediation and Communication

Fixes ship through the following steps:

Pull request review.
Preview deploy.
Production deploy.
Release notes.
Customer notification when needed.

The Jira ticket should link to the pull request, the deployment identifiers, and the release note entry.

10. Evidence Preservation

Evidence for triage and reporting is kept in these locations:

Location	Evidence held
GitHub Actions artifacts	Including CycloneDX SBOM output
Jira tickets	Security project
Release changelog	Release history
Customer notification mailbox	Customer notifications
Snyk reports	Scanner findings

Each Jira ticket should reference the related evidence in these locations so that the timeline from intake to fix to communication can be reconstructed. The intake does not define a retention period, so this policy does not state one.

11. Incident Response Linkage

Northwind Ledger keeps an incident-response page in Notion. That process has not yet been rehearsed specifically for CRA Article 14 reporting (see Gap Register, G4).

12. Gap Register

These items are not yet in place. They are listed so they are not mistaken for current practice.

ID	Gap	Current state
G1	Owner of the 24-hour early-warning decision	Not yet assigned. No documented 24h CRA early-warning owner.
G2	Owner of the final report	Not yet assigned.
G3	Final-report template	Not yet defined.
G4	Reporting drill	None held yet. The Notion incident-response page has not been rehearsed for CRA Article 14 reporting.
G5	SBOM coverage of worker images	Not yet covered. The SBOM covers the web app only.
G6	Support / security-update period	Not yet defined. There is no public support-period statement.

13. Planned Work

Northwind Ledger has not provided target dates, owners, or a plan for closing the gaps above. This section records only that each item in Section 12 remains open. Owners and timelines are not yet assigned or defined.

Northwind Ledger Cloud — CRA Article 14 Reporting Tabletop Drill

Based on answers provided by Northwind Ledger on 2026-10-28. Self-attested by the manufacturer; not audited, certified, a conformity assessment, or legal advice.

About This Document

This is a tabletop exercise for rehearsing the reporting workflow for Northwind Ledger Cloud, a B2B SaaS / web application. It is not legal advice and not a conformity assessment. It does not determine whether the CRA applies to this product or how. It does not confirm that any obligation has been met. Questions of scope and interpretation should go to counsel.

Every practice described here comes from Northwind Ledger's intake answers dated 2026-10-28. Practices that are not yet in place appear only in the Gap Register at the end.

Security reports contact: security@northwind.example

1. Drill Purpose and Scope

Purpose: Run the existing vulnerability and incident workflow against the CRA Article 14 reporting timelines. Record where the workflow holds and where it breaks.

Context from intake:

EU availability: Customers in Germany and the Netherlands. EU users are not blocked.
Existing process: A Notion incident-response page. It has not yet been rehearsed specifically for CRA Article 14 reporting.
Drill history: No reporting drill has been run before. This is the first one.

CRA reporting timing facts used in this drill:

Milestone	Timing
Early warning	Within 24 hours
Full notification	Within 72 hours
Final report (actively exploited vulnerability)	No later than 14 days after a corrective measure is available
Final report (severe incident)	Within one month

Facilitators should not add other deadlines during the exercise. The clock times in the scenarios below are drill timestamps only.

2. Participants (Roles from Intake)

Role	Responsibility stated in intake
Product security lead	Makes the first triage decision. Drafts the 72-hour full notification.
Engineering manager	Approves severity.
Legal / external counsel	Reviews the full notification before submission where time allows. Reviews regulatory language when available.
Founder	Approves urgent operational updates.
Facilitator	Runs the clock, injects prompts, records decisions and timestamps.
Note-taker	Records evidence references and gaps observed.

Roles without an owner (see Gap Register):

The 24-hour early-warning decision has no assigned owner.
The final report has no assigned owner.

The facilitator should record who acts in these roles during the drill. That record does not make the assignment permanent.

3. Existing Workflow Being Tested

Intake channels:

security mailbox (security@northwind.example)
GitHub private advisories
Snyk
npm audit
customer support escalations

Triage:

The product security lead triages.
The engineering manager approves severity.

Severity inputs:

CVSS
known exploitation signals
customer impact
whether the affected component is internet-facing

Tracking: Jira Security project, with labels for customer-impacting issues.

Version identification:

Git tags
Vercel deployment IDs
customer-visible release notes

Component inventory: A CycloneDX SBOM is generated in GitHub Actions for the web app. Worker images are not yet covered.

Scan and alert sources:

Snyk
npm audit
GitHub Dependabot
manufacturer advisories

Release path:

Pull request review
Preview deploy
Production deploy
Release notes
Customer notification when needed

Evidence locations:

GitHub Actions artifacts
Jira tickets
release changelog
customer notification mailbox
Snyk reports

Language review:

External counsel reviews regulatory language when available.
The founder approves urgent operational updates.

4. Scenario A — Actively Exploited Vulnerability

Setup Inject (T+0)

A Snyk alert and a GitHub Dependabot alert both flag a vulnerability in an npm dependency used by the Northwind Ledger Cloud web app. Within the hour, a customer in the Netherlands writes to the support team. They report suspicious requests against their tenant that match the published exploit pattern. Support escalates the report to the product security lead.

Timeline Prompts

Drill time	Prompt
T+0	Which intake channel registered the issue first? Who saw it, and when? Is a Jira Security ticket opened, and when?
T+1h	The product security lead begins triage. Which severity inputs apply (CVSS, exploitation signals, customer impact, internet-facing component)?
T+2h	The engineering manager is asked to approve severity. How is the approval recorded in Jira?
T+3h	Can the team confirm which releases are affected? Use Git tags, Vercel deployment IDs, and the CycloneDX SBOM. Is the component in the web app (covered by the SBOM) or in a worker image (not covered)?
T+6h	Inject: A second customer, in Germany, reports similar activity. Does this change the exploitation assessment?
T+12h	Who decides whether a 24-hour early warning is needed? (No owner is assigned. The facilitator records who acts and how the decision is made.)
T+20h	Is the early-warning content drafted? Who reviews it? Is external counsel available?
T+24h	Checkpoint: Has the early-warning decision been made and documented?
T+36h	The fix moves through pull request review and a preview deploy. What evidence is captured?
T+48h	Production deploy. Are release notes and the customer notification prepared? Does the founder approve the urgent customer update?
T+60h	The product security lead drafts the 72-hour full notification. Is legal review possible in the time left?
T+72h	Checkpoint: Has the full notification draft been completed and reviewed (or has the lack of review been recorded)?
Fix available + up to 14 days	Who owns the final report? What template is used? (Neither exists yet. The facilitator records how the team handles this.)

Decisions to Make

Does the evidence show active exploitation, or only exposure? What record supports the conclusion?
What severity is approved, and by whom?
Which versions and deployments are affected, based on Git tags and Vercel deployment IDs?
Does the affected component sit in the web app SBOM? If it sits in a worker image, how is it confirmed?
Who makes the 24-hour early-warning call, given that no owner is assigned?
Should affected customers be notified before the fix is deployed, after it, or both? Who approves the wording?
If counsel is unavailable before 72 hours, what happens to the full notification draft? How is that recorded?
Who will own the final report, and what will it contain?

Evidence to Attach

Snyk report and Dependabot alert for the dependency
npm audit output, if run
Customer support escalation records
Jira Security ticket, with labels, severity approval, and timestamps
CycloneDX SBOM artifact from GitHub Actions for the affected build
Git tags and Vercel deployment IDs for affected and fixed releases
Pull request, preview deploy, and production deploy records
Release changelog entry
Customer notification copies from the customer notification mailbox
Early-warning and full-notification drafts, with reviewer and timestamp notes

Pass/Fail Criteria

#	Criterion	Pass	Fail
A1	Issue logged in Jira Security with a timestamp	Ticket exists with the first-seen time	No ticket, or time unknown
A2	Severity triaged by the product security lead and approved by the engineering manager	Both actions recorded	Missing approval or no record
A3	Affected versions identified	Git tags and Vercel deployment IDs listed	Versions undetermined
A4	Component located in the inventory	Found in the SBOM, or the coverage gap is noted explicitly	Not checked
A5	Early-warning decision made and documented by the 24h drill mark	Decision, decision-maker, and rationale recorded	No decision by 24h
A6	Full notification drafted by the 72h drill mark	Draft exists; legal review done or its absence recorded	No draft
A7	Fix released through the documented release path	PR, preview, production, and release notes evidenced	Steps skipped without a record
A8	Final-report ownership and content addressed	Owner and outline recorded (even as a drill-only stand-in)	Not discussed

A drill can fail individual criteria and still be useful. Record each failure as a finding.

After-Action Questions

How long did the escalation from customer support to the product security lead take?
Did the severity inputs support a clear exploitation judgement? What was missing?
Could worker images have been ruled in or out without SBOM coverage?
Who acted as early-warning owner, and should that become a permanent assignment?
Was external counsel reachable in time? What is the fallback?
Did the Notion incident-response page help, or did people work around it?
What would a final-report template need to contain, based on this run?

5. Scenario B — Severe Security Incident

Setup Inject (T+0)

A message arrives at security@northwind.example. It reports that data belonging to a German customer's tenant appears accessible to another tenant through the Northwind Ledger Cloud web application. A customer support escalation arrives at the same time, describing the same behaviour.

Timeline Prompts

Drill time	Prompt
T+0	Who monitors the security mailbox, and how fast is the message seen? Is a Jira Security ticket opened with the customer-impacting label?
T+1h	The product security lead triages. What is the customer impact? Is the affected component internet-facing?
T+2h	The engineering manager approves severity. Is the incident treated as severe? On what basis?
T+4h	Which deployment introduced the behaviour? Check Vercel deployment IDs, Git tags, and release notes.
T+6h	Inject: Logs suggest that a worker process may also be involved. The SBOM does not cover worker images. How does the team establish what is running?
T+10h	What containment is applied, and how does it pass through the release process? Does the founder approve an urgent operational update to affected customers?
T+18h	Who decides whether an early warning is needed? (No owner is assigned.)
T+24h	Checkpoint: Has the early-warning decision been made and documented?
T+48h	Inject: A Dutch customer asks whether they are affected. Who answers, and with what approved wording?
T+60h	The product security lead drafts the full notification. Is external counsel available?
T+72h	Checkpoint: Has the full notification draft been completed, with review status recorded?
Within one month	Who owns the final report? What template is used? (Neither exists yet.)

Decisions to Make

Does this meet the team's threshold for a severe incident? Who decides, and on what inputs?
What containment is acceptable before a full fix?
Which customers are affected, and how is that determined?
Who makes the 24-hour early-warning call?
What may the team say to customers before counsel reviews it? The founder approves urgent operational updates; counsel reviews regulatory language when available.
How is worker-image involvement investigated without SBOM coverage?
Who owns the final report, which is due within one month?

Evidence to Attach

The original security mailbox message and the support escalation
Jira Security ticket, with customer-impacting label, severity approval, and timestamps
Vercel deployment IDs and Git tags for the suspected and remediated releases
CycloneDX SBOM artifact for the web app build
Any record of worker-image contents gathered during the drill
Pull request, preview deploy, and production deploy records for containment and fix
Release changelog entry
Customer notification copies, with approver noted
Early-warning and full-notification drafts, with review status

Pass/Fail Criteria

#	Criterion	Pass	Fail
B1	Report seen and logged with a timestamp	Jira ticket with the first-seen time and customer-impacting label	Not logged
B2	Severity triaged and approved by the stated roles	Both recorded	Missing
B3	Affected deployment identified	Vercel ID or Git tag recorded	Unknown
B4	Worker-image coverage gap handled	Gap acknowledged and an alternative method recorded	Ignored
B5	Customer communication approved by the stated approver	Founder approval (urgent) or counsel review recorded	Sent without a recorded approver
B6	Early-warning decision documented by the 24h drill mark	Decision, decision-maker, and rationale recorded	Missing
B7	Full notification drafted by the 72h drill mark	Draft exists with review status	No draft
B8	Final-report plan for the one-month window	Owner and outline recorded (drill-only stand-in acceptable)	Not discussed

After-Action Questions

Was the severe-incident judgement clear? Should written criteria exist?
How long did tenant-impact scoping take, and what slowed it down?
What was missing because worker images are not in the SBOM?
Did the split between founder approval and counsel review cause delay or confusion?
Who acted as early-warning owner, and was that the right person?
What did the absence of a final-report template cost the team in this run?
What should be added to the Notion incident-response page?

6. Facilitator Notes

Record real wall-clock time for each decision alongside the drill time.
Do not resolve gaps during the drill. Record them.
Keep all drill artifacts clearly labelled as exercise material. Do not send them externally.
Store drill outputs in the stated evidence locations (Jira, GitHub Actions artifacts) so the run itself becomes evidence of rehearsal.

7. Gap Register (Not Yet in Place)

These items were reported by Northwind Ledger as not yet in place. They are not current practice.

#	Gap	Current status	Drill relevance
G1	Owner for the 24-hour early-warning decision	Not yet assigned	Checkpoints A5 and B6 depend on an improvised owner
G2	Owner for the final report	Not yet assigned	Checkpoints A8 and B8
G3	Final-report template	Not yet defined	Final reports in both scenarios have no structure
G4	Public support-period statement	Not yet defined	Customers cannot be told the security-update period
G5	Reporting drill history	No drill run before this one	This exercise is the first rehearsal
G6	Incident process rehearsed for CRA Article 14	Notion page exists but has not been rehearsed for Article 14	Tested by this drill
G7	SBOM coverage of worker images	Not yet covered	Injects in both scenarios

8. Planned Work (Candidate Follow-ups)

These are suggestions drawn from the gaps above. None has been committed to by Northwind Ledger, and none has an owner or date yet.

Assign an owner for the early-warning decision. (Owner: not yet assigned.)
Assign an owner for the final report and define a template. (Owner: not yet assigned.)
Define and publish a support-period statement. (Not yet defined.)
Extend CycloneDX SBOM generation to worker images. (Not yet scheduled.)
Update the Notion incident-response page with the findings from this drill.
Schedule a repeat drill after the gaps are addressed. (Date: not yet defined.)

This drill is not legal advice and not a conformity assessment. It does not establish that Northwind Ledger or Northwind Ledger Cloud meets any regulatory requirement. Security reports: security@northwind.example.

Ready to build yours?

Flat $3,999, one time. The output is grounded only in facts you attest before checkout.

Build my reporting pack →