Article 14(3) Severe incident notification under the CRA

What Article 14(3) severe incident notification asks manufacturers to do

Once a manufacturer knows a severe incident affects the security of one of its products, the clock on Article 14(3) starts, and the windows are short and fixed. Since 11 September 2026, the first step is an early warning within 24 hours, submitted through ENISA's Single Reporting Platform. That notice must say whether unlawful or malicious acts are suspected, which means the person on call needs a decision in the first day: is this an attack or a fault? Teams that have not agreed in advance who can make that call, and who signs the submission, will spend the first hours arguing about roles instead of gathering facts. Confirm your internal escalation path, your delegated signatories and your access to the platform before an incident, not during one.

The incident notification follows within 72 hours. It is more substantive than the early warning, so the hard part is usually not the form but the facts: a usable description of what happened, which versions and components are affected, and whether the severity threshold is met. The severity test in the regulation turns on whether the incident affects or can affect the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or has led or can lead to malicious code being introduced or executed. Because the test covers what an incident *can* affect, not only what has been confirmed, document your reasoning at each stage so a later reviewer can see why you classified it as you did.

The final report is due within one month after the incident notification. It must describe the incident, its severity and impact, the likely threat type or root cause, and the mitigations applied and still under way. A month sounds generous until the root cause investigation runs long, so plan for the final report to be drafted in parallel with containment. Delay carries a real cost: users and CSIRTs may be exposed to an unpatched product while the notification sits unsent. The duty to inform impacted users, with mitigations they can deploy, runs alongside these windows, so the communication plan belongs in the same runbook as the reporting timeline.

Which incidents and products fall under the severe incident duty

Article 14(3) applies only to severe incidents that affect the security of an in-scope product. The cards below walk through the severity test, the products it reaches, the parts of the supply chain that can trigger it, and who makes the call inside the manufacturer.

The availability and integrity test

Article 14(5) treats an incident as severe when it affects, or can affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. Read the test as a question about what could happen, not only what has happened. A flaw that lets an attacker tamper with a firmware update path or read stored credentials can meet the test before any exploitation is confirmed. Check which data and functions your product treats as sensitive or important, and write that list down before an incident occurs.

The malicious code test

The second limb of Article 14(5) applies when malicious code has been introduced or executed in the product or in a user's systems, or when it can be. This limb matters most for connected devices, agents and update mechanisms, where a compromised component can reach users' environments. Ask your incident response team to treat any confirmed or plausible code injection in a shipped product as a candidate severe incident and to start the clock as soon as the manufacturer becomes aware.

Products placed on the market before 2027

Products placed on the market before 11 December 2027 fall under the full regulation only if they are substantially modified from that date. The Article 14 reporting obligations are different: they apply to all in-scope products whenever they were placed on the market. Inventory your installed base now, including products that will never receive a CRA conformity assessment, so that a severe incident in an older unit still reaches the reporting workflow.

Third-party components and cloud services

A severe incident can originate in a library, operating system package or cloud service that your product depends on. The duty still sits with the manufacturer of the product, so a vulnerability in an upstream component that affects your product's security must be assessed against the same test. Keep a component inventory that links each dependency to the products it reaches, so the team can decide quickly whether an external event has an impact on a shipped product.

Who owns the severity decision

The manufacturer owns the decision that an incident is severe and must notify the Single Reporting Platform, not an implementation partner or an assessor. Define a named role with authority to make the call, a documented decision record, and a rule for escalating borderline cases to legal and the product security lead. Outside advisers can prepare the assessment template and run tabletop exercises, but the manufacturer signs off on each notification.

Microenterprise and small enterprise relief

Article 64(10)(a) exempts microenterprises and small enterprises from fines for missing the 24-hour early warning deadline. The exemption covers that one deadline only, so the other reporting steps and the duty to inform users still apply. Confirm your company size category under the applicable EU definitions and document how you reached it. Article 17(6) also requires CSIRTs to offer helpdesk support on reporting, particularly to SMEs, so ask the designated CSIRT about its support channels before an incident happens.

