Master modern complexity by treating safety and security as a control problem rather than a component failure.
Modern systems are no longer just collections of parts. They are complex, software-intensive, and deeply interconnected socio-technical systems. Traditional safety and security methods often struggle to keep pace with this interactive complexity.
STAMP (System-Theoretic Accident Model and Processes) introduces an effective way of thinking about system weaknesses and vulnerabilities. Instead of looking for “failed” components, individual “threats”, or “human error”, STAMP views safety and security as a control problem. By enforcing constraints on system behavior through a functional control structure, vulnerabilities can be identified that traditional methods miss.
| Traditional cause | STAMP view |
|---|---|
|
“Operator error” “Operator violates established procedure” |
Inadequate Mental Model. If the operator incorrectly believes the system is in State B rather than State A, they may execute a procedure that is functionally correct for the perceived state but catastrophic for the actual state. Because the system design does not provide a clear way to confirm the true state, it can cause human error. |
| “Software design error” | Inadequate Control Algorithm. Software functionality A lacks the necessary safety constraint B to prevent hazards. Hazard X will be caused if the software correctly executes functionality A during context C. |
| “The conditions exceeded design limits” | Inadequate Feedback. No clear feedback exists to indicate exactly when design boundaries are being approached or crossed. As a result, decisions to operate may involve an incorrect assumption that the design limits are not exceeded. |
| “Simultaneous failure of redundant hardware is unlikely” | Ineffective Redundancy. The redundant components may not fail simultaneously. One component fails and a backup takes over as designed. However, feedback about the failure is not enabled, is not communicated, or the component is not repaired within X time as assumed. There is missing operational feedback to recognize when actual time to repair exceeds the value assumed by engineers. The system continues operating normally until the redundant component eventually fails. |
| Automation failed | Decision-making flaw. "Software Action_A is unsafe when B. However, software can default to Action_A when C, causing a hazardous condition." |
If the operator incorrectly believes the system is in State B rather than State A, they may execute a procedure that is functionally correct for the perceived state but catastrophic for the actual state. Because the system design does not provide a clear way to confirm the true state, it will cause human error.
Design the system to provide direct, independent feedback of the true state, and update procedures to include appropriate means to confirm the state.
In the Three Mile Island accident, operators followed procedures based on a mental model that a valve was closed, when it was actually stuck open. The valve position indicator was was designed to indicate what the valve was commanded to do rather than measuring the actual position of the valve.
Assign an assurance/integrity level to minimize the chance of an unknown error. Use rigorous software development practices, like increasing test coverage to catch more bugs. If a bug is found, fix it.
Software functionality A lacks the necessary safety constraint B to prevent hazards. Hazard X will be caused if the software correctly executes functionality A during context C.
Define a software safety constraint to ensure __ is always provided by the software whenever ___ occurs. Remove functions A and B that contradict this constraint, and instead implement functions D and E to ensure the software cannot enter hazardous states regardless of user input.
The Therac-25 radiation accidents occurred because the software logic allowed a high energy beam to activate without a protective spreader in place, never enforcing a critical safety constraint during rapid operator input.
Warn operators not to exceed limits and improve training on technical specifications.
No clear feedback exists to indicate exactly when design boundaries are being approached or crossed. As a result, decisions to operate may involve an incorrect assumption that the design limits are not exceeded.
Establish continuous “Safe Envelope” visualizations that show margins of safety in real time, and automate boundary enforcement (e.g., hard-coded lockouts) when sensors detect environmental parameters exceeding safety thresholds.
The Space Shuttle Challenger disaster involved operating outside the “safe envelope” for temperature. The decision was enabled by a weak control structure to address growing concerns and a management belief that there was no clear indication that design limits were exceeded.
Use quantitative reliability modeling (e.g., Fault Tree Analysis) to determine the probability of concurrent failures. Implement sufficient redundancy/diversity/independe ce to ensure the residual risk is acceptable.
The redundant components may not fail together. One component fails, but the failure has minimal impact because a backup system immediately takes over. Feedback about the failure is not enabled, does not exist, or it exists but the component is not repaired within X time as assumed. There is poor or nonexistent feedback to management to recognize when actual time to repair exceeds the value assumed by engineers. The system continues operating normally until the redundant component eventually fails.
Design the control structure to ensure explicit alerts to maintenance. Design leadership feedback to evaluate when the assumed time to repair is exceeded in operation. Define required responses at each level, including operators, maintenance, and leadership, when the redundant path is not repaired within a validated time limit. For example, certain operations may be halted or additional limits imposed until a full repair is completed.
The Deepwater Horizon Oil Spill involved two redundant control systems on the ocean floor: the Blue Pod and the Yellow Pod. Only one was needed to function, and the system was designed so that if one failed, the other could take over. However, there was no “hard” control that halted drilling if one pod went offline. Months before the explosion, the Blue Pod failed due to a dead battery. The Yellow Pod took over seamlessly. The rig continued to operate “normally”.
While there was some technical feedback that the Blue Pod was struggling, it wasn’t treated as a “stop-work” event. Management and leadership did not have a feedback loop to recognize that the Mean Time to Repair (MTTR) had been exceeded by weeks. On the day of the disaster, the Yellow Pod (the only one left) failed due to a dead battery. Even though the two pods did not fail simultaneously, the lack of timely repair of the blue pod made an accident inevitable.
A Proactive Hazard Analysis for Safety. STPA is used during the concept and design phases to “build safety in” rather than “inspecting it in” at the end. It identifies hazardous scenarios caused by complex interactions, software logic, and human-machine interfaces—even when no components have failed.
A System-Theoretic Approach to Cybersecurity. STPA-Sec moves beyond “perimeter defense” to focus on functional vulnerabilities. It analyzes how an attacker can manipulate control loops and feedback to cause a loss, even without a technical “breach”.
For Advanced Accident and Incident Investigation. CAST is a structured methodology for learning from past losses or near-misses. It shifts the focus from “who to blame” to “why it made sense” for people to act the way they did, uncovering the systemic factors that allowed the event to occur.
Regardless of the industry—Aviation, Automotive, Medical, Space, or Defense—the evidence for STAMP-based approaches is clear:
| Feature | Traditional Methods (FMEA, FTA, RCA) | STAMP-Based Methods (STPA, STPA-Sec, CAST) |
|---|---|---|
| Causality Model |
Chain of Events / Failure Propagation Failure_A -> Failure_B -> Failure_C |
STAMP: Considers failures, unsafe interactions without a failure, non-linear causality, and emergent behavior Action_A -> Belief_B -> Action_C |
| Focus | "What failed?" | "What context made the action unsafe?" “Why would an unsafe decision appear reasonable at the time?” |
| Software | Hard to model software and human decision-making | Directly identifies software and human decision-making flaws |
| Human Error | Viewed as a "Root Cause" | Viewed as a symptom of systemic flaws in the design or organization |
| Cost | High: Frequent "patching" of symptoms; high risk of recurring losses or late-stage retrofits | Low: Lifecycle costs reduced by identifying flaws early, minimizing expensive rework, and preventing losses |
Stay informed about the latest from STAMP Institute.
Tell us what you’re interested in, and we’ll recommend a path forward.
By continuing, you agree to our Terms of Service and Privacy Policy.
Gain skills and confidence with expert guidance as you implement modern approaches in your organization.
Gain a strategic overview of the STAMP framework designed specifically for your executive team. Our briefings focus on high-level alignment, risk mitigation, and scaling impact across your organization.
The information provided will be used exclusively to prepare your tailored briefing. By submitting, you agree to our Terms of Service and Privacy Policy. This service is reserved for organizational leadership and project stakeholders.
We’ve received your industry details. Our team regularly updates our active industry list to reflect new sectors and innovative applications of the STAMP framework. We’ll reach out if we’d like to feature your work as a specific case study!
The STAMP Institute Team
We are constantly inspired by the diverse ways our community applies STAMP. Tell us about your industry and how you’re using these methods so we can better represent the full reach of our network.
The information collected here is for mapping purposes only. By submitting this form, you grant STAMP Institute permission to display your organization’s industry on our public website. Contact and use case details will not be shared without your consent.
Thank you for reaching out! A member of the STAMP Institute team will review your request to hand-select the case studies most relevant to your goals.
Our research spans diverse sectors, but we know your challenges are unique. Tell us a bit about your focus, and we’ll curate a selection of case studies and impact reports relevant to your specific field.
By submitting this form, you agree to our Privacy Policy. STAMP Institute will only use your information to provide the requested content and update you on relevant industry insights. You may unsubscribe at any time. We do not sell your personal data.
Thank you for contacting us. A STAMP Institute representative will follow up shortly to schedule a discovery call.
Learn modern approaches to safety, security, and reliability with customized, expert-led training from STAMP Institute. Gain skills and confidence with expert guidance as you implement modern approaches in your organization.
Thank you for contacting us. A STAMP Institute representative will follow up shortly to schedule a discovery call.
You’re on the list! Thank you for joining the STAMP Institute community. You’ll now be the first to receive updates on modern approaches to safety and security.
New Training Announcements: Stay ahead with the latest curriculum updates.
Research & Presentations: Exclusive insights and expert methodologies.
Upcoming Courses: Priority registration for specialized training sessions.