Miscalculated S-O-D ratings and skewed Risk Priority Numbers rank among the most common findings quality teams face during AS9100D, ISO 9001, and ISO 13485 audits. FMEA is meant to be proactive. ASQ describes its goal as mitigating or eliminating potential failures before they reach a customer, not documenting them after the fact.
This guide breaks down exactly how to score Severity, Occurrence, and Detection, calculate RPN correctly, and avoid the scoring mistakes that turn a solid FMEA into an audit finding.
Key Takeaways
- Severity, Occurrence, and Detection are rated 1-10 and multiplied into an RPN to prioritize corrective action
- S-O-D numbers are ordinal rankings, not precise measurements; treating them as exact math causes misleading comparisons
- Detection scoring runs backward: a high score means poor detection, not high visibility
- FMEA maps failure modes; ISO 14971 assesses harm probability and severity — complementary tools, not the same document
- AIAG-VDA now favors an Action Priority table over fixed RPN thresholds for deciding what gets fixed first
What Is FMEA Risk Assessment?
FMEA (Failure Mode and Effects Analysis) is a systematic method for identifying potential failure modes in a design or process, then evaluating their severity, occurrence, and detection to prioritize corrective action.
You'll typically see it in two forms:
- DFMEA (Design FMEA) — used during design to catch failure modes before a product ever reaches production
- PFMEA (Process FMEA) — used for manufacturing, assembly, and ongoing process control
Both appear widely in safety-critical industries: aerospace and defense, medical devices, and automotive manufacturing, where SAE and AIAG maintain the governing standards.
FMEA is one input into a broader risk management process, not a replacement for it. The FDA lists FMEA as one commonly used risk-analysis technique among several — it feeds a risk file, but it isn't the whole file.
Severity, Occurrence, and Detection: The Core of FMEA Scoring
S-O-D scoring is the technical engine of FMEA. Get these three ratings wrong, and every downstream priority decision built on them is unreliable — including which failure mode gets fixed first and which one waits.
The most commonly overlooked mistake: teams treat S-O-D numbers as precise measurements instead of ordinal rankings. A Severity of 8 isn't "twice as bad" as a 4. It's simply worse on a ranked scale.
Research published in Safety Science confirms S, O, and D are ordinal-scale variables whose numeric spacing isn't proven to be equal. Averaging or interpolating these scores produces numbers that look precise but aren't.
Severity (S)
Severity measures the seriousness of a failure's worst-case consequence, rated 1 (no effect) to 10 (catastrophic or safety hazard).
Rules that matter:
- Assign severity only through someone qualified to judge consequences: a medical officer for a device risk, a systems engineer for an aircraft component
- If a failure mode has multiple effects, record only the highest severity
- Never let detection capability or occurrence frequency pull a severity rating down
Occurrence (O)
Occurrence measures the likelihood that a specific failure cause will happen, rated 1 (extremely unlikely) to 10 (near certain).
Don't guess this one. Estimate it using:
- Historical failure data from similar parts or processes
- Reliability predictions or field-return rates
- Benchmarks from comparable processes already in production
Rate the cause here, not the effect, and not how severe that effect would be if it happened.
Detection (D)
Detection measures how well current controls can catch the failure mode or its cause before it reaches the customer, rated 1 (certain detection) to 10 (no detection possible).
Here's where teams trip up: Detection scoring runs opposite to Severity and Occurrence. A high Detection score signals weak controls, not strong risk visibility.
A 1 means you'll catch it every time. A 10 means you're flying blind. Better inspection or a poka-yoke device lowers the D score; it never touches Severity.
Calculating RPN and Prioritizing Risk
The formula is simple:
RPN = Severity × Occurrence × Detection
With three 1-10 ratings, RPN can range from 1 to 1,000. Higher numbers flag failure modes that need attention first.
Quick example: A failure mode with Severity 8, Occurrence 4, and Detection 6 produces an RPN of 192. That is high enough to trigger a corrective action with an owner and a deadline to add an inline inspection step. On re-score, Detection drops to 2.
But RPN has a real limitation: because S, O, and D are ordinal, different rating combinations can produce identical RPNs that carry very different risk profiles. A Severity 9 / Occurrence 2 / Detection 2 (RPN 36) is not the same risk as Severity 3 / Occurrence 4 / Detection 3 (RPN 36) — yet the math says otherwise.
That's part of why the AIAG-VDA approach, reflected in SAE J1739, moved toward an Action Priority table (High, Medium, or Low) rather than relying solely on a fixed RPN cutoff. High-severity failure modes get flagged for action regardless of what the RPN number says.
How the FMEA Process Works: Step by Step
FMEA works best as a structured, cross-functional exercise — not something one engineer finishes alone at a desk.
- Assemble the team and define scope. Pull in design, quality, manufacturing, and reliability perspectives. Decide upfront whether this FMEA covers a concept, design, process, or service.
- Identify functions and failure modes. List what the item or process is supposed to do, then brainstorm every way it could fail to do that.
- Determine effects and rate Severity. Identify what happens to the customer, system, or regulatory standing if the failure occurs, then assign the Severity rating.
- Identify causes and rate Occurrence. Trace each failure mode back to its root cause and rate how often that cause is expected to show up.
- Evaluate current controls and rate Detection. Document existing inspections, tests, or poka-yoke devices that would catch the failure, then rate Detection and calculate RPN.
- Prioritize actions and review as a living document. Rank failure modes by RPN or Action Priority, assign owners and deadlines, then re-score once actions are implemented.
Treat the FMEA as a living document. That last step matters more than most teams treat it. FMEAs aren't a one-time form to file away — revisit them whenever designs, processes, or regulations change.
FMEA vs. Risk Assessment: Why the Distinction Matters
These two get confused constantly, and auditors notice when a team treats them as interchangeable.
A formal risk analysis, such as under ISO 14971, evaluates the probability and severity of harm to a patient, user, or environment. An FMEA evaluates failure modes and their engineering effects, not harm directly.
The FDA's own definition of risk under ISO 14971 combines probability and severity of harm, with no separate Detection score.
That's the key distinction:
| Factor | FMEA | Risk Analysis (ISO 14971) |
|---|---|---|
| Unit analyzed | Failure modes, causes, effects | Hazard, hazardous situation, harm |
| Detection scoring | Yes — separate 1-10 rating | No — folded into harm probability |
| Scoring output | RPN or Action Priority | Risk acceptability decision |
Detection is unique to FMEA. In a formal risk analysis, detectability is already absorbed into the probability-of-harm estimate rather than scored on its own.
The two processes are complementary, not interchangeable. FMEA findings on design, process, or software failures feed into and support the broader risk management file. They don't replace it. A medical device team running both should keep the records distinct, with clear mapping between the FMEA and the risk file it informs.
How QMS Learning Helps Teams Build Real FMEA Capability
FMEA capability tends to live in one senior engineer's head. When that person leaves the room, or leaves the company, the rest of the team is left guessing at scoring rationale during an audit.
QMS Learning was built by Will Trikha, a 20-year quality and operations practitioner who has written over 1,000 aerospace and defense audit findings and closed twice that number as a quality manager. That background shapes how the platform treats FMEA: as a skill the whole team applies consistently, not a one-off form.
The AI Workbench's Method Router guides users through the right questions as they work a failure mode. It prompts Severity, Occurrence, and Detection considerations tied to the standard your organization is audited against: AS9100D, ISO 9001, or ISO 13485.
Once a team completes an FMEA scenario, the platform compiles results into a single Audit-Evidence Package built for registrar review:
- Scoring rationale and completed records
- Corrective actions and generated documentation
- Training records and time-stamped activity
The guidance is scoped to the exact standard your team faces, and it stays with the organization permanently rather than leaving when a consultant's contract ends. As standards revise, the guidance updates with them.
FMEA is a living risk document. Review it whenever a design, process, or regulation shifts underneath it.
Frequently Asked Questions
What is FMEA in risk assessment?
FMEA (Failure Mode and Effects Analysis) is a proactive method for identifying failure modes and ranking them by Severity, Occurrence, and Detection. The goal is catching problems before they cause harm or nonconformance, not documenting them afterward.
What is the difference between a risk assessment and an FMEA?
A risk assessment evaluates the probability and severity of harm to a person, patient, or environment. FMEA evaluates failure modes, their causes, and their engineering effects, and those findings feed into the broader risk assessment.
What are the steps of the FMEA process?
Build a cross-functional team, define scope, identify functions and failure modes, rate Severity, Occurrence, and Detection, calculate RPN, then prioritize and act on the highest-risk items. Re-score after corrective actions are implemented.
What is a good RPN score in FMEA?
There's no universal "good" number — thresholds are organization- and standard-specific. AIAG-VDA now favors an Action Priority table (High, Medium, Low) over a fixed RPN cutoff, especially for high-severity failure modes.
What is the difference between DFMEA and PFMEA?
DFMEA (Design FMEA) evaluates failure modes in a product's design before production. PFMEA (Process FMEA) evaluates failure modes in manufacturing and assembly, focused on process control.
How often should an FMEA be updated?
Treat it as a living document. Update it whenever designs, processes, or regulations change, or when new failure data surfaces that contradicts your original Occurrence or Detection ratings.
