Meet the Monsters Behind Your FMEA Ratings: What Severity, Occurrence, and Detection Ask of Process Validation

In the spirit of Halloween, our latest video casts three classic monsters as the three ratings behind a failure mode and effects analysis (FMEA): the Zombie for severity, the Werewolf for occurrence, and the Vampire for detection. The video introduces what each rating measures. This post covers what each one asks of process validation, and why a process FMEA needs several decisions in place before anyone assigns a number. It accompanies our free FMEA Thought Guide for Process Validation, a three-part checklist a team can use during an FMEA session.

Why a thought guide rather than a template

Each organization defines its own rating criteria, sampling approach, and prioritization method. A calculation tool or a fixed template would imply a standardization that does not exist in practice, so the guide asks the questions and leaves the answers to the organization. For established companies, the prompts point back to existing procedures. For younger companies, the decisions a team records become the starting point for a procedure.

Before anyone rates anything

A process FMEA team should include the people who oversee, operate, maintain, inspect, and design the process and its outcomes. Operations and Engineering personnel understand how the process runs and how it fails, but Quality plays a central role in defining failure effects and their severity, particularly where those ratings carry over from product risk analyses. A session without Quality representation risks underrating effects that are clear from a compliance or patient perspective.

The guide itself is a reusable reference, not a form. Responses belong in two working documents: the FMEA worksheet, which holds the line-by-line analysis, and a ground rules log, which holds the session-level decisions and the reasoning behind them. Standard FMEA templates often lack columns the validation-specific prompts depend on, so we recommend adding four to the worksheet: the basis of each occurrence rating, the applicable sampling tier, the worst-case or noise factor designation, and a control qualification or validation requirement following the detection rating. Each of these comes up again below.

The session-level decisions (rating scales, severity carry-over, sampling tiers, acceptable occurrence bases, prioritization method, and action criteria) come before any rating begins. A team that adopts its thresholds mid-analysis is tempted to adjust them once it sees which lines would fall above them; decisions made in advance cannot be shaped by the ratings themselves. Once each scale is adopted, every participant should have a hard copy during the line-by-line analysis, so ratings are made against the agreed criteria rather than from memory or from experience with a different scale. Setting ground rules first does not lock a team into a rule that fails in practice: at close-out, a ground rule can still be revisited if it proved unworkable, provided the reason is documented in the log alongside the change.

Process characteristics, not product characteristics

A process FMEA asks about process characteristics rather than product characteristics. Earlier FMEAs in a product's life were likely performed on the product itself during design; the validation incarnation focuses on what the process creates or affects. A single process step often has several characteristics, and a single characteristic often has several failure modes. Each failure mode can in turn have several effects and several causes, and each can have multiple preventive and detection controls. A new line is warranted wherever a different failure or control would produce a different rating. Combining them on one line forces a single rating to represent conditions that carry different risk.

Failure mode or failure effect?

A common conflict surfaces early. Many organizations, particularly those whose FMEA practice grew out of product quality, treat the product defect as the failure mode. That framing serves product quality well, but it leaves validation with little to design a study around: it describes what went wrong without identifying which process condition to challenge.

For process validation, the failure mode is a process characteristic that fails to meet its requirement (seal temperature below its lower limit, for example), and the resulting product defect (an incomplete seal) is the effect. Framed this way, each failure mode points to something a validation study can act on: a parameter to challenge at worst case, a noise factor to capture, or a control to qualify.

The two framings are not competing interpretations of one FMEA. They describe linked analyses with different subjects. The product risk analysis rates product defects and their consequences; in the process FMEA, those product defects become the effects, and their severity ratings carry forward. Each analysis has its own failure mode, and the two connect through the effect. Recognizing that cascade resolves a disagreement practitioners with product quality and validation backgrounds frequently encounter when working on the same FMEA. Effects themselves can be considered at several levels (the next operation, the finished product, the patient or user, and the organization), which helps a team avoid underrating an effect that appears minor locally but has downstream consequences.

Severity: the Zombie

Severity is assessed as though the failure has already happened and reached its consequence, independent of how likely it is or whether anyone would catch it. The FMEA is built in a deliberate order (severity, then occurrence, then detection) so that one rating does not contaminate another.

At the process FMEA stage, the product is generally treated as fixed, and severity ratings typically carry over from the product risk analyses. Severity's role in process validation is to inform sampling and acceptance criteria: a more severe effect warrants more stringent criteria. The relationship is directional; the specific tiers are organization-defined. An organization might, for example, place severity 9 and 10 at its most stringent levels, 7 and 8 at intermediate levels, and 1 through 6 at its least stringent levels, though some would separate 9 from 10, since regulatory noncompliance and a health or safety hazard are meaningfully different effects.

How stringency is expressed depends on the type of data. For attribute data (pass/fail, conforming/nonconforming), it is typically expressed as confidence and reliability levels, which determine sample size and the number of failures allowed. For variables data, it is typically expressed as tolerance interval confidence and coverage, or as a minimum capability or performance index such as Cpk or Ppk. Many practitioners first encounter confidence and reliability through zero-failure attribute sampling and may not recognize the same concepts inside tolerance intervals, while organizations that set Cpk or Ppk minimums may never frame variables criteria in those terms at all.

Occurrence: the Werewolf

