CRA Art.14 72-Hour Full Report Template: What SaaS Providers Must Document for ENISA

Post #3 in the sota.io CRA Art.14 Vulnerability Reporting Operations Series

The 24-hour early warning is intentionally lean. Its purpose is speed: authorities need to know a threat actor is actively exploiting something in your product, and they need that information fast enough to mobilise. The early warning is not expected to be complete.

The 72-hour full notification is different. It is the substantive tier. When you file it, ENISA and the national CSIRT coordinator expect a technically credible picture of what happened, what you have done so far, and what the exposure window looks like. Getting it wrong — submitting a partial or inaccurate report — is itself a compliance failure, separate from any underlying incident.

This post walks through the 72-hour notification field by field, explains what the regulators are actually trying to learn from each section, and gives SaaS developers a practical internal checklist for gathering all the required information within the window.

The applicable regulation is Regulation (EU) 2024/2847 (the Cyber Resilience Act). Reporting obligations under Article 14 apply to manufacturers of products with digital elements from 11 September 2026.

The Clock: When Does 72 Hours Start?

A common confusion is whether the 72-hour window starts from the moment you filed the 24-hour early warning, or from the moment you first became aware of the incident.

The answer is: from when you became aware — the same starting point as the 24-hour window.

The three tiers are parallel obligations triggered by the same awareness event, not a chain where each tier opens after the previous one closes:

If you became aware of an actively exploited vulnerability at Tuesday 09:00, you must:

• File the early warning by Wednesday 09:00 (T+24h)
• File the full notification by Friday 09:00 (T+72h)
• File the final report by Tuesday of the following week 09:00 (T+14 days)

This structure means your investigation team has only 48 additional hours after the early warning to produce the full notification. In practice, the data gathering for the 72-hour report should begin the moment you confirm the trigger, not after the early warning is filed.

What the 72-Hour Full Notification Must Cover

The CRA does not prescribe a form with named fields the way some DORA technical standards do. The full notification must give the competent authorities sufficient detail to assess the threat and coordinate any necessary response. Based on Article 14 and ENISA's pre-publication guidance, the following areas must be addressed.

Section 1: Product Identification and Version Scope

Field 1.1 — Product name and type: The commercial name of the product, the category (application software, operating system, network product, IoT device), and whether it is a component embedded in a larger system.

Field 1.2 — Affected versions: Specific version strings or ranges. If the vulnerability is present across multiple major versions, list each. Vague ranges like "versions before 4.x" are insufficient — regulators need to cross-reference with other manufacturers or coordinate national advisories.

Field 1.3 — Distribution channel and deployment model: How was the product distributed — direct download, app store, SaaS (subscription access), OEM embedding? For SaaS products: how many tenants are on the affected version and can you update them centrally without customer action?

Field 1.4 — Estimated number of users affected: The total population of users exposed to the vulnerability at the time of the notification. This is a risk-calibration input — a vulnerability in a product used by 200,000 KRITIS operators warrants different authority response than one in a niche developer tool. Be honest about uncertainty; a range with a confidence note is better than false precision.

Section 2: Vulnerability Technical Description

Field 2.1 — Vulnerability type: Use a standard classification. CVSS vector string is expected. Common Weakness Enumeration (CWE) identifier should be included if applicable. If a CVE has been assigned or is pending, include it.

Field 2.2 — Affected component: The specific module, library, or subsystem within the product where the vulnerability exists. For SaaS products: the service, microservice, or API endpoint.

Field 2.3 — Attack vector and prerequisites: How is the vulnerability reached? Network-accessible without authentication? Adjacent network? Local access required? What attacker capabilities are needed? Does exploitation require user interaction?

Field 2.4 — What the vulnerability allows: What can an attacker do? Remote code execution, privilege escalation, information disclosure, denial of service, authentication bypass. Be specific about the impact class — "could lead to various issues" is not sufficient.

Field 2.5 — CVSS Base Score and Vector String: Calculate the CVSS 3.1 base score using the standard calculator. Include the full vector string (AV:/AC:/PR:/UI:/S:/C:/I:/A:). If you have not yet done a formal CVSS calculation at 72 hours, note that a preliminary score is provided and will be updated in the final report.

Section 3: Exploitation Evidence

This is the section that distinguishes an Article 14 mandatory notification from a voluntary disclosure. You are here because you have evidence of active exploitation (or a severe incident). You must describe that evidence.

Field 3.1 — How exploitation was discovered: Log anomalies, customer reports, threat intelligence feed, security researcher disclosure, automated detection, red team finding. The discovery method affects the reliability of your "awareness start time" claim and matters for regulator assessment.

Field 3.2 — Indicators of compromise (IOCs): IP addresses, domains, hashes, user-agent strings, request patterns or any other technical artefacts associated with the observed exploitation. Where possible, provide IOCs in a structured format (STIX, MISP, or tabular form). Redact customer-identifying information but preserve the technical content.