How an assessor tests the incident notification process

This table walks through what an assessor checks for each stage of severe incident notification, the evidence they ask for, and where manufacturers usually fall short. Read it as a test plan: each row is a check you should be able to pass with records you already keep. Confirm with the relevant market surveillance authority or certification body which approach it expects, because the reviewer may not be a certification body.

Test step	What the assessor checks	Evidence they expect	Common finding
Severity procedure walkthrough	Whether a documented method decides if an incident is severe under the Article 14(5) criteria, and who makes that call	Written severity procedure, decision criteria, named roles, sign-off records	Severity criteria are undefined or depend on one engineer's judgment
Sampling of incidents	Whether real incidents, or simulated exercises where none occurred, pass through the procedure as written	Incident register, tickets, tabletop exercise reports with dates and outcomes	No incidents or exercises exist, so the process has never been tested
24-hour early warning clock	Whether awareness time, submission time and a statement on suspected unlawful or malicious acts are recorded	Timestamps for detection, awareness and submission, plus the early warning text	Awareness date is not recorded, so the clock cannot be shown to have run correctly
72-hour incident notification clock	Whether the notification was filed within 72 hours and updated where status changed	Submission record, update history, copy of what was sent to the CSIRT	Notification content is generic and does not match the incident record
One-month final report clock	Whether the final report was filed within one month of the incident notification	Final report with submission date, linked to the notification reference	Report is late or drafted but never submitted through the platform
Final report content against Article 14(4)(c)	Whether the report describes the incident, its severity and impact, the likely threat or root cause, and applied and ongoing mitigations	Final report checked line by line against the four content elements	Root cause is left blank or mitigations list only past actions, not ongoing ones
Duty to inform impacted users	Whether users affected by the incident were told, with mitigations they can deploy, and whether a structured machine-readable format was used where appropriate	User notices, distribution logs, advisory format, reasons for any users not reached	No user notice exists, or the notice gives no concrete steps the user can take
Consistency across records	Whether timestamps, severity labels and descriptions match across tickets, notifications, reports and user notices	Cross-referenced case record showing one timeline for each incident	Records disagree on dates or severity, which undermines every other test

Building a notification process that meets the clocks

This sequence turns Article 14(3) into a working process: a severity decision that starts the clock, detection and triage that can meet the 24-hour early warning, and templates and access that let the team report on time. Each step ends with an artifact a reviewer can inspect.

