Failure Mode and Effects Analysis

Anticipate credible failures before they reach users, then assign controls and actions to the risks that matter most.

In one minute

Failure Mode and Effects Analysis (FMEA) is a structured team method for asking six linked questions:

1. What must this step or component do?
2. How could it fail?
3. What would the effect be?
4. What could cause the failure?
5. Which controls prevent the cause or detect the failure?
6. What action will reduce the risk?

The value lies in the reasoning chain and owned actions, not in producing a risk number. Severity, occurrence and detection ratings help comparison, but no arithmetic score should overrule a severe safety, legal or trust consequence.

Best for: new or changed workflows, control design, AI deployment, regulated operations and recurring quality risk.
Avoid when: an incident is unfolding and needs containment, or the team has not defined the process or intended function.

The problem it addresses

Teams often review a design by asking whether the happy path works. Failure appears later through rare inputs, missing data, confusing hand-offs, silent system errors or controls that exist only on paper.

FMEA makes those possibilities discussable before launch. It connects each risk to a function, effect, cause, existing control and accountable action. This prevents vague risk registers filled with labels such as “AI error” that cannot guide design.

When to use it

Use FMEA when:

• a process, product or control is being designed or materially changed;
• AI or automation can influence customers, money, rights or safety;
• exceptions and hand-offs are numerous or poorly understood;
• a repeated failure suggests broader exposure than one incident;
• preventive and detective controls need explicit ownership;
• a supplier, model or data source introduces a new dependency.

Keep the boundary narrow enough that the team can describe real functions and controls. A workflow-level FMEA is usually more actionable than one covering an entire company.

When not to use it

Do not use FMEA:

• instead of containing an active safety or customer-impacting incident;
• as a solo scoring exercise by someone distant from the work;
• to turn every imaginable event into an equal priority;
• when functions and process boundaries remain undefined;
• to claim that a low score proves an AI system is safe;
• as a static compliance artefact with no action review.

Use Root Cause Analysis to explain a failure that has already occurred. Use Mistake Proofing to design a specific prevention or detection mechanism.

Inputs required

• a scoped process, product or service boundary;
• intended functions and required outcomes;
• actual process steps, interfaces and operating conditions;
• incident, defect, exception and near-miss evidence;
• affected customers, workers, systems and obligations;
• existing prevention and detection controls;
• agreed rating definitions with examples;
• owners able to change the design or operating control.

Step-by-step process

1. Define the scope and function

Describe the item, process or step being analysed, its boundary and what it must accomplish. Include quality, privacy, security, accessibility and safety requirements when relevant.

2. Describe credible failure modes

Write how the function could fail, not a vague topic. Examples: “refund is issued to the wrong account,” “model cites a non-existent policy” or “low-confidence extraction proceeds without review.”

3. Record effects and severity

Describe what the customer, operator, organisation or wider system experiences. Rate severity using an agreed scale. A severe effect should remain visible even when estimated occurrence is low.

4. Identify causes and occurrence evidence

List plausible mechanisms that could produce each failure mode. Distinguish a cause from the failure itself. Use observed data where available and mark estimates explicitly.

5. Evaluate current controls

Separate:

• prevention controls, which reduce the chance that a cause occurs;
• detection controls, which reveal the cause or failure before the effect reaches the user.

Rate detection based on the control’s demonstrated capability, not its presence in a procedure.

6. Prioritise with judgement

Use severity, occurrence and detection to compare risks. If the organisation uses a Risk Priority Number, calculate it consistently, but also review high-severity items and weak controls separately. Different rating combinations can produce the same number while requiring different decisions.

7. Define risk-reduction actions

Prefer actions in this order:

1. remove or redesign the failure opportunity;
2. prevent the cause;
3. detect the problem early and reliably;
4. contain the effect and recover safely;
5. add warnings or training only when stronger controls are not practical.

Assign an owner, due date and success evidence.

8. Reassess residual risk

After the action is implemented and verified, update the ratings and record the evidence. Do not reduce a score merely because an action was planned.

9. Keep the analysis alive

Review the FMEA after incidents, model changes, process changes, new data sources or material shifts in use. Feed observed failure information back into controls and tests.

AI automation lens

AI-enabled workflows introduce familiar operational risks in new forms: ambiguous inputs, incorrect generation, prompt injection, data leakage, automation bias, drift and uncontrolled downstream action.

Analyse the complete socio-technical workflow rather than the model alone. Include:

• the task and decision the model supports;
• data provenance and permissions;
• confidence or abstention behaviour;
• human review conditions and reviewer workload;
• tools and records the model may read or change;
• monitoring, incident response and rollback;
• effects on people who cannot easily contest an outcome.