Field 3.3 — Scope of observed exploitation: How many exploitation events have been observed? Single incident or sustained campaign? Geographic origin if determinable? Any attribution indicators? Is exploitation opportunistic (scanning the internet) or targeted (specific organisation)?

Field 3.4 — Timeline of known exploitation: Earliest known exploitation event with timestamp. If you have identified exploitation that preceded your awareness event (for example, log evidence from three days before detection), document it — authorities need the full window to assess exposure.

Field 3.5 — Impact confirmed in the wild: Has exploitation resulted in data exfiltration, service disruption, privilege escalation, or other confirmed impact? If so, describe the scope. If unknown, state that.

Section 4: Affected Customers and Supply Chain Exposure

Field 4.1 — Are customers directly affected? If your product is embedded in customer infrastructure, or if customers' data was potentially accessed through the vulnerability, document the affected customer categories (critical infrastructure, public sector, financial sector, healthcare, general commercial).

Field 4.2 — Supply chain position: Is your product a component in other manufacturers' products? If yes, have you notified downstream manufacturers through the coordinated vulnerability disclosure process? Under CRA Article 14, the obligation runs to ENISA and the national CSIRT — but downstream notification is also a best-practice expectation and may be required under separate contractual obligations.

Field 4.3 — Personal data exposure: Has the vulnerability led to or potentially enabled unauthorised access to personal data? If yes, a GDPR Article 33 notification to the supervisory authority may be running in parallel with mandatory timelines of its own (72 hours from the data controller's awareness).

Section 5: Mitigations Applied or Available

Field 5.1 — Patch status: Has a patch been developed and deployed? If yes: patch version, deployment date, deployment method (automatic update, manual download, SaaS-side push). If no: expected timeline for patch availability.

Field 5.2 — Workarounds available: Are there configuration changes, firewall rules, feature disablement, or other mitigations users can apply while waiting for the patch? If yes, describe them with sufficient precision to be operationalised.

Field 5.3 — Mitigations deployed on the platform side: For SaaS providers who operate the infrastructure: what mitigations have been applied server-side? WAF rules, network-level blocking, feature flags, API rate limiting? Document what was done and when.

Field 5.4 — Customer notification status: Have customers been notified? When, through which channel, and what were they told to do? If not yet notified, explain why and when notification is planned.

Section 6: Reporting Entity and Contact

Field 6.1 — Legal entity making the notification: Full legal name, registered country, company registration number.

Field 6.2 — Product economic operator classification: Is the notifying entity the manufacturer, importer, or distributor under CRA Article 3? For software products, the manufacturer is typically the entity that developed the software and places it on the EU market, but open-source maintainers and platform providers have distinct positions.

Field 6.3 — Security contact: Named contact at the organisation responsible for this notification, with direct phone and email. ENISA and CSIRTs may need to follow up within hours — a generic "security@" mailbox is not sufficient.

Field 6.4 — Legal/regulatory contact: In case of regulatory follow-up, who handles CRA compliance enquiries?

What Gets Authorities' Attention: High-Risk Flags

Certain elements in a 72-hour notification will immediately escalate the authority's response level. If any of these apply to your incident, expect follow-up contact:

Critical infrastructure customer base: If your product is used by operators in energy, water, transport, health, or banking sectors as defined in the CRA's critical infrastructure cross-reference, the incident has national security implications beyond your product line.

CVSSv3 Base Score ≥ 9.0 (Critical): Remote code execution with no authentication and no user interaction on network-exposed services.

ENISA NCSC cross-notification: If you have already received contact from a national CSIRT or CERT indicating they have third-party threat intelligence about exploitation of your product, document it. Authorities need to reconcile intelligence streams.

Exploitation in more than three EU member states: Cross-border active exploitation activates ENISA's coordination role under Article 14(9) and may trigger the EU CyCLONe (Cyber Crises Liaison Organisation Network) escalation path.

Internal 72-Hour Ops Checklist

The 48-hour window between the early warning and the full notification is short when you consider that most of the data gathering happens in parallel with ongoing incident response. Here is a practical checklist:

T+0 to T+12: Parallel Tracks

• Incident Commander confirmed and incident response team convened
• Evidence preservation: logs, network captures, forensic snapshots secured before they age out
• Preliminary CVSS calculation initiated
• IOC extraction started — assign analyst to pull structured artefacts from log data
• CRA-responsible officer (or legal counsel) notified that a 72-hour notification is in progress
• GDPR assessment initiated: does this incident involve personal data?

T+12 to T+36: Data Assembly

• Affected version list confirmed with version control system, not from memory
• Customer impact assessment: query subscription database for customers on affected versions
• Supply chain map: does this component feed into any OEM/downstream products?
• Patch status: is a fix available or in development? ETA documented
• Workaround documentation: drafted, reviewed by engineering, ready to publish
• IOC list finalised and reviewed by threat intelligence function

T+36 to T+60: Draft and Review

• Full notification draft completed using the field structure above
• Legal review: check that Section 4.3 GDPR assessment is consistent with any parallel GDPR notification
• Technical review: CVSS vector string verified by a second engineer
• Timeline verified: awareness time, early warning filing time, exploitation timeline — all consistent
• CRA-responsible officer approves the submission

T+60 to T+72: Submit

• Filed via ENISA single reporting platform (Article 16 — centralised EU-level portal)
• Submission receipt / acknowledgement number recorded
• Internal record: copy of submission, timestamp, submitter identity
• CSIRT follow-up channel confirmed (check whether your national CSIRT has a dedicated CRA point of contact)

The 72-Hour Report Is Not the End

Filing the 72-hour notification does not close the CRA Article 14 obligation. The 14-day final report (described in Post #4 of this series) must follow with:

• Full root cause analysis
• Complete remediation timeline — what was done and when
• Permanent mitigation status: patch deployed, user adoption rate
• Lessons learned and any process changes
• Updated IOC set if the investigation produced additional artefacts

The final report is also the moment to correct any factual inaccuracies in the early warning or 72-hour notification. Regulators understand that fast-moving incidents produce imperfect initial reports — but persistent inaccuracies in the final report raise separate concerns.

Common Mistakes in 72-Hour Notifications

Treating the 72-hour window as starting from the early warning filing. It starts from awareness. An early warning filed at T+23h59m leaves you only 48 hours and one minute to file the full notification — less time, not more.

Leaving CVSS uncalculated. A notation of "high severity, exact score pending" in the 72-hour notification signals that your security team has not done the baseline technical analysis. Calculate a preliminary score with the available information and flag it as preliminary.

Vague version ranges. "Versions before 3.4.1" is not a version list. Regulators cross-reference your notification against vulnerability databases and other manufacturers' disclosures. They need exact version strings.

No IOCs. If exploitation is confirmed, the absence of IOCs in the 72-hour notification implies your investigation has not reached the stage of extracting technical artefacts. This is a significant gap — either the investigation is under-resourced or the product's logging is insufficient to surface exploitation artefacts.

Single contact point. If the named security contact is unavailable when authorities follow up, delays in response will be attributed to your organisation. Name a primary and a backup contact in every notification.

Conflating CRA and GDPR timelines. The 72-hour CRA notification goes to ENISA and the national CSIRT. A GDPR Article 33 notification — if personal data is involved — goes to the national data protection authority. These are separate filings with separate recipients and potentially different 72-hour clocks (the GDPR clock starts from the data controller's awareness, which may not be identical to the CRA clock start). Running both in parallel without coordination between your security and data protection functions is a compliance risk.

SaaS-Specific Considerations

SaaS providers have structural differences from embedded-software manufacturers that affect how the 72-hour notification fields apply.

Centralised update capability: Unlike device firmware or installed software, SaaS providers can typically deploy mitigations across all affected tenants without customer action. This should be reflected in Section 5 — a statement that you have already pushed a mitigation to all affected tenants and the patch window was zero (customers did not need to take action) will be viewed favourably by authorities assessing residual risk.

Tenant data access logs: SaaS products typically have per-tenant access logs that embedded software does not. You are better positioned to scope exploitation than a device manufacturer because you can query server-side logs. Regulators may expect more precise IOC data and customer impact scoping from a SaaS provider than from a hardware manufacturer for this reason.

Multi-tenant blast radius: A critical vulnerability in a shared service component can affect every tenant simultaneously. Section 4.1 should address whether the vulnerability is in a shared infrastructure layer (affects all tenants) or in a tenant-scoped component (affects only tenants on a specific tier or configuration).

Hosted in the EU vs. outside: If your SaaS infrastructure is hosted outside the EU but serves EU customers, the CRA still applies to you as a manufacturer placing products on the EU market. Your notification must identify the data processing location and the legal entity responsible in the EU.

Linking the Series

The CRA Art.14 Vulnerability Reporting Operations series covers the full three-tier lifecycle:

• Post #1: CRA Art.14 Explained — Three-Tier Timeline ✓
• Post #2: 24-Hour Early Warning — Developer Ops Guide ✓
• Post #3: 72-Hour Full Notification Template (this post)
• Post #4: 14-Day Final Report — Root Cause, Remediation, and Lessons Learned (coming)
• Post #5: Compliance Finale — Complete September 2026 Vulnerability Reporting Ops Checklist (coming)

The 72-hour full notification is the tier that exposes the most gaps in unprepared SaaS organisations. The early warning can be filed in 30 minutes with basic product and incident data. The full notification requires structured investigation output, legal review, and coordinated GDPR assessment — all within a deadline that has already been running for 72 hours from discovery. Start building the data pipeline now, before September 2026.

Key Dates