The CRA does not define a severe incident by outage length, customer count, or a vulnerability score. Article 14(5) supplies two legal tests: one concerns a product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; the other concerns the introduction or execution of malicious code in the product or a user’s network and information systems.

Assess both tests independently. A short event can still matter if its security effect meets a test, while a disruptive operational event may fall outside Article 14 if it has no qualifying product-security impact.

Write the assessment around effects

A compact severity record should identify:

  • the product and affected versions;
  • the data or functions whose protection was affected or could be affected;
  • any malicious-code path involving the product or a user’s systems;
  • the evidence and uncertainty for each conclusion; and
  • the accountable human decision-maker.

Avoid replacing this analysis with a single red, amber, or green badge. A status can route work, but it cannot show which statutory test was applied or why.

Trace the product boundary first

Start with the product and affected versions, then trace the incident through the product’s security functions, data paths, execution paths, and connections to a user’s network and information systems. Keep effects on the manufacturer’s corporate environment in a separate branch unless the evidence connects them to product security.

For the data-or-function test, name the availability, authenticity, integrity, or confidentiality property at issue and the sensitive or important data or function it protects. For the malicious-code test, document the code, its execution or introduction path, and the product or user-system boundary reached.

Use two independent findings

Give each statutory test its own conclusion, evidence references, counter-evidence, uncertainty, and decision owner. One test may remain open while the other is resolved. Do not let a confident answer in one column erase an unresolved question in the other.

Operational measures also belong in the record, but they are not the conclusion. Containment may reduce risk while the legal assessment remains open; a long outage may demand urgent response while still requiring evidence of a qualifying product-security effect.

Keep facts and scenarios separate

Record observed effects as facts. Record credible future effects as scenarios and state the conditions required for them. The statutory wording includes effects an incident is capable of causing, so dismissing a case merely because the worst effect has not happened would skip part of the test.

At handoff, freeze the evidence set used for the decision and state what new information would change it. If the product scope, malicious-code path, or protected function remains disputed, name the resolver and next review time. This gives the reporter a bounded conclusion without presenting uncertainty as certainty.

Legal and security reviewers should resolve difficult boundary cases. This article provides an organising method, not legal advice.

Continue this workflow with the product-boundary trace and the two-track record.