How to Build a Risk Management Plan under ISO 14971

A risk management plan is the governance control that determines whether your risk management file stays consistent, traceable, and defensible over time. In audits, weak plans usually correlate with weak files: inconsistent criteria, unclear ownership, missing triggers, and risk controls that cannot be traced to design outputs or verification evidence.

This guide focuses on practical construction of an ISO 14971 risk management plan for medical device manufacturers, including required plan elements and an example table of contents. For the full end-to-end system context (plan → analysis → evaluation → control → PMS integration), refer to ISO 14971 Risk Management System: Step-by-Step Implementation.

1) What the risk management plan must do in practice

The plan is not a formality. It is the “rules of operation” for how risk is identified, evaluated, controlled, approved, and kept alive across the device lifecycle. Your plan must make risk decisions repeatable across:

• Different reviewers and functional teams.
• Different development phases and design changes.
• Different products within a family.
• Different post-market signal conditions (complaints, field performance, vigilance triggers).

If a plan does not define governance and criteria clearly, risk decisions drift. Drift becomes audit nonconformities: inconsistent severity ratings, vague residual risk rationale, missing linkages to verification evidence, and ad hoc updates that cannot be traced.

2) When to create or update the plan

Create the plan before risk analysis begins. Updating the plan later to fit outcomes undermines defensibility. Plan updates are allowed, but they must be governed and justified.

Create the plan at minimum when:

• Starting a new device development or significant design change program.
• Implementing ISO 14971 for the first time.
• Recovering from audit findings related to risk traceability or residual risk logic.
• Entering new markets with different regulatory expectations for risk evidence.

Update the plan when:

• Risk acceptability criteria are being revised (must be controlled and justified).
• Methods or tools change (e.g., new worksheet structure, new controlled templates).
• Organizational roles and approval authorities change.
• Post-market feedback shows your criteria or assumptions are systematically misaligned with field reality.

3) Core plan elements: scope, responsibilities, criteria

A) Scope (what is covered and what is not)

Auditors expect scope to be explicit and device-specific. A scope statement should allow a third party to understand what the plan governs without guesswork.

• Device identification: device name, model(s), family, variants, and accessories in scope.
• Intended use and users: intended purpose, user groups (clinicians, lay users), and use environment (clinical, home, EMS, lab).
• Lifecycle coverage: development, design transfer, production, distribution, servicing, decommissioning (as applicable).
• Software and connectivity scope: software functions, cybersecurity-relevant functions, connectivity/remote features.
• Interfaces: what parts of the QMS the plan links to (design controls, change control, complaint handling, post-market monitoring).
• Exclusions: justified exclusions (e.g., components out of scope, accessories managed under separate plans) with rationale and reference to the applicable plan.

Scope must also define your “risk file boundary.” If you split risk across multiple documents (e.g., a core file plus a usability-focused annex, a cybersecurity annex, or a manufacturing risk annex), your plan must define how those pieces integrate and remain consistent.

B) Responsibilities (ownership, competence, and approval authority)

Define responsibilities as roles, not individuals. Auditors sample whether responsible roles exist, whether they are competent for their tasks, and whether approvals are performed by defined authority.

• Risk management owner: accountable for maintaining the risk file, ensuring updates occur, and ensuring traceability remains intact.
• Cross-functional contributors: design engineering, manufacturing engineering, quality, regulatory, clinical (where applicable), service/aftermarket, and supply chain.
• Reviewers: defined reviewers by topic (e.g., clinical reviewer for clinical harm pathways, manufacturing reviewer for process control measures).
• Approver(s): final authority for approval of plan and key risk file states (baseline, major updates, release readiness).

Responsibility definitions should also include:

• What each role must produce (outputs) and when.
• What each role must verify (evidence checks).
• Escalation rules for unresolved risk acceptability decisions.
• RACI-style clarity for multi-disciplinary decisions.

C) Criteria (acceptability, residual risk, and decision logic)

