An attack on a maker’s firm is not a severe CRA event just because it harms the firm. The CRA asks about the product. Does the event harm, or could it harm, the security of a product with digital elements under Article 14(5)?
The same event may still create other legal, contract, or work duties. Add a product security check. Do not replace the main firm response.
Draw the product dependency path
Start with the hacked asset and trace each path to a product. Check source code, build tools, signing keys, updates, and release storage. Add online services that form part of the product. Also check support tools and admin systems with broad product rights.
For each path, record if access was possible, tried, or seen. Name the versions and tasks that rely on the asset. A nearby network link does not prove product harm. A lack of direct access to user devices does not rule it out.
Test the two severity branches
For the first branch, name the key data and tasks the product must protect. Check if they were kept ready, true, whole, and secret. Record harm that was seen. Also record the event’s proven power to cause harm.
For the second branch, ask if harmful code entered or could enter the product. Could it run in the product or a user’s network? Keep signing logs, build source, release hashes, access logs, and sales proof. State what is not yet known.
Keep proof tied to the product. A hacked work email and a hacked release key may share one case ID. Their CRA results can still be quite different.
Run two linked workstreams
The main event lead should own limits and recovery. A product security lead should own the product link and Article 14 check. Link both records with one event ID. Give each its own questions, approver, outside readers, and clocks.
Check the result often while facts change. A first result of “no proven product path” should name open checks. It should state the fact that would reverse it. If product harm meets a severe test, record awareness and start CRA reports. Do not wait for the firm-wide review to close.
Preserve the negative case too
If the event stays outside the CRA term, keep the asset map and product link check. Save the logs checked, choice time, approver, and facts that would reopen it. Do not just write “firm only.” Explain why no proven path harmed or could harm the product guards at issue.
This split lets the team handle one event as a whole. The product security choice stays clear and can be checked. It is tied to the proof that matters under Article 14.
Continue this workflow with the severe-incident test and the CRA and GDPR triage.