Define severity criteria in writing
Start by turning the Article 14(5) test into a decision procedure your product security lead and legal counsel can apply under pressure. The test asks whether an event affects or can affect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or whether malicious code has been or can be introduced or executed in the product or a user's systems. Write the criteria with examples specific to your product, including who decides and how quickly. The artifact is a signed severity decision procedure that names the decision owner and the record kept for each decision, including decisions that conclude an event is not severe.
Set up detection and triage that starts the clock
The early warning clock depends on when the manufacturer becomes aware of a severe incident, so the team needs telemetry that surfaces product-side events quickly. Log sources can include product backends, update infrastructure, telemetry from deployed components and vulnerability feeds. Wazuh can decode collected logs and match events against its ruleset, and OpenSearch Security Analytics can run Sigma-based detectors and send alerts to email or chat channels. Confirm each tool's supported log types in your environment before relying on it. The artifact is a documented alert path showing how an alert reaches the on-call decision owner, with test alerts that were received and timestamped.
Open a case and track the timeline from the first alert
Once triage flags a possible severe incident, every action needs a single record so the three reports can be built from the same facts. DFIR-IRIS keeps each case as one record of assets, indicators of compromise, tasks and evidence with a full audit trail, and it can build a consolidated timeline and generate reports from case data. Set a rule that the case is opened at the moment of the severity decision, not after the investigation ends. The artifact is a case template with fields for awareness time, severity decision, suspected unlawful or malicious acts, affected versions and mitigations, plus a sample case showing the audit trail.
Prepare the early warning template and platform access
Notifications go through ENISA's Single Reporting Platform to the CSIRT designated as coordinator, so access must be ready before an incident. Ask the designated CSIRT and ENISA which access steps, account roles and contact details apply to your organization, and confirm them in writing. Draft the early warning template so it states whether unlawful or malicious acts are suspected, as Article 14(4)(a) requires, and keep it short enough to complete within the early warning window. The artifact is an approved template, a named list of users who can submit, and a test of the account access completed before any live event.
Rehearse the 72-hour notification and one-month final report
The incident notification and final report reuse the case, so the rehearsal checks whether the case record can produce them. Run a tabletop exercise on a hypothetical product incident, labeled as illustrative, and have the team fill the notification fields from the case alone, including the severity assessment, the affected components and the mitigations applied or ongoing. The final report under Article 14(4)(c) must describe the incident, its severity and impact, the likely threat type or root cause, and mitigations. The artifact is a completed rehearsal report with gaps, owners and dates for each gap, and a revised template.
Build user notification and machine-readable mitigation output
Article 14(8) requires informing impacted users, and where appropriate all users, about the incident and the mitigations they can deploy, where appropriate in a structured machine-readable format. Decide in advance which user channels exist, how contact data is maintained, and which mitigation fields a machine-readable notice would carry, such as affected versions and fixed versions. Confirm with counsel and the designated CSIRT what counts as appropriate in your case, because a CSIRT may inform users if the manufacturer does not do so in time. The artifact is a user notice template, a channel inventory and a sample structured mitigation file validated against the schema you chose.
Assign owners and review the process after each drill
A notification process only meets the clocks if people know their roles when the clock is running. Assign a named owner for each step, define who signs each submission, and schedule a review after each rehearsal and after any real event. Keep the severity criteria, templates and access records under version control so the process can be shown to an assessor or market surveillance authority. The artifact is a responsibility matrix, a document history and a dated review record for the most recent drill.

How open-source tooling keeps the incident record defensible

DFIR-IRIS (LGPL-3.0-or-later) is the case management layer. It keeps each incident as one record that holds the affected assets, indicators of compromise, tasks and evidence, with a full audit trail of who changed what. Its alert intake takes events from SIEM, EDR and REST sources and turns them into cases, so the timeline your team reports to the CSIRT starts from a record rather than from memory. Evidence entries can be logged with SHA-256 verification and chain of custody, which supports the statement of severity, impact and root cause that the final report must contain.

Single incident record: assets, indicators, tasks and evidence sit in one case, which keeps the notification and final report consistent.
Consolidated timeline: the platform builds an investigation timeline from case data, useful for the time stamps the 24-hour and 72-hour deadlines depend on.
Evidence integrity: SHA-256 hashes and chain of custody entries show that evidence was not altered after collection.
Report generation: reports are produced from case data, which reduces retyping errors in the final report.
Audit trail: changes to a case are recorded, giving reviewers a history of decisions.

Confirm with your counsel and CSIRT which evidence and personal data may be shared, and whether DFIR-IRIS fits your hosting, access control and retention rules. Review the LGPL-3.0-or-later terms with your legal team before you modify the code.

Evidence that shows the notification duty works

Article 14(3) is tested by whether a manufacturer can show what it knew, when it knew it and what it reported. The cards below are the records that connect a severity decision to the early warning, the notification, the final report and the notices sent to users. Each one needs a named owner and a review step, because a record that is accurate on the day of an incident but out of date at the next one will not hold up.

Severity decision record

Each suspected incident needs a written decision on whether it is severe under Article 14(5), with the date, the people who made the call and the criteria applied. Record the affected data or functions, whether malicious code could have been introduced or executed, and why a no-decision was reached if the answer is no. Keep the criteria as a versioned document so an assessor can see which version applied on the decision date. Review the criteria after every drill and after any change to the product's architecture.

Timestamped early warning and notification copies

Keep the exact text submitted through the Single Reporting Platform for the 24-hour early warning and the 72-hour incident notification, with the submission time recorded from the platform or your own log. The early warning must say whether unlawful or malicious acts are suspected, so store the reasoning behind that statement. Archive the receipt or reference returned for each submission. Check quarterly that the people who can submit have working accounts and that the reporting contact is still correct.

