The CRA test is narrower than “someone says this is exploited.” It requires reliable evidence that a malicious actor used the vulnerability in a system without the system owner’s permission. A threat feed, customer message, internal detection, or public claim is therefore an input to assess, not a conclusion to copy.
That distinction matters when sources disagree. The team needs a fast way to preserve each signal, test it against the same criteria, and record when the available evidence becomes reliable enough to support the decision.
Separate observations from interpretations
Create one line for every material signal. Record the original source, receipt time, affected product named, version or configuration, observed behaviour, underlying artefact, and any stated confidence. Keep the source’s wording separate from the manufacturer’s interpretation.
Then ask four questions: does the evidence concern the manufacturer’s product, does it show actual use rather than mere exploitability, does it identify malicious activity, and was the activity outside the system owner’s permission? A laboratory proof, authorised penetration test, or vulnerability score may still demand urgent remediation, but it answers a different question from the statutory definition.
Reconcile conflicts without averaging them
Do not turn two weak signals into one strong conclusion by counting them. Check whether supposedly independent reports repeat the same unverified origin. Compare timestamps, indicators, product fingerprints, execution traces, and customer context. Note whether a denial rests on newer evidence or simply on an absence of telemetry.
Use a short disposition for each signal: corroborated, contradicted, not product-applicable, authorised activity, or unresolved. Name the evidence that would change the disposition. This makes disagreement visible without forcing the case into a premature yes or no.
Give the decision a controlled boundary
Assign one decision owner and one deputy with access to product security, incident response, legal, and customer evidence. The owner should record the evidence set considered, the conclusion, the decision time, and the next review trigger. Preserve dissent and uncertainty rather than editing them out of the record.
If the definition is met, capture the awareness timestamp and enter the reporting path. Do not postpone the early warning merely to complete root-cause analysis. If the definition is not yet met, keep the case active with a named next check and a short interval appropriate to the risk.
Reopen on changed facts
A defensible “not established” decision is not permanent. Reopen it when a customer provides artefacts, telemetry becomes available, a CSIRT corroborates exploitation, a product-version link is confirmed, or an assumed authorised test proves unauthorised.
The useful output is not a confidence score. It is a traceable explanation of what the manufacturer knew, why the evidence did or did not satisfy each element, who decided, and what fact would cause a new decision.
Continue this workflow with the actively exploited vulnerability definition and the non-reportable decision record.