Article 14 reporting runbook
Who opens the process, what gets attached in the first 24 hours, what changes by 72 hours, and where final-report evidence comes from.
For software and connected-product manufacturers selling into the EU
Be ready for CRA vulnerability reporting before the clock starts.
Answer product-security questions, attest every fact, and get a Cyber Resilience Act Article 14 reporting runbook, notification drafts, evidence register, vulnerability-intake policy, and tabletop drill — built only from answers you confirm. Flat $3,999, one time. Not legal advice, not certification, not a conformity assessment.
The reporting clock you have to be ready for
Once an actively exploited vulnerability or severe incident is known, CRA Article 14 sets a fixed cadence. VulnBrief turns that cadence into a named owner and a prepared evidence step for each stage.
- 0–24h
Early warning
Notify your CSIRT within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident.
- ≤72h
Full notification
A fuller report within 72 hours — severity, affected versions, and the corrective measures taken or planned.
- ≤14d
Final report
No later than 14 days after a corrective measure is available for an actively exploited vulnerability.
- ≤1 month
Severe incident report
Severe security incidents get their final report within one month, with the same evidence trail.
Cadence per the official CRA reporting-obligations page. VulnBrief prepares the process; it does not file reports for you.
What lands in your pack
Five Markdown documents plus a JSON bundle, delivered to a private order page and your inbox. Every artifact is grounded in the facts you attest — missing practices become a clearly-labelled gap register, never a claim.
Notification drafts
Early-warning, full-notification, and final-report templates that keep unknown facts as unknown instead of inventing legal conclusions.
Evidence register
A product-specific map of SBOMs, scanner alerts, tickets, versions, releases, advisories, and submission records — including what is missing.
Vulnerability-intake policy
How reports arrive, who triages, how severity is decided, and where the work is tracked — grounded in the channels and tools you actually use.
Tabletop drill
A rehearsal for one actively exploited vulnerability and one severe incident, so the runbook is tested by people, not just written down.
How it works
Attest the facts
Scope one product, your vulnerability channels, SBOM status, evidence locations, release process, and reporting owners. Mark anything not in place as “not yet.”
Review every statement, then pay
Before checkout you see the exact statements the documents will be built from — nothing else. Edit anything that isn’t true today.
Generate and rehearse
The pack generates right after checkout, typically in minutes. Run the tabletop drill with engineering and turn the gap register into tickets.
Who VulnBrief is for
A strong fit if…
- You make software or a connected product sold into the EU.
- You have scattered evidence — SBOMs, scanners, a security inbox, tickets — but no single reporting process.
- You want a rehearsable runbook your engineers and counsel can act on, not a dashboard to administer.
Not the right tool if…
- You need a full CRA conformity assessment or a CE-marking decision.
- You want a lawyer to review or sign off on your notifications.
- You want someone to file reports into the Single Reporting Platform for you.
The boundary is explicit
VulnBrief produces manufacturer-attested operational documentation. It does not file reports, provide legal advice, certify CRA compliance, perform a conformity assessment, or guarantee regulator acceptance. That restraint is part of the product: the pack is useful because it says what is known, what is unknown, and who owns the next action. No scoping call, no retainer — answer the questions, attest the facts, get the pack.
A real example, fully visible
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.
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.
Common questions
Is the September 11, 2026 date real?
Yes. The European Commission states the CRA Article 14 reporting obligations apply from September 11, 2026. We link the official page on this site so you can confirm it yourself, and we keep the copy about readiness rather than panic.
What data do you store?
Your intake answers, attestation timestamp, generated artifacts, order status, and support/refund signals. Generated packs are private behind an unguessable order link unless you explicitly publish the optional readiness page.
How long does it take?
The intake is the slow part because the facts are yours. Generation starts after checkout and typically finishes in minutes; the order page and email show status.
Is this legal advice?
No. It is operational documentation generated from your attested facts. Counsel should review any actual regulatory submission or customer-facing legal position.
What if the pack fails or I never use it?
If generation fails a quality gate or never delivers, the order is refunded automatically. If your order record shows you never opened the deliverable, you can request a refund through the same private order page. Full terms are on the Terms page.
Who is this not for?
Teams seeking a full CRA conformity assessment, a legal opinion, or someone to file notifications for them. VulnBrief is for building the reporting process and evidence pack before an event.