What is STPA?

What must we have in order to be safe? Checking off the items on the emergency preparedness checklist

If you attended SREcon Americas 2025, you may have watched or heard about Theo Klein’s talk on STPA.

The core insight of STPA is that most really bad incidents—in software or anywhere else—happen because of interactions between components, not because of component failures themselves.

STPA is a design analysis method which lets us discover and protect ourselves against these potential unsafe component interactions.  It is part of a family of methods under the heading of STAMP developed by Prof. Nancy Leveson, John Thomas, and their students at MIT.

Technically STPA stands for “Systems Theoretic Process Analysis,” although we liked to backronym it as “Stuff That Prevents Accidents.”

When we were at Akamai, we were inspired by Prof. Leveson and the STAMP family of methods, including STPA, and worked to adapt them to the needs and challenges of software companies.  Together we have over a decade of experience both with using STPA directly as well as adapting it to these other environments.

Now, as independent consultants, we’re excited to help others learn about STPA and get the same value out.

If you’re interested in hearing more about STPA, please drop us a line!

Photo credit: iStock.com/Pixsooz