CRA PSIRT – Vulnerability Reception, 24/72h Reporting and Chain of Custody | Word/PDF/Excel

Receive, assess and document a concrete security vulnerability or incident in a digital product – from the initial report to the actual CRA notification and customer communication. This specialist package for manufacturers of products with digital elements focuses on CRA Article 14 and ENISA's Single Reporting Platform (SRP). It does not replace a broader CRA risk assessment, SBOM or actual regulatory reporting.

Quick facts: 5 Swedish working documents, 1 Swedish user guide and 1 English User Guide, all in editable Word (DOCX) and searchable, printable PDF (not interactive forms), plus 1 Swedish Excel workbook with 9 tabs. Total 15 customer files: seven standalone documents in two formats plus one XLSX. Digital ZIP delivery upon future activation.

Who should choose the template – and when?

For product developers and manufacturers who sell software, connected equipment or other products with digital elements on the EU market and must handle an indication of active exploitation or a serious security incident. Two use cases: a reporter sends evidence of attacks against a specific firmware version; or a manufacturer becomes aware of an incident that seriously affects the product's security. If you are a regular reseller, IT service provider or only handle internal IT incidents, other documents and other rules may be appropriate. Legal manufacturer status and CRA applicability must first be checked.

File by file

The Excel tool in practice

The workbook has filterable records, status fields, ID links and a formula-based overview. When an actual UTC time value is entered for when the manufacturer became aware of a reportable event, it shows the indicative 24h and 72h times. These are absolute technical control values, not a right to wait: report without unnecessary delay. The final report date is entered manually because the trigger differs: when a remediation is available (AEV) and when the 72h notification has actually been submitted (SI). The register distinguishes between draft, assessment, submitted notification and actual receipt.

Step-by-step workflow

1. Identify legal manufacturer, product, version and authorized PSIRT/SRP role.
2. Record sources and evidence without placing secrets or exploitation code in unsecured office files.
3. Assess AEV and SI separately against CRA Article 14 and document the awareness timing.
4. If obligated: prepare the basis and report without unnecessary delay through ENISA's official SRP.
5. Save actual submission IDs and timestamps for 24h, 72h and applicable final report.
6. Document corrective remediation, affected users, communication and post-check.

Legal boundaries and responsibility

CRA (EU) 2024/2847, Article 14 began to apply to manufacturers on 11 September 2026. Reporting obligation for actively exploited vulnerability requires relevant evidence of actual exploitation; a CVE number or high risk score is not automatically sufficient. Serious incident must be assessed according to Article 14.5. Early warning must be provided within 24h and notification within 72h from relevant awareness, both without unnecessary delay. For AEV, the final report must be submitted no later than 14 days after corrective or mitigating remediation is available. For SI, the final report must be submitted within one month after the actual 72h notification. Article 14.8 covers information to affected users.

ENISA's SRP FAQ and field glossary should be checked directly before actual reporting because fields and platform features are updated. A Word or Excel status is never considered a submitted notification. The main other CRA requirements generally start to apply on 11 December 2027, and Article 24.3 for open-source software stewards follows a different start date. If necessary, a special assessment according to, for example, NIS2, GDPR and DORA is required.

Difference from our other documents

Our broader CRA Compliance package covers risk assessment, SBOM, security requirements and overall CRA reporting. This new package is instead a specialized workflow for an actually received report or incident, SRP receipts, evidence and customer communication.

Frequently asked questions

Must every security vulnerability be reported?

No. Article 14 has special thresholds for actively exploited vulnerabilities and serious incidents. Other vulnerabilities may require internal handling, but are not automatically mandatory SRP notifications.

Does the template send the notification to ENISA?

No. The basis prepares and documents the work; an authorized representative must submit the notification via the actual SRP platform.

Are the PDF files editable?

They are searchable and printable, but not interactive fillable forms. Use the Word files for editing.

Is all material translated into English?

No. The five working documents and Excel are in Swedish. The English guide explains how the Swedish documents are used.

Version, sources and transparency

Release 1.0, 9 November 2026. AI-assisted legal source review of CRA Article 14, the Commission's reporting information and ENISA's SRP material on 9 November 2026. No external independent legal review, regulatory review or technical product certification has been performed. The package is an administrative support, not a guarantee of compliance.