Choosing a CRA compliance tool for Article 14 reporting: build, buy, or work where your tickets live

July 2026 · 7 min read

With the Cyber Resilience Act's reporting duty applying from 11 September 2026, teams are deciding how to operationalise Article 14 of Regulation (EU) 2024/2847. The honest starting point: you do not strictly need to buy anything. A disciplined team with a runbook, a calendar, and templates can comply. The question is what failure looks like under pressure, and which class of tooling removes which failure mode. This is a framework, written by the developer of one of the options — bias declared, criteria first.

What Article 14 actually demands of tooling

Strip the regulation to its operational skeleton and a tool must do five things: (1) help decide whether a case is reportable — actively exploited vulnerability (Art. 14(1)) or severe incident (Art. 14(3), framed by 14(5)); (2) run the staged clocks correctly, including the two different final-report start points — 14 days after a corrective or mitigating measure is available on the vulnerability path (Art. 14(2)(c)), one month after the 72-hour notification is submitted on the incident path (Art. 14(4)(c)); (3) produce the five documents — three authority stages plus the affected-user notice (Art. 14(8)) and the upstream component-maker notice (Art. 13(6)); (4) keep an audit trail that survives scrutiny; (5) not create a new data-protection problem while doing all of the above.

The four approaches

	Runbook + spreadsheet	Enterprise ASPM / product-security suite	Generic GRC platform	Ticket-native app (inside Jira/JSM)
Cost shape	Free; pays in attention	Typically quoted; often five figures annually	Mid; per-seat	Low; per-user via marketplace billing
Article 14 depth	As deep as your runbook	Strong on vulnerability discovery; reporting workflow depth varies — verify the two final-report clocks specifically	Strong on evidence storage; CRA-specific deadline logic usually configured by you	Purpose-built for the staged clocks and the five drafts; narrow by design
Where the work happens	Wherever the spreadsheet is	A separate console	A separate portal	In the incident ticket itself
Data residency	Yours	Vendor cloud — review the DPA	Vendor cloud — review the DPA	Can be tenant-contained (verify: no external egress)
Audit trail	Manual discipline	Usually strong	Usually strong	Verify: append-only, per-action
Fits best	Single product, rare incidents, strong discipline	Large portfolios already buying ASPM	Orgs standardised on one GRC for many regimes	Teams whose incident response already runs in Jira/JSM

Evaluation questions that separate the field

Ask the two-clocks question first. "Show me how the tool anchors the vulnerability final report versus the incident final report." A tool that counts both from awareness has not read Art. 14(2)(c) and 14(4)(c). This single question eliminates more options than any feature list.
Where does incident data go? Your Article 14 evidence is, by definition, sensitive security data. A reporting tool that ships it to a third-party cloud adds a vendor to your threat model at the worst possible moment. Ask for the egress story in writing.
Who decides borderline cases? Whether an incident is "severe" under Art. 14(5), and when you "became aware," are judgment calls whose interpretation depends on official guidance. Be wary of tooling that auto-decides them; the responsible pattern is flagging for human confirmation.
Does it file for you? Automatic submission sounds attractive and is premature: the ENISA single reporting platform (established under Art. 16) is still having its registration procedures and templates finalized. An export-and-submit posture, with a human pressing the button, is the honest design for 2026.
What happens between incidents? Reporting tools are used rarely by definition. Ask what the tool does in normal times — vulnerability registers, exploited-vulnerability catalog matching, tabletop rehearsal — or accept that it will be shelfware whose runbook nobody remembers.
Does it cover the notices, not just the reports? The affected-user notice (with the CSIRT able to inform users directly if you fail to — Art. 14(8)) and the upstream component notice (Art. 13(6)) are the parts teams forget. Five documents, not three.

The uncomfortable summary

The regulation's penalties (up to €15 million or 2.5% of worldwide annual turnover, whichever is higher) make Article 14 a board-level topic, but the operational risk is mundane: a miscalendared start point, a user notice that sat in a drawer, an awareness timestamp reconstructed from memory. Choose the approach that removes your most likely mundane failure — for teams already living in Jira or JSM, that is usually the approach that never asks responders to leave the ticket.

Full disclosure and a free way to test the fit: CRA Reporting Copilot is the ticket-native column of this table — Jira/JSM-native, zero-egress by design, two clocks modeled as the regulation writes them. Its readiness check is free, so you can evaluate the approach against your own tickets before deciding anything: overview · documentation.

Sources: Regulation (EU) 2024/2847 (Cyber Resilience Act), Art. 13(6), 14(1)–(8), 16, 64, 71(2) — EUR-Lex; European Commission, "Cyber Resilience Act — Reporting obligations"; ENISA, Single Reporting Platform pages.