Who is accountable when CRA evidence is incomplete after an incident?

Why This Matters for Security Teams

When CRA evidence is incomplete after an incident, the issue is not only technical. It becomes a governance and product assurance problem because the organisation may be unable to demonstrate what happened, what was affected, and what was fixed. Under the EU Cyber Resilience Act, manufacturers need defensible evidence of security processes, incident handling, and remediation. If logs, access records, or change history are missing, accountability quickly shifts from “who caused it” to “who failed to preserve proof.”

Security teams often underestimate how quickly evidence gaps turn into reporting gaps. Incident response, engineering, product, and compliance functions may each hold part of the answer, but none can reconstruct the full chain if ownership was not assigned in advance. The practical risk is not just regulatory exposure. It is also the loss of trust in the organisation’s ability to explain control performance, prove containment, and support a credible post-incident review. Current guidance suggests that evidence readiness must be designed into operational controls, not added as a last-minute legal exercise. In practice, many teams discover this only after the incident record is already fragmented across systems, chat threads, and manual notes.

How It Works in Practice

In CRA-aligned environments, accountability should be anchored to the product manufacturer because the manufacturer is the entity expected to maintain conformity, security documentation, and incident records. Operational ownership, however, is distributed. Engineering owns the logging and telemetry design, security owns detection and incident handling, and response or compliance functions own preservation, reporting, and evidence assembly. That split matters because incomplete evidence usually reflects a failure in control design rather than a single person’s mistake.

A practical model is to assign explicit evidence owners for each critical artifact class:

• System and application logs: owned by engineering or platform teams.
• Access and privilege records: owned jointly by identity and security teams.
• Incident timeline and containment actions: owned by the incident commander.
• Remediation proof and validation: owned by the product or service owner.

That structure maps well to control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, where auditability, accountability, and evidence retention are treated as operational controls rather than after-the-fact documentation tasks. For AI-enabled products, the same logic applies to model outputs, prompt traces, tool calls, and approval records, especially where autonomous actions can change system state. Recent industry reporting on the Anthropic — first AI-orchestrated cyber espionage campaign report is a reminder that detailed activity records can become essential when AI systems are involved in security-relevant workflows.

Best practice is to define evidence retention, access scope, and chain-of-custody before an incident occurs, including who can freeze logs, who can export them, and who validates integrity. These controls tend to break down in fast-moving cloud-native environments where short log retention, distributed ownership, and ad hoc incident handling make it impossible to reconstruct events after the fact.

Common Variations and Edge Cases

Tighter evidence retention often increases storage, process overhead, and privacy review burden, so organisations must balance investigatory value against data minimisation and operational cost. That tradeoff becomes more visible when products process personal data, telemetry from customer devices, or AI interaction logs that may contain sensitive prompts or outputs.

There is no universal standard for exactly how much evidence is enough for every CRA incident, so current guidance suggests setting a tiered model based on product criticality and incident severity. For lower-risk issues, a concise incident package may be sufficient. For serious vulnerabilities or suspected compromise, the evidence set should expand to include configuration snapshots, authentication events, relevant secrets access, code or deployment changes, and any AI agent actions if the product uses autonomous tooling.

Edge cases often appear when the organisation relies on third parties. Cloud providers, managed service partners, and outsourced SOC functions may hold key telemetry, but accountability still sits with the manufacturer to request, preserve, and validate it. Another common gap arises where product teams assume observability equals evidence. It does not. Evidence needs integrity, retention, and an owner who can explain why it is trustworthy. In practice, the hardest failures happen when a vendor platform is blamed for missing logs, but the real cause is that no internal function was assigned to preserve them in the first place.

Related resources from NHI Mgmt Group

• Who is accountable when GDPR evidence cannot be reconstructed after an incident?
• Who is accountable when compliance evidence is incomplete?
• Who is accountable when SOC 2 evidence is incomplete?
• Who is accountable when ISO 27001 evidence is incomplete or inconsistent?