Quick answer: Safety, security and privacy failures are all control problems, not isolated incidents. How System-Theoretic Process Analysis turns loss scenarios into leading risk indicators that feed directly into system design, rather than after-the-fact reporting.
Originally published on LinkedIn: 9 May 2026.
Traditional risk management often fails to capture the dynamic functional relationships and feedback loops that now drive modern safety, security, and privacy threats. Organisations face critical risks from unsafe control actions and loss scenarios triggered by systemic issues such as incorrect feedback, design errors, or component failures. The absence of a past incident does not guarantee the absence of future loss in increasingly interconnected environments. Professionals must adopt a structured System-Theoretic Process Analysis (STPA) approach to identify functional gaps and develop leading indicators of risk that proactively inform architectural design and strategic resilience.
The complexity trap
Modern industrial and digital ecosystems, from autonomous transport networks to global financial infrastructures, have surpassed the threshold of manageable complexity. Traditional checklist-based risk management, predicated on the linear failure of individual components, is no longer merely insufficient; it is a liability. Organisations are witnessing catastrophic failures occur despite every individual part functioning exactly as specified. STPA is a proactive design science rather than a reactive audit of broken parts. It starts with defining the purpose of the analysis: setting the system boundary and identifying potential losses and hazards before anything else. That sequencing moves the exercise from vague safety goals to a rigorous engineering framework built to answer why systems fail when the components are, individually, fine.
It is not the parts, it is the interactions
The fundamental flaw in traditional risk assessment is the reductionist fallacy: the belief that a system is merely the sum of its parts. STPA's second step models the control structure, capturing functional relationships and interactions as a hierarchical set of feedback control loops, starting at a high level of abstraction and refined iteratively. Most risk managers are conditioned to find the broken component. In complex systems, the danger resides in the broken relationship. Failure often traces to a breakdown in communication or a mismatch between a controller's mental model and the system's actual state. Focusing on the control loop reveals where feedback is missing or commands are misinterpreted, capturing risks that component-based checklists inherently miss.
Safety, security and privacy are the same problem
One of STPA's most useful properties is its universality: in a system-theoretic world, there is no functional difference between a safety mishap, a security breach, or a privacy violation. All three are control problems. A hacker gaining unauthorised access is simply an external agent triggering an unsafe control action, just as a sensor failure might. Organisations typically manage safety, security and privacy in isolated silos, each with its own metrics and language. STPA provides a unified framework that lets the C-suite view resilience through a single lens, exposing cross-departmental vulnerabilities that were previously invisible. These steps do not change regardless of whether STPA is applied to safety, security, privacy, or other properties.
Using unsafe actions to design requirements
The third step identifies unsafe control actions: specific behaviours that, in a given context, lead to a loss. Rather than logging these as errors after the fact, STPA converts them directly into functional requirements and constraints. This is the shift from reactive patching to proactive design. Instead of building a system and bolting on security or safety features afterwards, STPA uses the analysis of potential failures to dictate the system's requirements from inception, baking resilience into the architecture and reducing the long-term cost of remediation and technical debt.
Finding the why before the failure manifests
The final phase, identifying loss scenarios, uncovers the causal factors behind potential disasters: how incorrect feedback, inadequate requirements, design errors, component failures and other factors can lead to unsafe control actions, and how safe control actions might be specified but not properly followed or executed. Most organisations rely on lagging indicators, waiting for an accident to happen. STPA identifies the why before the event. These scenarios also evaluate existing design decisions, identify gaps in current operations, and define test cases and test plans, moving an organisation from hoping for the best to engineering for the certain.
Engineering a resilient future
STPA shifts risk management from a passive, box-ticking exercise into a rigorous design science. Once loss scenarios are identified, they drive architecture, inform design recommendations, and enable precise revisiting of existing decisions. It transforms risk management into a tool for building superior systems rather than merely documenting their inevitable flaws. The question for any organisation is whether its current risk strategy manages the individual pieces of the puzzle, or manages the way those pieces actually fit together. True resilience is not found in the silence of past successes, but in the systematic scrutiny of the hidden vulnerabilities that have yet to speak.
Tony Ridley, MSc CSyP FSyI SRMCP, advises boards and executives on enterprise security risk management, drawing on decades of operational risk leadership across critical infrastructure, government and complex global programs. Organisations seeking to move beyond checklist-based risk management and build STPA-informed leading indicators into their governance and design decisions can engage Tony directly for a structured control-loop assessment of their systems.