Final report with severity and mitigations

The final report due within one month of the incident notification must describe the incident, its severity and impact, the likely threat type or root cause, and the mitigations applied and still ongoing. Build the report from the case record so each statement traces to a timestamped entry rather than to memory. Store drafts and sign-off history. Confirm that the root cause section can be updated if the investigation changes the original finding.

User notices and machine-readable mitigation files

Article 14(8) requires notice to impacted users, and to all users where appropriate, describing the incident and the mitigations they can deploy. Keep each notice with its distribution list, send time and channel. Where a structured, machine-readable file is used for mitigations, version it with the product release it applies to and store the checksum. Confirm the notice channel works without depending on the affected service, since a compromised service may be the one that needs fixing.

Drill records and contact checks

Run tabletop or live exercises that walk a simulated severe incident through the severity decision, both reporting deadlines and the user notice. Record who took part, the simulated timeline, the time each step finished, and the gaps found. Track each gap to closure with an owner and date. Use the drill record to confirm that the reporting path works when the usual on-call engineer is unavailable.

Case logs and evidence chain

Keep the incident case, its timeline, alert sources and audit trail together so reporting claims can be traced to raw data. Self-hosted tools such as DFIR-IRIS can hold the case record, and Wazuh or OpenSearch can supply the alert history. Retain audit logs from the systems that hold the case and the reporting credentials, and confirm where each log is stored and for how long. Check that exported reports can be regenerated from the case data after a later edit.

What meeting Article 14(3) costs in money and effort

This table lists the cost components of running severe incident notification under Article 14(3), who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, since no price is published here and the figures depend on your product, support period and incident volume.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Detection tooling and hosting	Hosting provider or your cloud account, plus any paid support contract. The open-source licenses carry no fee, but the servers and storage do.	Setup is one-time. Hosting, storage and support recur.	Log volume from the product fleet, retention period, and whether you run the stack in high availability. Confirm the license terms of each component with its vendor.
Engineering time for detection rules and templates	Your security engineers or an implementation partner who writes detectors, correlation logic and rules that flag malicious code or loss of integrity.	Mostly one-time, with recurring updates when the product changes.	Number of product lines, complexity of the architecture, and how much telemetry the product already emits. Ask the partner to separate build hours from maintenance hours.
Notification templates and workflow design	Your incident response lead and legal counsel, or a partner who drafts the early warning, incident notification and final report formats.	One-time drafting, then recurring review after each drill or regulatory update.	Number of recipients (the CSIRT and ENISA platform), languages, and whether templates must support the required machine-readable user notices. Check guidance as it is updated.
On-call and triage staffing	Your staff or an outsourced security operations provider, paid per shift or per role.	Recurring, around the clock for the 24-hour early warning window.	Expected alert volume, the number of people trained to classify severity, and whether you rely on a provider for out-of-hours cover. Ask for the staffing model in writing.
Legal review of notices	External counsel or your in-house legal team, billed per review or as retainer time.	Recurring per incident, plus one-time review of the templates.	Whether statements may point to suspected unlawful or malicious acts, how often notices need review, and the number of Member States where you operate.
Drills and tabletop exercises	Your staff time, plus any external facilitator or cyber range provider you engage.	Recurring, usually scheduled at least once a year.	Team size, number of product teams involved, and whether drills test the platform submission process end to end. Ask the provider what the drill covers.
External incident response and testing support	A retained incident response firm or a DFIR partner, paid on retainer plus hourly work during an event.	Retainer recurs. Hourly work arises only when an incident occurs.	Retainer size, response time commitments, and the depth of forensic work needed for the final report. Confirm response times and scope in writing before you sign.
Final report preparation	Your product security and engineering teams, with legal and an external reviewer where needed.	Recurring per severe incident, within one month of the incident notification.	Complexity of the root cause analysis, the number of affected components, and how well evidence was captured during triage.

Who runs the notification duty and what to outsource

Who is legally responsible for notifying a severe incident under the CRA?