Criteria are the most heavily tested part of the plan because criteria drive design decisions and residual risk justification. Criteria must be defined in a way that is consistent, usable, and auditable.

Severity criteria

• Define severity in clinical/user impact terms relevant to your device, not generic labels.
• Ensure definitions distinguish between minor reversible harm and serious injury outcomes.
• Define how you handle multiple harm severities from the same hazardous situation (worst credible harm vs scenario-based severity).

Occurrence approach

• Define how occurrence is estimated or bounded (historical data, similar devices, testing evidence, process capability, field data assumptions).
• Define what to do when occurrence cannot be credibly quantified (bounded assumptions, conservative categorization, enhanced monitoring triggers).
• Define how occurrence changes are detected post-market (trend thresholds and review triggers).

Acceptability criteria

• Define acceptability zones and decision rules that translate into required actions.
• Define when risk controls are mandatory and what evidence is required before acceptance.
• Define when benefit-risk rationale is required and what it must address (high-level, operational rationale expectations).

Residual risk criteria

• Define how residual risk is evaluated after controls are implemented and verified.
• Define when information for safety is required and how it must align with the remaining hazardous situation pathway.
• Define the required monitoring assumptions: what PMS signals would challenge residual risk conclusions.

4) Example risk management plan table of contents

The structure below is suitable for small–mid manufacturers and scales cleanly. It is written as a table-of-contents model rather than a theoretical outline, so you can implement it directly.

Section	What it contains	Why auditors care
1. Device scope and intended use	Device family, variants, users, use environment, lifecycle stages	Defines boundaries of hazard identification and file completeness
2. Roles, responsibilities, approvals	Owner, contributors, reviewers, approvers, escalation rules	Shows controlled governance and authority for decisions
3. Risk acceptability criteria	Severity definitions, occurrence approach, acceptability zones	Tests consistency and prevents criteria manipulation
4. Methods and tools	Hazard identification methods, worksheets, templates, conventions	Shows systematic approach, not ad hoc hazard listing
5. Risk analysis approach	Sequence-of-events logic, foreseeable misuse, use error inputs	Demonstrates completeness and reasoning quality
6. Risk control strategy	Control hierarchy, selection logic, verification expectations	Tests whether controls are implemented and verifiable
7. Residual risk and information for safety	Residual risk evaluation rules, labeling alignment expectations	Tests justification and communication consistency
8. Traceability requirements	How risk controls link to design inputs/outputs and verification evidence	Addresses weak traceability findings
9. Interfaces and triggers	Change control triggers, CAPA triggers, PMS triggers, review cadence	Defines “keep alive” governance and lifecycle updates
10. Risk management file structure	File index, document IDs, retention, controlled storage, revisions	Supports retrieval under audit and historical traceability

5) Plan content: what to write under each critical heading

5.1 Device scope and intended use

Make the scope operational, not marketing. Include the user, environment, and operational conditions that materially affect hazard pathways (power conditions, cleaning conditions, storage, connectivity, maintenance behaviors). If your device is used in home environments, your plan should reflect foreseeable variability in user competence and environment control.

5.2 Roles, responsibilities, approvals

Define approval checkpoints. Typical checkpoints that survive audit sampling:

• Plan approval: before risk work begins.
• Baseline risk analysis approval: before design freeze or before formal verification begins.
• Risk control implementation checkpoint: before release readiness decisions.
• Post-market review checkpoint: periodic and event-triggered reviews with documented outcomes.

Define escalation rules for cases where risk acceptability is disputed. Disputes should not be “resolved” by changing criteria. They should be resolved by additional controls, additional evidence, or documented benefit-risk rationale per your governance rules.

5.3 Risk acceptability criteria

Document how criteria are applied. The plan should explicitly state that criteria are established in advance and applied consistently, and that any changes to criteria are controlled changes requiring justification, review, and approval.

