The CRA does not define a severe event by outage time, user count, or a flaw score. Article 14(5) gives two tests.

The first asks if a product fails or could fail to guard key data or tasks. Check if the data or tasks stay ready, true, whole, and secret. The second asks if harmful code entered or ran in the product or a user’s network.

Run both tests on their own. A short event can meet a test. A long work outage may fall outside Article 14 if it has no required product harm.

Write the assessment around effects

A short event-level record should name:

  • the product and versions at risk;
  • the key data or tasks harmed or at risk;
  • any harmful-code path through the product or user systems;
  • the proof and doubt for each result; and
  • the person who owns the choice.

Do not replace the check with one red, amber, or green mark. A mark can route work. It cannot show which legal test was used or why.

Trace the product boundary first

Start with the product and versions at risk. Trace the event through product guards, data paths, run paths, and links to a user’s network. Keep harm to the maker’s firm systems in a separate branch unless proof links it to product security.

For the data or task test, name the guard at issue. Did the product keep key data or tasks ready, true, whole, or secret? For the harmful-code test, record the code and how it entered or ran. State which product or user-system line it crossed.

Use two independent findings

Give each legal test its own result, proof links, proof against it, doubt, and owner. One test may stay open while the other ends. A firm answer in one column must not erase an open point in the other.

Response steps also belong in the record, but they are not the result. A limit on harm may cut risk while the legal check stays open. A long outage may need fast work but still lack proof of the required product harm.

Keep facts and scenarios separate

Record seen harm as fact. Record sound future harm as a case and state what would cause it. The law covers harm an event can cause. Do not rule out a case just because the worst harm has not yet occurred.

At handoff, save the proof used for the choice. State which new fact would change it. If scope, the code path, or a guarded task is in dispute, name the resolver and next check time. This gives the filing person a clear result without hiding doubt.

Legal and security reviewers should decide hard cases at the edge. This guide is a work method, not legal advice.

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