The manufacturer is responsible. Under Article 14, the duty to notify severe incidents sits with the manufacturer of the product with digital elements, not with the implementation partner, hosting provider or auditor. The manufacturer decides whether an incident is severe, makes the early warning, incident notification and final report through the Single Reporting Platform, and informs impacted users. Any outside party can prepare the tooling and procedures, but the filing and the statements in it are the manufacturer's own.

Can DeployOpen file CRA incident reports or issue a compliance certificate?

No. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms, and it can prepare the systems, runbooks and evidence that a manufacturer uses when reporting. It does not file notifications on a manufacturer's behalf, issue reports, attestations or certifications. Independent auditors, assessors and certification bodies are the parties that issue those documents. Confirm the division of roles in the written scope before work starts.

What parts of the notification duty are commonly outsourced?

Three parts are usually outsourced because they are technical build work:

Runbooks that map each step of the 24-hour, 72-hour and one-month clock to named roles and systems
Tooling build, such as case management, log detection and audit logging configured in the manufacturer's environment
Tabletop and technical drills that test whether the team can classify an incident, collect evidence and draft a notification within the deadlines

Each item should be defined in a fixed-scope written agreement with deliverables and a timeline agreed before work starts.

Which parts of severe incident reporting should stay in-house?

Keep the decisions and the sign-off in-house. Severity classification under Article 14(5), the judgment on whether unlawful or malicious acts are suspected, the content of each filing, the choice of what to tell users, and legal approval all depend on the manufacturer's knowledge of its product and its legal exposure. An outside partner can prepare the templates and the decision criteria, but the people accountable for the statements should be the manufacturer's own staff, with legal counsel reviewing wording before submission.

What does an independent assessor test for incident notification?

An independent assessor checks whether the process works as documented and whether the evidence exists. For Article 14 reporting, that typically means reviewing the runbook, the severity criteria, the timestamps and records of past or simulated incidents, the audit trail for notifications and the process for informing users. The assessor's role is to test and report on what they observe. The organization remains responsible for the controls, and the assessor does not decide severity or make filings. Ask the assessor to confirm in writing which standards or methods they apply.

How much does outsourcing CRA incident notification cost?

Cost depends on the number of products in scope, the state of existing logging and case management, and how many drills are required. The cost of implementation work is one-time, while drills, tooling updates and retained support recur. The CRA itself does not set a price for outside help. Ask for a quote built from a written scope that lists the products covered, the systems to be configured, the number of drills, the evidence to be delivered and who reviews it. Note that DeployOpen does not publish a price list, and a quote follows from the agreed scope.

Can a small manufacturer handle the notification duty without outside help?

A small manufacturer can handle it internally if it has a named owner, a written runbook and a tested way to reach its CSIRT. Article 64(10)(a) exempts microenterprises and small enterprises from fines for missing the 24-hour early warning deadline, and Article 17(6) requires CSIRTs to provide helpdesk support on reporting, especially to SMEs. That exemption is a fine rule, not a reporting exemption, so the duty still applies. Confirm the exemption and its conditions with your national authority or legal counsel before relying on it.

What should a manufacturer ask a partner before signing an outsourcing agreement?

Ask for a written scope that separates responsibilities clearly. Confirm which products and environments are covered, which deliverables are produced (runbooks, configured tooling, drill reports, evidence packs), who signs off each one, and what happens to records after the engagement ends. Ask how the partner handles access to sensitive vulnerability and incident data, and whether the agreement covers ongoing support or only the initial build. Make sure the contract states that the manufacturer keeps the reporting duty and that the partner issues no reports or certifications.

Gaps that cause missed incident deadlines

Article 14(3) runs three clocks from the moment a severe incident is identified: 24 hours, 72 hours and one month. Most missed deadlines come from the steps before the clock starts, such as unclear severity criteria, detection that never reaches a case, and contacts nobody has tested. Each gap below pairs with the closure step that keeps the clock visible.

No written severity criteria

