STPA
System-Theoretic Process Analysis
Forward-looking hazard analysis to identify and prevent potential losses before they occur.
About STAMP
A system-theoretic approach to safety, security, and reliability.
Already know the basics?STPA in DepthCAST in Depth
Page Overview
Foundation
- 1What is STAMP?
Why losses happen in complex systems, including the harmful interactions between parts that each work as designed.
- 2The Control Loop Model
How feedback and other information shape a controller’s decisions, and how an unsafe action can look reasonable given the information available and the local context.
- 3The Hierarchical Control Structure
How control loops stack up, from the equipment to operators, managers and regulators.
Methods
- 4What is STPA?
Finding where the control structure of a system or organization could allow a loss, so it can be fixed early.
- 5What is STPA-Sec?
Using STPA for security, alongside safety.
- 6What is CAST?
Analyzing a loss after it occurs, to find system changes that work better, and often cost less, than retraining or blaming people.
Part 1 · Foundation
What is STAMP?
Behind many accidents, outages, and security incidents are decisions that made sense at the time. A pilot, an operator, an automated system, or an AI acted on a belief about the system that turned out to be wrong. Often every component worked as designed. The decision-maker was fooled by feedback that was missing, late, or misleading, or by a misunderstanding between people and automation about who was doing what.
STAMP (System-Theoretic Accident Model and Processes) is a model of how accidents and other losses happen, based on systems theory rather than reliability theory. Professor Nancy Leveson of MIT created STAMP and introduced it in a 2004 paper. STAMP views losses in terms of controls and decisions. It treats every decision-maker as a controller that decides what to do based on its beliefs about the system, and updates those beliefs from the feedback it receives. That one idea lets you analyze decisions made by humans, automation, and AI in the same terms, and especially the interactions between them. The model is easy to sketch and intuitive to reason about, and the methods built on it tend to uncover hidden vulnerabilities in real systems.
What STAMP-Based Methods Help You Do
- Find flaws in a design or organization before they lead to a loss (STPA)
- Find security vulnerabilities before they lead to an incident (STPA-Sec)
- Understand a complex loss after it happens, including the systemic factors that contributed (CAST)
Safety is a feedback control problem.
The central insight of STAMP: losses happen when safety constraints on the system’s behavior aren’t adequately enforced through its controls and feedback.
Accident Models
Safety in engineering and operations is about preventing losses, such as loss of life, harm to patients, loss of a mission, lost production, a service outage, or a data breach. To prevent losses, assumptions are made about what causes losses and how those causes combine and affect each other. An accident model describes the kinds of assumptions that are often made and enables them to be recognized and challenged. Despite the name, it applies to any kind of loss. All methods for finding and preventing losses and their causes are based on an accident model of some kind, although the model and its assumptions are often not documented. When teams understand the model behind a method, they can see which kinds of causes it will find and which it will miss. STAMP is a new type of accident model. It gives a different view of how losses happen, which helps teams quickly uncover causes and vulnerabilities that often get missed.
Popular methods include FMEA, Fault Tree Analysis, HAZOP, and Functional Hazard Assessment (FHA). These methods follow the chain-of-events model, where one event leads to the next. Most of these methods focus on failures (deviations from required or intended behavior). The failures can be in components or in functions, such as a loss of function, partial loss of function, or malfunction. Focusing on failures can help prevent them, or reduce their effects when they happen, but losses can still occur in other ways. Safety also depends on whether the intended functions are safe as defined, and whether the operating context matches the assumptions made during design.
Hard to Capture with Failure-Based Methods
- Behavior that works exactly as designed, but is unsafe in the full context
- Needed functions that were never designed in
- How software and automation decide what to do, based on what they believe is happening
- How people decide what to do, and why an action made sense to them at the time
- Functions that combine into a new behavior, at the level above, that nobody designed or intended
- Feedback loops, where an effect comes back around and changes its own cause
Chain-of-Events Model
- 1Brake hose cracks
- 2Brake fluid leaks
- 3Brake pressure drops
- 4Car can’t stop in time
- 5Collision
- 6People injured, cars damaged
Software, automation, and now AI make these gaps matter more. In many recent accidents no component failed: the parts worked as designed and combined in ways nobody planned. Problems like these tend to stay hidden until something goes wrong. STAMP, and the methods built on it, were developed to uncover these problems before a loss occurs.
History of System Safety Engineering
-
1920s–1940s
Mechanical Systems
Assumed cause: human error
-
1940s–1970s
Electromechanical Systems
Assumed cause: component failures and human errors
-
1980s–today
Software and Computer Control
-
2020s–today
AI-Enabled Systems and Operations
Main challengesWorkers injured by machines in factories, mines, and railroadsHeinrich (1931) attributed 88% of industrial accidents to unsafe acts by workers.
Main challengesComponent failures in missiles, aircraft, and chemical and nuclear plants
Main challengesFast-growing complexity, new technologies, and changing human roles
Main challengesAI that makes or supports decisions, behavior learned from data, and people supervising it
Created for these challengesMachine guardsTrainingInspections
Created for these challengesFMEAFTAETAHAZOP
Created for these challengesSTPACAST
Every Model Leaves Something Out
“Essentially, all models are wrong, but some are useful.” — George Box
A model is like a lens: it brings some parts of the system into focus and leaves others blurred. Teams use different methods to analyze each model. A problem that one model hides may show up in another. STAMP-based methods analyze the control structure.
Piping and Instrumentation Diagram
Shows physical flows. Leaves out how digital controls behave and how people interact with the system.
Reliability Block Diagram
Shows redundancy. Used in Fault Tree Analysis and reliability assessment.
Functional Decomposition
Shows individual functions. Used in Functional Hazard Assessment.
Task Analysis
Shows the steps people take to do a job. Used in human factors and training.
Markov Model
Shows the states a system can be in, such as working, degraded, or failed, and the rates of moving between them. Used in reliability analysis.
Control Structure
Shows who controls what, the decisions each controller makes, and the feedback those decisions rely on. Used in STAMP, STPA, and CAST.
Like every model, a control structure focuses on some things and leaves other aspects out. A control structure shows what drives decisions and the feedback loops around them, and leaves out physical layout and form. Teams who analyze a control structure can find problems that are hard to see in a piping diagram or a reliability block diagram.
STPA is most useful for systems with software, people, or both, where interactions can be complex and an unsafe decision can make sense to the person or software making it, based on what they believe at the time.
Where STPA Helps Most
- AI, which is one part of a control loop and, like software or a person, can take an unsafe action that seems reasonable given the information it has
- New and emerging technology, such as self-driving cars, autonomous aircraft, and reusable spacecraft. Losses with new technology tend to come from familiar flaws in control loops, even when a failure is new or nothing fails.
- Organizations, whose flaws often contribute to major losses. System safety teams seldom analyze organizations, because failure-based methods don’t extend easily to them.
- Problems between disciplines that only show up when a team looks at automation and human factors together. In practice, separate teams working on each discipline often miss these problems.
- Maintenance, a human control loop that failure-based methods often leave out
Part 2 · Foundation
The Control Loop Model
At the heart of STAMP is the concept of a control loop, which explains how decisions can be informed and how patterns emerge from the continuous interactions in a system. Within a control loop, a controller oversees a controlled process. The controller can be a human, an automated system, or an AI. The controlled process could be another controller, physical machinery, or a virtual process or data. Controllers make decisions based on their process model, which is their internal understanding of how the system is currently behaving. For this loop to function, the controller may rely on timely feedback to provide updated information about the process and its true state. Controllers often rely on feedback to update their process model. If the feedback is missing, delayed, or misinterpreted, the controller may issue an unsafe command that “makes sense” given their flawed information, leading to a loss.
Choose an example to fill in the loop:
STAMP Terminology
Click a term to learn more.
Controller
An entity that makes decisions and provides control actions to controlled processes to achieve goals. Controllers include people, teams, organizations, software, AI, and hardware devices.
Control Actions
An action that may be provided by a controller to control or supervise a lower-level process.
Decision-Making (aka Control Algorithm)
Describes which control actions may be suitable based on the current process model or other factors.
Process Model
Represents a controller’s “beliefs” about the outside world that impact decision-making and may lead to Unsafe Control Actions. All controllers have a process model, including human, automated, and other controllers.
Feedback
Information provided to a controller about a lower-level process that they directly or indirectly control.
Controlled Process
Any process that is controlled, such as a physical process, data, or another controller.
Unsafe Control Action
A control action that leads to a hazard in a particular context. It can be unsafe to not provide a needed action, to provide one when it isn’t safe, to provide it too early, too late or out of order, or to apply it too long or stop it too soon.
For example, a controller in a car may be a human driver or an Automated Driving System (ADS). In either case, the controller may decide to issue a braking control action to prevent a collision with a pedestrian. This decision is only possible if the controller has an updated process model that recognizes a pedestrian is in the vehicle’s path. If the process model does not accurately reflect the true state of the environment, the controller will not be able to make safe decisions and provide safe control actions. The controller relies on feedback, such as visual observation or sensor data, to continuously update its process model. If any part of this control loop is out of sync or dysfunctional, the system can drift into a hazardous state.
A breakdown can occur if the pedestrian is outside the visible range, for example if they are a small child and the windshield or sensor is too high to notice the pedestrian. The feedback available may not be enough for the controller to form a correct process model that a pedestrian is in the vehicle’s path. As a result, the controller may provide an unsafe control action: maintaining the current speed (no braking) when a pedestrian is in the vehicle’s path. The resulting collision isn’t a mechanical failure of the brakes, but a poor system design and an unsafe decision that made sense given the controller’s flawed process model (belief) at the time.
The terminology so far, like unsafe control actions and missing feedback, is broadly applicable whether they are caused by a failure or not. A sensor failure can result in poor or missing feedback, leading to an unsafe control action. A power failure can also cause unsafe control actions. More importantly, non-failure causes can have the same effect. For example, a missing software requirement can result in an unsafe control action. An intended feature operating as designed can inadvertently increase feedback delays in certain cases, resulting in poor or missing feedback.
In STAMP, a failure is not the unit of analysis.
Instead, STAMP shifts the focus toward identifying inadequate feedback, mismatched process models, and unsafe control actions, regardless of whether they originate from a component failure. In fact, many accidents in complex systems have been caused not by isolated failures but by components that interacted in unsafe ways according to requirements and procedures that were flawed.
Part 3 · Foundation
The Hierarchical Control Structure
Builds on: Part 2, The Control Loop Model
STAMP models the multiple layers of control in a system, from physical processes and frontline operators near the bottom to executive management and government regulators at the top. Each level in the hierarchy imposes safety constraints on the level below through specific control actions. The lower levels, in turn, may provide feedback to inform future decisions at higher levels. Safety is not a property of a single part, but an emergent property that is maintained only when these interactions are properly designed and align with overall goals of the system. When an accident or loss occurs, it is rarely due to a single “failed” component or link. Instead, it is often because the control structure lacked the necessary means to enforce safety constraints under changing conditions. For example, an organization may have a formal safety policy at the management level, but without an effective feedback channel from the field, decision-makers may remain unaware that production pressures are systematically forcing operators to bypass those very protections.
Control Structure Model
Example: Aviation
Methods
STAMP-Based Methods
Step-by-step methods built on STAMP help at every stage of a system’s lifecycle, from early design through operation and accident investigation. STPA and CAST are the most widely used.
Reactive(understand past events)
MethodCASTAccident Analysis
MethodSTPAHazard Analysis
Proactive(anticipate future events)
TheorySTAMPAccidents are caused by inadequate control, not just failures
STPA-Sec
Security Extension
Applying STPA principles to security and cybersecurity analysis of critical systems.
CAST
Causal Analysis based on Systems Theory
Analysis of past accidents and incidents to uncover the systemic and other factors that contributed.
Part 4 · Hazard Analysis
What is STPA?
Builds on: Part 2, The Control Loop Model and Part 3, The Hierarchical Control Structure
STPA (System-Theoretic Process Analysis) is a forward-looking technique to anticipate future loss scenarios and ensure they are prevented. The goal is to identify vulnerabilities in a design or organization and use this information to develop effective solutions as early as possible before a loss occurs.
How STPA Works
- 1
Unacceptable Losses
Identifies the overall losses (outcomes) that would be unacceptable to stakeholders, such as loss of life or loss of revenue.
- 2
Control Structure
Models the control hierarchy and feedback loops in a system, including both human and technical interactions.
- 3
Unsafe Control Actions
Identifies potential unsafe decisions and control actions that could contribute to the losses.
- 4
Causal Scenarios and Solutions
Builds scenarios to explain why each component, whether human or technical, might have believed a decision was reasonable at the time, given the information available and other contextual factors. The scenarios lead to solutions, such as new design features, changes in functionality, more robust or simpler solutions, test cases, and other solutions.
STPA is widely used in aviation, automotive, autonomous vehicles, medical devices, nuclear power, and many other high-risk industries.
Part 5 · Cybersecurity
What is STPA-Sec?
STPA-Sec refers to the use of STPA to include security and cybersecurity considerations. The overall steps are the same, but with additional considerations included.
While traditional security focuses on threats, perimeters, and firewalls, STPA-Sec focuses on the functional capabilities of the system. It helps engineers design systems that can maintain their critical functions even when under attack or when facing intentional disruptions. This focus is well-aligned with STPA’s ability to help safety engineers design robust systems that maintain critical functions even in the face of unsafe component interactions or failures that were caused unintentionally.
Although STPA originated in safety-critical applications, modern uses of STPA can include safety, security, performance, and other considerations in the same overall process.
“Security, safety, and performance can be addressed together.”
STPA-Sec enables integrated analysis of security and safety concerns within the same framework, avoiding conflicts between security measures and safety requirements.
Part 6 · Incident Analysis
What is CAST?
Builds on: Part 2, The Control Loop Model and Part 3, The Hierarchical Control Structure
CAST (Causal Analysis based on Systems Theory) is the technique used for systematically analyzing past accidents and other losses. CAST is designed to uncover deeper systemic factors and deficiencies that are often overlooked in a root cause analysis or post-mortem.
CAST is used to move beyond human error or individual component failures as potential root causes. Instead, it examines the entire socio-technical system, including flaws in complex technology, operation, management structures, and regulation. To uncover the most effective opportunities to improve, it’s not enough to identify who or what contributed. The goal of CAST is not to assign blame, but to identify why each decision may have appeared reasonable at the time and to determine the most effective systemic changes to prevent recurrence.
What a CAST Analysis Does
- Generates more effective recommendations that target deeper causes
- Identifies systemic causes, not just proximate causes
- Examines the entire socio-technical system
- Focuses on why safety constraints were not enforced
CAST Analysis
Go beyond superficial causes to uncover low-cost, high-impact systemic changes.
Traditional“Operator Error”
CAST“System Design Flaw”
“Beyond Human Error”
CAST recognizes that humans make decisions based on available information and system feedback. The focus shifts to why the decision appeared reasonable at the time.