Learn how to use a risk-based FMEA workflow to identify failure modes, select controls, set testing priorities, and document residual risk.
What is risk-based validation?
Risk-based validation directs assurance effort toward failures that could affect product quality, patient safety, data integrity, or a critical business decision. It is a method for choosing evidence, not a reason to remove evidence.
FMEA, or failure mode and effects analysis, gives teams a structured way to identify how a process or system could fail and what controls reduce the risk.
How does an FMEA support validation?
| FMEA step | Validation use |
|---|---|
| Failure mode | Define what could go wrong |
| Effect | Describe the consequence to the process or record |
| Cause | Identify how the failure could occur |
| Existing control | Show prevention or detection |
| Risk assessment | Set priority and review depth |
| Action | Assign a control, test, owner, or decision |
How should failure modes be identified?
Walk the real process from input to output. Include users, data entry, calculations, approvals, interfaces, reports, exports, exceptions, and administration. Ask where a wrong value, missing record, unauthorised action, or unavailable service could change the outcome.
- Review process maps and requirements.
- Interview users and subject-matter experts.
- Use incidents and deviations as evidence.
- Include negative and unusual paths.
- Check supplier and integration boundaries.
How should testing priorities be set?
Use the risk assessment to prioritise high-consequence and poorly controlled failure modes. Test prevention controls, detection controls, permissions, calculations, audit trails, interfaces, and recovery where they matter to the intended use.
Do not rank a failure mode only by technical inconvenience. Consider what the failure means for the regulated process and the record used to make a decision.
How should residual risk be handled?
After controls and tests are defined, reassess the remaining risk. State what is still possible, what compensating control exists, who accepts it, and when it will be reviewed. Residual risk should not disappear simply because a test passed.
The question is not “Did we test?” It is “What risk does this evidence control?”
What makes the workflow defensible?
Keep stable IDs for failure modes, controls, requirements, tests, deviations, and actions. Link the FMEA to the validation plan and traceability matrix. Update it when intended use, configuration, data, supplier, or process changes.
What should the working record contain?
Keep the decision, evidence, and ownership together. A reviewer should be able to see the current baseline, the reason for the activity, the people who approved it, and the records that support the conclusion. Use stable identifiers for requirements, risks, tests, actions, and versions so a later review does not depend on one person's memory.
Good lifecycle records explain both the decision and its limits. Record assumptions, exclusions, unresolved questions, and the date when the conclusion should be revisited. This makes the next change or review faster without turning the file into a wall of generic text.
- State the system and process boundary.
- Link the activity to intended use and risk.
- Preserve original results and approved corrections.
- Assign an owner to every open action.
- Record the final decision and residual risk.
How can teams keep the process practical?
Use short decision gates instead of one large end-of-project review. At each gate, ask what is known, what remains open, who owns the next action, and whether the current risk is acceptable. This keeps the work moving while preserving an auditable trail.
Make the record useful to the people who operate the system. Link procedures, training, access decisions, and evidence to the same controlled item. When a future reviewer can understand the context without opening several disconnected folders, the lifecycle is doing its job.
Review the process after the first release. Operational experience often reveals a missing requirement, an unclear role, or a control that looked adequate on paper but is difficult to use. Feed those findings into the next controlled decision.
FAQ
Is FMEA required for every validation project?
The organisation may use another risk method. The important requirement is a documented, proportionate assessment that informs assurance work.
Can one control address several failure modes?
Yes, if the relationship is explicit and the control is tested against each relevant outcome.
What if experts disagree on severity?
Record the discussion, criteria, decision owner, and rationale. Consistent scoring rules help, but the reasoning matters more than a number alone.
When should the FMEA be updated?
Update it when new information, incidents, changes, supplier events, or process changes alter the risk picture.
Conclusion
Risk-based validation is disciplined prioritisation. Use FMEA to connect failure modes to controls, tests, owners, and residual-risk decisions.
Turn risk assessment into traceable action
Connect failure modes, controls, requirements, tests, and approvals across the lifecycle.
Build a risk-based workflow →