Article 14(5) defines a severe incident by its effect on availability, authenticity, integrity or confidentiality of sensitive or important data or functions, and by malicious code being introduced or executed. If your team has no written test against that definition, each on-call engineer decides alone whether an event counts. Closure step: write a severity decision record that maps your product's sensitive data and functions to those four properties, and have legal and product sign it.

Detection that does not start a clock

Alerts from SIEM, EDR or product telemetry often sit in a queue with no link to a reporting timer. The 24-hour early warning runs from the point the manufacturer identifies the severe incident, so an unassigned alert can consume hours before anyone asks whether it is reportable. Closure step: route alerts that match severity criteria into a case record with a timestamp, so the awareness time is documented from the first triage.

Unclear ownership between product and security

Product teams own the firmware, release and user base, while security teams own detection and triage. When neither is named as the decision owner, the early warning can wait while each side assumes the other is filing it. Confirm in writing who is the notifying role, who approves content, and who holds the Single Reporting Platform account. Closure step: publish a RACI for reporting that names a primary and deputy for each step.

Untested CSIRT contact steps

Notifications go through the Single Reporting Platform to the CSIRT designated as coordinator, which receives the report and makes it available to ENISA. Teams that have never logged in, never confirmed their coordinator, or never drafted an early warning under time pressure lose hours on access and forms. Confirm your coordinator and access rights before an incident. Closure step: run a tabletop exercise that files a dummy early warning end to end and records the elapsed time.

Third-party component incidents not routed

A severe incident may originate in an open-source library, an embedded component or a cloud service that your product depends on. If the supplier's advisory lands in a shared inbox, the manufacturer's clock may already be running without anyone owning the question. Map each critical component to a named monitoring source and an internal owner. Closure step: add supplier advisory feeds to the same case intake as your own telemetry, with SBOM lookups in the triage step.

User notices not machine-readable

Article 14(8) requires manufacturers to inform impacted users, and where appropriate all users, of the incident and of mitigations they can deploy, in a structured machine-readable format where appropriate. Free-text emails written after the final report often miss this requirement and delay mitigation. Decide in advance which notice formats your update channel supports. Closure step: draft a user notice template with fixed fields for affected versions, mitigation steps and update source.

Questions buyers ask about CRA incident notification

How much effort does severe incident notification take?

The effort depends less on the number of notifications than on how quickly your team can establish that an incident is severe and gather facts for three deadlines. Each severe incident requires an early warning within 24 hours, an incident notification within 72 hours and a final report within one month of the notification. The early warning must also say whether unlawful or malicious acts are suspected, which means someone must assess that within the first day. Effort drivers include how mature your detection and triage is, how many people hold product security knowledge, and how many products and third-party components could be affected. Ask any consultant to estimate effort from your written scope, product inventory and detection coverage rather than from a generic figure.

How long does it take to set up incident notification capability?

No official duration is fixed by the regulation for setting up internal capability, so the timeline is set by your starting point and scope. Reporting obligations for manufacturers under Article 14 apply from 11 September 2026, so organizations should check how much of the runbook, contact path and evidence collection already exists. Setup typically covers a severity assessment procedure, a named decision owner, templates for the three notifications, a route into the ENISA Single Reporting Platform, and tested log retention. Confirm the expected duration in the written statement of work, and ask which steps depend on your own staff availability.

What information must the team be able to supply for each notification?

Each stage requires different information, and the final report sets the highest bar. The early warning must state whether unlawful or malicious acts are suspected. The final report under Article 14(4)(c) must include a detailed description of the incident, including its severity and impact, the type of threat or root cause likely to have triggered it, and the mitigation measures applied and still ongoing. Your team therefore needs:

Timestamped detection and triage records for the affected product
Asset and component inventory showing which versions are affected
Evidence of the severity assessment against the Article 14(5) test
A record of mitigations and user communications

Confirm with your counsel how these records will be stored and who may access them.

Can we run CRA incident notification in-house?