Occurrence rests on two inputs: the cause behind the failure mode and the preventive actions already in place. The example causes and preventive actions in our guide follow the six branches of a fishbone diagram, paired in order: personnel (operator error, training), equipment (equipment malfunction, preventive maintenance), method (unclear work instructions, controlled procedures), material (raw material variation, supplier controls), measurement (measurement error, calibration), and environment (environmental conditions, environmental monitoring).

The basis for an occurrence rating is not a single organizational decision. Historical data may support one cause, data from a similar process another, and subject matter expert judgment may be the only option where no data exists. The organizational decision is which sources are acceptable; recording the basis row by row makes each rating defensible. A low rating can also mean two different things: a cause that is genuinely rare, or a cause a control is suppressing. If it is the control, validation should confirm that the control works.

Occurrence is also where the FMEA begins to shape study design directly. If a cause has a controllable parameter (a setting, input, or condition the team can deliberately set during a study), it is a candidate worst-case condition, and the study can challenge the end of the operating range that represents the worst case. If it does not, the cause is a noise factor: it cannot be set, but it can be recorded, and the study's timing can sometimes be arranged to capture it (seasonal humidity, raw material lot changes, or shift changes, for example).

Detection: the Vampire

A control can act at three points: on the cause, preventing or flagging the condition that produces the failure; on the failure mode, identifying a nonconforming characteristic; or on the effect, catching a downstream consequence such as a functional failure at a later test before release. The earlier the point of detection, the more limited the impact. The detection scale also runs opposite to intuition: a low rating means detection is strong, and a high rating means the failure is likely to escape.

Where detection is weak, prevention is often more effective than improving detection, because it addresses the cause rather than the consequence. A detection rating is also only as credible as the control behind it. A control the team relies on for detection may itself need to be qualified or validated before that reliance is justified: test method validation for an in-process or release test, attribute agreement analysis for a manual visual inspection, or an alarm or interlock challenge during equipment qualification. A detection rating that relies on a method that has not actually been validated understates the risk. The control qualification column added to the worksheet, placed after the detection rating, records what each control needs to support its rating or cites the existing record where it is already qualified. Captured this way, detection ratings become a list of prerequisite validation work that feeds directly into validation planning.

What the RPN does, and what it does not

Multiplying severity, occurrence, and detection produces the Risk Priority Number (RPN). It is simple to calculate, but different combinations can produce the same RPN while representing very different risks. Organizations commonly set a maximum allowed RPN above which action is required. One practical way to set it is to choose the rating combination that represents the boundary of acceptable risk and multiply; a threshold of 125, for example, corresponds to a middle rating of 5 for each factor.

A fixed threshold shares the RPN's core limitation. A line with severity 10, occurrence 3, and detection 4 produces an RPN of 120, which falls below that threshold despite involving a health or safety hazard. In a process FMEA, that severity is addressed through sampling and acceptance criteria stringency rather than through action, since the process team cannot change the product's failure effects. Readers with product quality backgrounds may expect severity alone to trigger action, and in product-level risk management it often does: severity-by-occurrence matrices frequently drive investigation and action requirements with heavy weight on severity. ISO 14971 defines risk as the combination of the probability of occurrence of harm and the severity of that harm, so device risk analyses typically use a two-factor matrix with no separate detection rating, and ICH Q9 likewise treats detectability as optional. Process FMEAs retain detection because how reliably current controls catch a failure mode directly shapes in-process controls, inspection, and sampling decisions.

Acting, re-rating, and formalizing

After actions are complete, occurrence and detection are re-rated and priority is recalculated to confirm whether the action brought the line below the action criteria. Severity is not re-rated, since it reflects the product failure effect; process actions reduce occurrence or improve detection. Re-ratings are recorded only after an action is complete and its effectiveness is verified, so their presence on the worksheet serves as the record of effectiveness rather than a prediction. A spot check by someone outside the core session team adds an independent view.

The scales, thresholds, and methods a team settles on during the session are the raw material for a risk analysis procedure, and the ground rules log serves as its first draft. Before an FMEA is relied on for validation decisions, those decisions should be formalized in a controlled procedure and aligned with the quality system's risk requirements and with the product risk analyses from which severity ratings carry over.

The applicable references play different roles. ISO 14971 is product-oriented: it addresses device safety (hazards, hazardous situations, and harm) across the lifecycle, and production risks enter it as sources of device hazards rather than as process performance concerns. It does not prescribe FMEA; FMEA is one tool among several described in ISO/TR 24971. For a device process FMEA, ISO 14971 is the source of carried-over severity ratings, not the framework governing the process analysis. ISO 13485, which calls for a risk-based approach to quality management processes and addresses process validation, more directly supports risk-based process validation for devices, and it now underpins FDA's device quality system requirements under the QMSR. For drug and biologic products, ICH Q9(R1) applies quality risk management across the product lifecycle, including manufacturing processes, and lists FMEA among its tools.

Bring the guide to your next session

Our free FMEA Thought Guide for Process Validation walks a team through these decisions in three parts: setting the ground rules, analyzing each line, and acting and formalizing. Its scales and thresholds are illustrative; the decisions are yours to make and record.

Planning your next process FMEA?

Receive the FMEA Thought Guide for Process Validation: a three-part checklist that walks your team through setting the ground rules, analyzing each line, and acting and formalizing, with illustrative rating scales and the validation-specific worksheet columns described above.

If your organization needs help understanding or applying an FMEA in a validation context, Brayearst Validation Consulting is available.

© 2026 Brayearst LLC. All rights reserved.