All articles

Retained evidence

How to build a CRA vulnerability case file that survives review

Connect the product, chronology, reporting assessment, corrective work and final evidence so the case can be reconstructed later.

20 August 2026 5 min read Dlovan Sharif
An animated open evidence case holding organised vulnerability records and a sealed decision file

A vulnerability ticket is an input to the CRA case. The case also needs the product scope, awareness chronology, reporting assessment, responsible people, corrective action and final evidence. The useful test is simple: can another person reconstruct what happened without asking the original owner to remember it?

Finish this job

Close one case with enough evidence to reconstruct it

CRA Operations connects the technical facts, regulatory decision, owner, dates and retained evidence without turning the ticket into a second product backlog.
  1. 1Preserve identity and chronology.
  2. 2Separate supplied facts from the reporting conclusion.
  3. 3Close with the decision, corrective action and evidence.
Start a vulnerability case

Start with identity and chronology

Identify the product, affected versions and the vulnerability or incident being assessed. Preserve important timestamps as events so later edits do not erase the sequence:

  • Initial signal received.
  • Awareness confirmed for the reporting assessment.
  • Early-warning and notification decisions recorded.
  • Corrective or mitigating measure made available.
  • Case closed with final evidence.

Separate facts from the conclusion

The technical finding, evidence of exploitation, security impact and mitigation status are facts supplied by the people closest to the work. The reporting route is a decision made from those facts under a particular interpretation.

Keep the supplied facts, their sources and the decision visible as separate parts of the same case. A corrected fact can then trigger a new assessment without rewriting what the team knew earlier.

Record ownership at each handoff

Engineering may confirm affected versions, security may assess exploitation and impact, and compliance may own the reporting route. Give each requested fact and decision a named owner and due time.

That makes the case operational while work is in progress and understandable after it closes.

Close with evidence, not a status label

A closed record should show the final reporting route, the person responsible, notices or reports submitted, the corrective measure, user communication where relevant and the sources used for the decision.

Keep the final case as a retained record. If the product, facts or interpretation later change, open a new assessment and preserve the earlier one.

Working guidance

This article explains an operational approach to CRA preparation. It does not replace the Regulation, official guidance or advice for a specific product and organisation.

Written by Dlovan Sharif

Founder, CRA Operations. Primary legal sources are linked alongside the article.