CRA and functional safety: one documentation set, not two

When the CRA lands on the desk of a company that already develops safety-critical products, the instinctive response is to open a new workstream: new team, new process, new documentation tree. I understand the instinct — and it's usually the most expensive way to comply.

You already produce most of the raw material

Look at what the CRA's essential requirements and technical documentation actually ask for, and compare it to what a functional safety process already generates:

• The CRA wants a cybersecurity risk assessment that informs design decisions. Your safety process already runs structured risk analysis with documented rationale — the method transfers, the mindset is identical.
• The CRA wants evidence of a secure development process. Your safety lifecycle already enforces requirements traceability, verification, configuration management, and change control — the exact process discipline the CRA assumes.
• The CRA wants ongoing vulnerability handling across the support period. Safety teams already run field monitoring and controlled updates, because an uncontrolled change to a safety-critical product is unthinkable.
• Both regimes end in the same artifact: a structured technical file that argues, with evidence, that the product is acceptably safe — or secure — for its intended use.

Where the two genuinely differ

Reuse has limits, and pretending otherwise causes its own problems. Safety analysis assumes random faults and foreseeable misuse; security analysis assumes an intelligent adversary who adapts. A hazard analysis cannot simply be relabeled as a threat analysis. The threat side needs its own method — but it can and should share the same item definition, the same system boundaries, and the same assumptions as the safety side.

That last point is where projects most often go wrong: safety and security teams working from subtly different system descriptions, producing analyses that quietly contradict each other. Auditors notice.

What an integrated approach looks like

• One system description and one set of assumptions, referenced by both analyses.
• A mapping from your existing safety work products to the CRA's documentation requirements — filled where gaps exist, reused where they don't.
• A single change-management process that evaluates both safety impact and security impact before any update ships.
• Cross-references instead of copies: the security case points to safety evidence where it applies, and vice versa.