Why “Article 9-ready” Risk Management Starts With the Register
Auditors don’t approve risk management systems because they look sophisticated; they approve them because they are traceable, repeatable, and complete across the lifecycle. The most defensible way to prove that is a lifecycle risk register that links hazards to controls, verifies effectiveness, and stays current as the product changes.
An “Article 9-satisfying” system (as commonly interpreted in regulated contexts) typically expects you to demonstrate:
- A documented process for identifying, evaluating, controlling, and monitoring risk
- Ongoing risk management from concept through post-market operation
- Clear accountability and governance
- Evidence that risk controls were implemented and verified
- A closed-loop system for changes, complaints, and incidents feeding back into risk updates
The register is the spine that holds that evidence together.
Step 1: Define Scope, Lifecycle Phases, and Ownership
Before creating fields and templates, set boundaries so the register is auditable.
Define scope
- Product(s), variants, configurations, accessories, and intended use
- Users and use environments
- Interfaces with other systems (hardware, software, services)
- Assumptions and exclusions (and who approved them)
Map lifecycle phases Use phases that match your development and operational reality, such as:
- Concept and feasibility
- Design and development
- Verification and validation
- Release and distribution
- Operation and maintenance (including updates)
- Post-market monitoring and end-of-life
Assign ownership Auditors look for a clear “who does what.” At minimum:
- A risk management owner accountable for the process and register integrity
- Cross-functional contributors (engineering, clinical/medical, quality, operations, support)
- Approvers for risk acceptability decisions (often separate from the author)
Step 2: Choose a Risk Model You Can Defend
You need a consistent method to evaluate risk and show decisions weren’t arbitrary.
Define the evaluation approach
- Severity scale (impact to people, property, environment, compliance, business continuity—tailor to your regulatory context)
- Likelihood scale (occurrence probability or frequency band)
- Detectability (optional; if used, define it precisely and apply consistently)
Set risk acceptability criteria
- What is acceptable without action
- What requires mitigation
- What is unacceptable and must be redesigned or stopped
- Criteria for “as low as reasonably practicable” or equivalent rationale (document what “reasonable” means in your organization)
Common audit pitfalls
- Mixing qualitative and quantitative estimates without rules
- Changing scales mid-project
- Accepting high residual risks without documented justification and approvals
Step 3: Design a Lifecycle Risk Register Structure (Fields Auditors Expect)
A register that auditors accept is typically relational, even if implemented in a spreadsheet. Each record should be traceable to upstream and downstream artifacts.
Include these core fields:
Identification and traceability
- Unique Risk ID (stable across revisions)
- Product/version/configuration reference
- Lifecycle phase where the risk was identified
- Linked requirements, design elements, test cases, tickets, and change requests (use internal identifiers)
Hazard and scenario definition
- Hazard (the potential source of harm)
- Hazardous situation (the circumstance in which people/assets are exposed)
- Foreseeable sequence of events (clear narrative)
- Harm (the actual injury/damage outcome)
- Affected users/stakeholders and environment of use
Risk evaluation
- Initial severity and likelihood (with rationale)
- Initial risk level (derived from your matrix or method)
- Risk acceptability decision (pre-control)
Risk controls
- Control measures (design controls, protective measures, information for safety, operational controls)
- Control type (preventive/detective/corrective)
- Control owner and implementation status
- Verification method and acceptance criteria (how you’ll prove it works)
- Verification evidence reference (test report ID, review record ID, etc.)
Residual risk and benefit considerations
- Residual severity/likelihood and residual risk level
- Residual risk acceptability decision (post-control)
- Risk–benefit justification (when needed)
- Disclosure/labeling requirements (if applicable)
Lifecycle monitoring
- Post-market signals to monitor (complaint codes, telemetry events, audit findings, service trends)
- Review frequency and triggers
- Date of last review, next review due
- Linked CAPA, incidents, and changes
Version control
- Register revision and change history
- Decision approvals with dates and roles
Tip: If your tool allows it, separate “Hazard” from “Scenario” and “Control” into linked tables. This reduces duplication and makes updates safer.
Step 4: Populate the Register Using Multiple Hazard Discovery Methods
Auditors are skeptical of a register that appears to be brainstormed once and then forgotten. Build credibility by using multiple, documented discovery inputs:
- Design reviews and architecture analysis
- Process mapping and use-case workflows
- Misuse and reasonably foreseeable abuse analysis
- Human factors considerations (use errors, confusing UI, fatigue, time pressure)
- Software failure modes and cybersecurity threat scenarios (where relevant)
- Supplier and component risk assessments
- Installation, maintenance, and service procedures
- Historical issues from prior versions or similar products
- Complaints and incident learnings (post-release)
For each risk entry, capture how it was identified (e.g., “design review DR-014” or “service trend analysis Q2”).
Step 5: Write Scenarios That Are Specific Enough to Test
Vague entries like “data loss” or “device malfunction” are hard to verify and easy to challenge.
A testable scenario has:
- A clear initiating event (what goes wrong)
- The exposure pathway (how it affects users)
- The harm (what outcome occurs)
- The context (when/where/who)
Example pattern (template)
- Initiating event: “During update, power interruption occurs”
- Hazardous situation: “System boots with incomplete configuration”
- Harm: “Incorrect output leads to unsafe decision”
- Users/environment: “Trained operator in time-pressured setting”
This level of specificity makes it easier to define risk controls and verification tests that match the scenario.
Step 6: Define Controls With Verification in Mind
A risk control that can’t be verified is a weak control in an audit.
For every control, include:
- What the control is (mechanism)
- Where it is implemented (component/module/process step)
- How it reduces severity and/or likelihood
- How you will verify it (test, inspection, analysis, simulation, review)
- Acceptance criteria (measurable where possible)
Use a control hierarchy where appropriate:
- Inherent safety by design (preferred)
- Protective measures (guards, interlocks, access control)
- Information for safety (warnings, training, labeling)
- Operational monitoring and response (alerts, logging, procedures)
Auditors typically expect that if you rely on “information for safety,” you can justify why design-based controls weren’t feasible and show the information is clear and effective.
Step 7: Make Residual Risk Decisions Explicit (And Approve Them)
Residual risk acceptance should be a documented decision, not an implied outcome.
Include:
- Residual risk rating and rationale
- Whether residual risk is acceptable per policy
- If not acceptable, what additional controls or design changes are required
- If accepted despite being high, a risk–benefit justification and escalation to the appropriate approval authority
Also consider overall residual risk: even if each individual risk is acceptable, auditors may ask how you judged the aggregate risk profile.
Step 8: Connect the Register to Change Control, CAPA, and Post-Market Monitoring
A lifecycle register must stay alive after release. Build an explicit closed-loop:
Change control triggers
- New features or configuration changes
- Supplier/component substitutions
- Manufacturing or process changes
- Field updates, patches, parameter changes
- New use environments or user types
Require that each change request includes:
- A risk impact assessment
- Updated register entries (new/modified scenarios)
- Updated verification evidence as needed
CAPA and incident linkage When complaints, incidents, or audit findings occur:
- Link them to affected risk IDs
- Reassess severity/likelihood using real-world data
- Add or strengthen controls
- Update residual risk acceptance and verification evidence
Periodic reviews Set review cadence and triggers (e.g., quarterly, major release, supplier change, incident trend). Record outcomes even if “no changes,” so auditors see active monitoring.
Step 9: Prepare Auditor-Friendly Outputs
Even with a strong register, audits go smoother when you can produce clear, consistent artifacts quickly.
Maintain these ready-to-export views:
- Risk summary by lifecycle phase
- Top residual risks and their justifications
- Control verification status (implemented vs. verified)
- Traceability report: scenario → control → test → evidence
- Post-market review log and resulting updates
During an audit, the goal is to show the system is not a static document but an operational discipline.
Step 10: Run a Self-Audit Checklist Before the Real Audit
Use this checklist to find weaknesses early:
- Every risk has a scenario narrative, not just a label
- Every control has verification evidence or a scheduled plan with dates/owners
- Residual risk acceptance is explicit and approved
- Register entries reflect the current product version and configuration
- Changes, incidents, and CAPAs are linked back to the register
- Risk scales and acceptance criteria are consistent and documented
- The register shows review history and monitoring triggers
- No “orphan” tests/requirements exist without a corresponding risk rationale (and vice versa)
Build for Traceability, Not Just Compliance
A risk management system that satisfies Article 9 expectations is one where an auditor can pick any high-impact scenario and follow a clean thread: how it was identified, how it was evaluated, what was done, how effectiveness was proven, and how it stays controlled after release. If your lifecycle risk register can do that reliably, you’re not just audit-ready—you’re operationally safer and faster when change inevitably comes.