Yes, in principle. The regulation places the duty on the manufacturer, so the organization remains accountable whether or not an outside party helps. In-house teams work well when they already run product security incident response and can staff a decision owner who is available around the clock. Outside help is commonly used to design the procedure, configure detection and case management tooling, rehearse the 24-hour timeline and prepare evidence packs. DeployOpen can plan, implement and document those systems inside your own infrastructure under a fixed scope, but it does not decide severity or submit reports on your behalf. Ask any provider to state in writing what it will and will not do.

Do SMEs get CSIRT helpdesk support for reporting under Article 17(6)?

Article 17(6) requires CSIRTs to provide helpdesk support on reporting, in particular to SMEs. This means a small manufacturer can ask its designated CSIRT for guidance on how to report, although the CSIRT does not carry out the manufacturer's duties. Article 64(10)(a) also exempts microenterprises and small enterprises from fines for missing the 24-hour early warning deadline. Do not treat the exemption as relief from the duty itself. Confirm which CSIRT coordinates your notifications, what helpdesk hours and channels it offers, and whether the exemption applies to your enterprise size under the Commission's definitions.

What changes for products placed on the market before 11 December 2027?

Products placed on the market before 11 December 2027 generally fall outside the full regulation unless they are substantially modified from that date. The Article 14 reporting obligations are different: they apply to all in-scope products whenever they were placed on the market. This means an older product still in use can trigger a severe incident notification if its security is affected. Your team should inventory installed products, identify which ones are in scope, and record whether any substantial modification has occurred. Ask your legal adviser to confirm how the Commission's non-binding guidance applies to your product lines.

Who must inform impacted users of a severe incident?

The manufacturer must inform impacted users, and where appropriate all users, of the incident and of the mitigations they can deploy. Under Article 14(8) this may be done in a structured, machine-readable format where appropriate. CSIRTs may inform users themselves if the manufacturer does not do so in time. Plan the user notice in advance, including distribution channels, language coverage and how you will reach users who do not run your update mechanism. Confirm with your legal team whether any user notice has to be coordinated with other reporting duties you hold.

What do fines look like if we miss a deadline?

Article 64 sets the maximum administrative fine for breaches of Articles 13 and 14 at EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Fines are a ceiling set by the regulation, and national authorities decide actual amounts based on the circumstances. Microenterprises and small enterprises are exempt from fines for missing the 24-hour early warning deadline under Article 64(10)(a). Confirm your enterprise classification and how your national market surveillance authority applies these rules before making decisions about staffing.

How DeployOpen prepares incident notification evidence

DeployOpen helps organizations set up the systems, logs, case records and written templates that support Article 14(3) notifications for a self-hosted open-source platform. The organization remains the manufacturer and makes every notification decision, and DeployOpen does not submit reports on its behalf.

How we scope

Engagements are fixed-scope, with the platforms, products and notification roles agreed in writing before work starts.
The written scope names which incident sources, log types and product components feed severity assessment for Article 14(3).
The scope states who on the client side owns the 24-hour, 72-hour and final report decisions and sign-off.
Ongoing support for notification readiness is available as a retainer after the initial scope is delivered.

How we build

Configure log collection on the self-hosted platform so security-relevant events reach a central analysis point.
Deploy detection rules, such as Sigma-based detectors or Wazuh rules, mapped to the severity test in the regulation.
Set up a case management record per incident with assets, indicators, tasks, evidence and an audit trail.
Build a timeline template that records detection, awareness, early warning, notification and final report dates.

How we hand over

Deliver written notification runbooks covering the early warning, incident notification and final report content.
Provide report templates that capture severity, impact, likely root cause and applied and ongoing mitigations.
Document the user notification process, including how mitigations are communicated to impacted users.
Confirm with the client's CSIRT and legal team which channel, contacts and formats their process requires.

How we support

Run a tabletop exercise against a hypothetical example, labeled illustrative, to test the runbooks with the client's team.
Review the evidence package after the exercise and update templates, detection rules and timelines as gaps appear.
Support the client through periodic reviews of log coverage, detection tuning and CSIRT reporting contacts under a retainer.
Coordinate with the client's independent assessor when evidence is requested, while the assessor alone issues any report or certificate.