Why Risk Controls and Verification Evidence Should Be Connected

The cost of separation

Risk analysis usually describes hazards, mechanisms, harms, and controls. Verification activities are recorded in a separate set of documents. The two sides may use different identifiers, different wording, and even different owners. As a result, answering "what evidence supports this control?" requires manually searching several files.

The separation becomes more expensive during audits, design changes, and post-market surveillance. More seriously, some controls may have no corresponding verification evidence, or the evidence may be outdated, without anyone noticing in time.

What "connected" means

• Every risk control has a stable identifier
• Every verification activity can be traced to the control it supports
• Every verification conclusion can be traced to input data, method, and review records
• Post-control residual risk can be traced back to the original risk entry
• When a change occurs, the affected risks, controls, and verification can be found by following relationships

Why it matters

A connected structure supports three kinds of work: change-impact analysis, review preparation, and evidence-completeness checks. Teams do not have to start from scratch each time; they can navigate known relationships. This does not guarantee a correct conclusion, but it reduces the chance of missing something.

The boundary: mapping is not adequacy

Connecting a control to a verification activity only shows that someone established the relationship. It does not prove that the method was adequate, the sample size was appropriate, the acceptance criteria were sound, or the result supports control effectiveness. Those judgments still require engineering and regulatory review of the specific evidence.

Practical steps

• Use stable, reusable identifiers for risks, controls, and verification activities
• Record provenance and review status on the relationship, not just a line on a diagram
• Make "unlinked" or "evidence missing" an explicit state rather than a hidden problem
• Follow the relationship chain downstream when a change occurs
• Periodically sample and re-check whether the relationships still hold