“Human in the loop” is not automatically a strong control. Specify what the reviewer sees, the time available, the authority to reject and evidence that review catches the targeted failure.

Visual model

Text alternative: an intended function can fail because of process, data or model causes and produce an effect. Prevention and detection controls reduce the risk; human review, controlled action and verification close the loop.

Text alternative: a structured chain connects function, failure mode, effect, cause, current prevention and detection controls, and risk-reduction action. A side panel shows severity, occurrence and detection as separate decision signals. AI-specific boundaries surround data, model output, human review and downstream action.

Interactive example

Scenario

A retailer plans an assistant that drafts refund decisions. It reads an order, policy and customer message, then prepares an amount and destination account for agent approval.

Observed evidence:

• 3% of orders contain a changed payment method;
• policy versions are updated monthly;
• agents review 65 cases per hour during peak periods;
• the interface highlights the amount but not the destination account;
• model answers are fluent even when a policy passage is missing.

Your move

Write one failure chain and propose a stronger control than “the agent checks it.”

Worked answer

Function: prepare a correct, policy-compliant refund for approval.
Failure mode: the refund is routed to an obsolete payment account.
Effect: financial loss, customer delay and possible fraud exposure.
Cause: the model selects historical payment data without a deterministic eligibility check.
Current control: a busy agent reviews a fluent summary that does not highlight the destination.
Action: determine eligible destination accounts with a transaction-system rule, display the account and evidence separately, block unsupported destinations and route mismatches to a specialist queue.

Success evidence includes blocked mismatch tests, reviewer detection rate, false-block rate, refund incidents and exception age.

Facilitation notes

• Bring operators, technical owners, control owners and affected-user perspectives together.
• Write functions before failures and failures before causes.
• Use one agreed rating table and calibrate with examples.
• Separate evidence from expert estimate.
• Challenge controls that depend on perfect attention.
• Give high-severity effects explicit review even when their combined score is modest.
• End only when actions, owners and verification evidence are recorded.

Expected output

A sound application produces:

• a defined scope and function list;
• specific failure modes and effects;
• causes supported by evidence or labelled assumptions;
• severity, occurrence and detection judgements;
• documented prevention and detection controls;
• prioritised actions with owners and dates;
• residual-risk evidence and a review trigger.

Common mistakes

1. Starting with scores. Numbers hide weak failure reasoning.
2. Confusing causes and effects. Actions then target the wrong part of the chain.
3. Treating documentation as control. A written instruction may not prevent or detect anything.
4. Multiplying ratings mechanically. Equal totals can conceal radically different severity.
5. Calling human review a control without testing it. Reviewers may lack time, evidence or authority.
6. Lowering ratings for planned actions. Residual risk changes only after verified implementation.
7. Freezing the FMEA at launch. New incidents and model changes invalidate assumptions.

Quality checklist

• Scope, functions and affected parties are explicit.
• Failure modes describe how a function can fail.
• Effects and causes are distinct.
• High-severity consequences receive explicit review.
• Prevention and detection controls are separated.
• Ratings use agreed definitions and evidence.
• Actions change design or control strength and have owners.
• Residual risk is updated only after verification.
• AI boundaries, exceptions and human accountability are visible.

Template

Knowledge check

A team lowers an FMEA score immediately after assigning an action to an owner. What is wrong?

A. Actions should never affect risk.
B. Residual risk should change only after the action is implemented and its control effect is verified.
C. Only severity can be rated.
D. Owners should not be named in an FMEA.

Answer: B. A planned action does not yet prevent or detect a failure.

Related tools

• Preceded by: Value Stream Mapping, process definition or system design
• Often combined with: Root Cause Analysis, Pareto Analysis
• Control design with: Mistake Proofing
• Test changes through: PDCA/PDSA Cycle
• Not to be confused with: an incident report, generic risk register or proof of safety

References

1. AIAG and VDA. FMEA Handbook, first edition. Automotive Industry Action Group, 2019, with an updated publication listing in 2022. Official manuals page (opens in a new tab).
2. SAE International. J1739: Potential Failure Mode and Effects Analysis (FMEA), revised 2021. Official standard page (opens in a new tab).
3. SAE International. ARP5580: Recommended Failure Modes and Effects Analysis Practices for Non-Automobile Applications. Official standard page (opens in a new tab).
4. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. Official publication (opens in a new tab).
5. National Institute of Standards and Technology. Generative Artificial Intelligence Profile. NIST AI 600-1, 2024. Official publication (opens in a new tab).

Sources reviewed 3 August 2026.