FMEA Severity, Occurrence, and Detection Ratings

Severity, occurrence, and detection are the three FMEA ratings. Severity scores how bad a failure's effect is, occurrence scores how often its cause happens, and detection scores how unlikely your current controls are to catch it. Each uses a 1-to-10 scale where higher is worse, including detection, where 10 means you would not catch the failure.

These three numbers are the whole engine of an FMEA. Rank on them and you decide where a plant spends its quality effort, so if the scores are soft or inconsistent, every priority built on top of them is wrong. The hard part is not the arithmetic; it is scoring the same failure the same way every time, across different people and different days. This guide explains what each rating measures, how to anchor a 1-to-10 scale so it means something, and how to calibrate a team so the numbers hold up.

What is severity and how do you score it?

Severity rates how bad the effect is if the failure reaches the customer, on a scale of 1 (no noticeable effect) to 10 (a safety hazard or regulatory violation, often without warning). The single most important rule: severity is a property of the effect not the cause and not the likelihood. A failure that could hurt someone is a 10 even if it almost never happens, because rarity is captured by occurrence, not by softening the severity. If one failure mode has several possible effects, you score the worst one.

Severity is also the rating you almost never reduce by adding controls. You lower severity only by changing the design or the product so the bad effect can no longer happen, removing a sharp edge, adding a fail-safe, eliminating a hazardous energy path. Better inspection does not touch severity; it touches detection. Keeping that straight is what stops teams from talking themselves out of a high number.

What is occurrence and how do you score it?

Occurrence rates how often the cause of the failure is likely to happen, from 1 (failure is nearly impossible) to 10 (failure is almost certain or persistent). It is a statement about the cause under your current process and controls, not about how bad the result would be. The anchor that keeps occurrence honest is real data: field returns, scrap and defect rates, warranty history, and process capability. A team that scores occurrence from gut feel drifts toward the middle, where everything becomes a 5 and nothing stands out.

You lower occurrence by attacking the cause, mistake-proofing a step, tightening a process window, removing a source of variation. Because occurrence is tied to how the process actually behaves, it is the rating that goes stale fastest: the moment the process changes, or the field reveals the cause is more common than you thought, the old occurrence score is a claim that is no longer true.

What is detection and how do you score it?

Detection rates how likely your current controls are to catch the failure before it escapes, and it is the one everybody reverses. On the FMEA scale, 1 means detection is almost certain (a strong control will catch it) and 10 means you would not catch it (no control exists, or the failure is undetectable). Higher is worse, same as the other two, but the direction feels backwards because a big detection number means weak detection. Score your controls as they exist today, not the ones you plan to add: if the only thing catching a defect is an operator's eye at the end of the line, that is a poor control and a high number, however skilled the operator.

A subtle trap: prevention controls and detection controls are different things. A poka-yoke that stops the defect from being made lowers occurrence; a gauge that finds the defect after it is made lowers detection. Scoring a prevention control as if it improved detection double-counts it and inflates the whole FMEA.

How do you anchor the 1-to-10 scales?

A scale only works if 1, 5, and 10 mean the same thing to everyone using it. The way to get there is written anchor descriptions for each rating, so a score is chosen by matching a situation to a description, not by picking a number that feels right. The table below shows the shape of anchored criteria; your own version should use language specific to your product and process.

How do you calibrate the team so ratings are consistent?

Consistency comes from the team, not from one expert filling in a spreadsheet. Scores set by a single person carry that person's blind spots; scores argued out by a cross-functional group converge on something defensible. Here is how to calibrate.

1. Agree the scales before you score anything. Adopt written anchor criteria for all three ratings and make sure operators, engineers, and quality read them the same way. Disagreements about the scale must be settled before, not during, the scoring.
2. Score as a team, out loud. Rate each line with the group present. When two people give a failure a 4 and an 8, the discussion that resolves the gap is where the real risk knowledge appears.
3. Anchor with data, not memory. Base occurrence on scrap, defect, and field data, and base detection on how the current control has actually performed. If the number and the data disagree, trust the data.
4. Separate prevention from detection. Confirm each control is scored in the right column: mistake-proofing lowers occurrence, inspection lowers detection. Never let one control improve both.
5. Calibrate on a known example. Have the team score a past failure whose real severity, frequency, and escape history you already know. If the scores match reality, the calibration holds; if not, fix the anchors.
6. Re-score against reality on a cycle. Occurrence and detection are claims about how the process behaves now. Revisit them whenever the process changes or the field teaches you something new, and adjust the numbers to match.

What are the most common scoring mistakes?

The first is central tendency: when scoring is rushed or done alone, everything drifts to the middle, every line lands near a 5, and nothing stands out for action. The cure is anchored scales and honest data. The second is inflating detection by counting controls you intend to add rather than the ones that exist today, which makes the FMEA describe a plant you do not yet have. The third is letting severity soften because a failure is rare, which is exactly the mistake the shift from RPN to Action Priority was designed to prevent. And the fourth, quietest failure is treating the ratings as permanent: they are time-stamped claims about a moving process, and a score nobody revisits slowly turns into fiction.

How do the three ratings feed the rest of the FMEA?

Once you have the three scores, they combine into a priority, either the classic risk priority number (severity times occurrence times detection) or the AIAG-VDA Action Priority table, and that priority tells you where to act first. The scores also point to how to act: a high severity means change the design, a high occurrence means mistake-proof the cause, a high detection means strengthen inspection and gauging. Because the ratings drive every one of these decisions, the same failure modes and the same scoring discipline flow straight into process FMEA on the line and design FMEA on the product; only the failure modes differ. And when a detection score depends on a measurement, that number is only trustworthy if the measurement is, which is what a gage R&R study confirms before you rely on it.

The scores are only as good as the data behind them, and that is where most FMEAs quietly rot. Occurrence and detection are supposed to reflect how the process actually performs, but when defect counts, escapes, and process results live on clipboards and month-end tallies, the team re-scores from memory and the numbers drift away from the truth. When that data is captured live at the point of work, tied to the line and the cause, the ratings can be re-scored against reality instead of recollection, and a rating that is trending worse shows up before it becomes a complaint. That is the loop Harmony gives a plant, working alongside your existing systems with no rip-and-replace, exactly the shift the processor in our CLS case study made from data found the next morning to data visible during the shift. This live feedback also strengthens statistical process control the other place occurrence data has to be true. See how the capture works on the features overview.