Linking risk

Risk that sits in its own silo can’t be managed against the design. Linking risks to the rest of your work puts them on the thread, so the impact of a change on your risk picture — and the verification behind your controls — is always visible.

Risk and requirements

A risk control is realized as a requirement: the design measure that reduces the risk. Linking a risk to the requirement that implements its control connects the analysis to the design. When that requirement changes, the risk is flagged for re-evaluation rather than silently drifting out of date.

Risk and tests

A control is only credible if it’s verified. Linking risks to the tests that demonstrate their controls work gives you risk-based verification coverage — a view of which risks are backed by passing tests and which still rely on unverified controls. This is exactly the evidence a safety case depends on.

Risk and architecture

Risks also connect to the architecture — the elements and interfaces where a hazard arises or is controlled. Tying risk to the model means a change to a component can surface the risks associated with it, so design decisions are made with their risk implications in view.

Risk and the supply chain

Risks can connect to SBOM components too, linking a vulnerability or a third-party part to the risk it poses. This brings supply-chain concerns into the same risk analysis as everything else (see SBOM).

Why it matters

Linked risk is living risk. Because the connections are real, the platform can flag affected risks suspect when something they depend on changes, show coverage of controls by verification, and trace from a hazard all the way to the test that proves it’s handled. The broader mechanics — the trace matrix, suspect links, and impact analysis — are covered in Traceability.