A consequence map traces one question through a system, asking what the business loses if it fails or gets compromised, and whether that loss can be recovered.

Building the map produces a ranked list of systems ordered by what failure actually costs. Systems at the top produce outcomes the organization cannot recover from. Systems at the bottom hurt but stay contained. This list drives every prioritization decision that follows, with no probability estimates or maturity scores, only direct answers per system.

Security runs the process but doesn't own the answers. Each system needs a technical owner, a business owner, and a finance or legal stakeholder if the system touches revenue, regulated data, or contractual obligations. Before classifying anything, get an executive to define what "existential" means for this organization.

Build a draft system list covering everything where compromise would be significant, including authentication, customer data storage, payment processing, production deployment, financial reporting, source code, customer-facing services, and anything holding credentials, regulated data, or intellectual property. A first pass usually runs 15 to 25 systems, and each one needs an assigned owner before scheduling.

Give each system 30 to 45 minutes. Keep a shared document open and record answers in real time so everyone can see them, and confirm the classification before the session ends.

Owners consistently underestimate what happens when their own systems get compromised, so the main job as facilitator is countering that optimism. When an answer sounds too low, push for specifics, asking what an attacker could do with the credentials of the most privileged account on that system. That question produces sharper answers than asking about consequence in the abstract.

Ask these questions in order, since each one builds context for the next.

1. What does this system do? One sentence, business function, not architecture.
2. What does it connect to, and what depends on it?
3. What data does it hold or process? The categories that change the classification: credentials or access tokens, customer personal data, customer financial data, regulated data (health, legal, government), intellectual property, internal operational data.
4. What happens if it is unavailable for one hour, one day, one week?
5. What happens if its data is corrupted or destroyed, not just the system being down?
6. What happens if its data is exfiltrated without any disruption? Who could be impersonated with it? What regulatory or contractual obligations are triggered?
7. What does recovery look like today? Has the system ever been restored from backup? Has anyone timed a full restore?
8. Is there any realistic scenario where compromise of this system produces an outcome the organization does not recover from?

Ask question 8 last. People answer it more directly after they've already walked through specific consequences than when it's asked cold at the start.

A system is "Existential" if the realistic worst case is unrecoverable, meaning regulatory action beyond what the organization can absorb, permanent loss of data it can't reconstruct, financial loss or liability beyond survival capacity, or damage that permanently destroys customer trust. Calibrate this to the organization's actual financial and reputational capacity, not to some abstract standard.

"High-recoverable" systems are costly but survivable, revenue loss measured in days or weeks, fines the organization can absorb, customer attrition that can be rebuilt over time, or operational disruption requiring real but limited recovery effort.

"Low-impact" covers everything where the consequence stays contained, the data isn't sensitive, and recovery is quick.

When a system sits between existential and high-recoverable, classify it as existential. Rank within each category afterward. The top of the existential list is where hardening and survivability work starts.

The output is a table with one row per system, covering system, function, data held, worst realistic scenario, classification, recovery status, and owner. Recovery status is "tested with a date", "untested" if a procedure exists but hasn't been run, or "unknown".

A sample row reads like this.

The customer auth service stores credentials and session tokens, and the worst case is credentials extracted, full customer impersonation, and a pivot to internal systems through service accounts. That system is existential, its recovery is untested, and the platform team owns it.

Optimism bias shows up in every session. Counter it by tying the existential question to the specific answers already collected during that same session, instead of asking about impact in the abstract. Some participants push to add likelihood scores to the classification. Redirect that straight away, since the map runs on consequence alone, because likelihood is too easy to manipulate and too hard to verify. The question is what happens if it occurs, not how likely it is to occur.

Remember, a map built only by the security team is fictional. The business and technical owners need to be in the room.

If you're just starting, run sessions for five systems only, namely authentication, customer data storage, payment processing if it applies, the production deployment pipeline, and source code. A clear map of five systems is more useful than an optimistic map of twenty, and coverage can expand each quarter.

As you go through the exercise, adapt it to your business. In regulated environments, the regulatory consequence of a breach dominates the existential classification, so systems touching regulated data, along with the systems controlling access to them, consistently land at the top. For SaaS companies, authentication, multi-tenant data isolation, and the production deployment pipeline usually classify as existential, since compromising any of them affects every customer at once.

Review the map quarterly for new systems, systems that changed significantly, or shifts in business context. Do a full refresh annually, and again after any major organizational change, such as an acquisition, entry into a new regulated market, a major architectural shift, or a new product line with a meaningfully different data or access profile.

Most security diagrams describe at best a system, showing its components, its boundaries, and the known risks attached to different parts. They show what exists, where it lives, and what might be wrong with it. Often, though, those diagrams are staled, as they are never updated once a system goes live.

A consequence map tells a story about failure instead. It starts with a single compromise or issue and follows it forward step by step, watching how it turns into actual damage. Rather than asking what the risks are, it asks what happens next once something breaks, and where that chain ends.

Traditional diagrams stay static, snapshots of a system at one point in time. A consequence map moves, forming a chain of cause and effect where each step leads to the next until it reaches something the business cares about, like downtime, data loss, or legal exposure.