Define how you handle uncertainty. Many audit failures occur because teams assign occurrence values without a credible basis. Your plan should define what you do when occurrence data is weak, including conservative categorization and specific post-market monitoring triggers that compensate for uncertainty.

5.4 Methods and tools

Define the method set you will use for hazard identification and risk analysis. A practical approach is to require at least two complementary methods (e.g., design decomposition plus use scenario analysis), and to define the minimum required sources of post-market input (complaints, returns, service data, literature).

Also define templates and conventions:

• Risk item ID conventions and stability rules (avoid renumbering).
• What fields are mandatory in risk records (hazard, hazardous situation, harm, control, verification evidence reference).
• How references are recorded (controlled document identifiers, report IDs, not informal filenames).

5.5 Risk control strategy and verification expectations

Your plan should define how controls are selected and how implementation is proven. A recurring audit weakness is “controls listed without evidence.” Address it by defining that every control must have:

• A defined control type (design, protective measure, information for safety).
• A defined implementation artifact (design output, process control, labeling statement).
• A defined verification method (test report, inspection evidence, validation evidence, review evidence).
• An evidence reference recorded in the risk file.

5.6 Interfaces and triggers (the “keep alive” engine)

“Keep alive” is not a slogan. It is a trigger set and a review cadence with defined outputs. Your plan must define at minimum:

• Periodic review cadence: e.g., quarterly for early-stage products, annually for stable products, or aligned to management review intervals where appropriate.
• Event-based triggers: specific events that force risk review and documented conclusions.

High-value triggers include:

• Design changes that alter materials, energy outputs, software functions, UI flows, alarms, connectivity, or performance claims.
• Manufacturing changes affecting critical-to-quality characteristics or inspection methods.
• Supplier changes for critical components or processes.
• Complaint trends, new complaint types, or changes in severity distribution.
• Field performance signals suggesting control drift or new hazardous situations.
• Vigilance events or field actions requiring reassessment of hazards and residual risk communication.

Define the required outputs of each triggered review: risk file update, documented “no change” rationale, change control initiation, labeling change proposal, verification update plan, or monitoring escalation.

6) Common plan weaknesses that lead to audit findings

Weakness 1: Criteria are vague or not usable

• What happens: inconsistent severity and acceptability decisions across reviewers and time.
• Correction: tighten definitions, define decision rules, and include uncertainty handling.

Weakness 2: Ownership and approval authority are informal

• What happens: approvals performed by convenience; no clear accountability for updates post-release.
• Correction: assign role-based ownership and define approval checkpoints with authority.

Weakness 3: “Keep alive” triggers are missing

• What happens: post-market information accumulates without risk file updates; auditors flag risk file as stale.
• Correction: define triggers and cadence; require documented outcomes for each review event.

Weakness 4: Traceability rules are absent

• What happens: risk controls cannot be traced to design inputs and verification evidence; residual risk conclusions are unsupported.
• Correction: require control-to-evidence referencing as a mandatory plan rule.

7) Minimal implementation sequence (practical build order)

1. Define device scope and boundaries, including variants and accessories.
2. Assign role-based ownership, reviewers, and approvers.
3. Define severity and acceptability criteria with uncertainty handling rules.
4. Define hazard identification methods and minimum required data sources.
5. Define risk control strategy and evidence expectations for implementation and verification.
6. Define traceability rules to design outputs and verification evidence references.
7. Define review cadence and event triggers for lifecycle updates.
8. Approve the plan before risk analysis begins and control plan changes thereafter.

Conclusion

A risk management plan is the control layer that makes an ISO 14971 risk management system auditable and sustainable. When scope, responsibilities, criteria, and lifecycle triggers are explicit, risk files remain consistent, traceable, and defensible during both certification audits and technical documentation review.

Once your plan is established, implement the full workflow (plan → analysis → evaluation → control → PMS) and ensure linkages to design changes and post-market signals remain active. Use ISO 14971 Risk Management System: Step-by-Step Implementation to align your plan with the complete end-to-end implementation approach.