Security Brutalism Under Real Conditions: Building the Consequence Map

A consequence map is a model that traces a single question: "If this thing fails or is compromised, what does the business lose, and is that loss recoverable?" Think about it this way: cause → chain of effects → final impact.

Going through the map creation exercise outputs a ranked list of systems and capabilities ordered by what failure actually costs. Top entries are systems whose compromise produces outcomes the organization cannot recover from. Bottom entries are painful but contained. This list drives every prioritization decision.

No probability estimates. No maturity scores. Honest answers per system.

Before the Sessions

Security facilitates but does not own the answers. For each system you need the technical owner, the business owner, and any finance or legal stakeholder for systems touching revenue, regulated data, or contractual obligations. Have an executive confirm what "existential" means for the organization before you start classifying.

Build a draft system list covering everything where compromise would matter: authentication, customer data storage, payment processing, production deployment, financial reporting, source code, customer-facing services, and any system holding credentials, regulated data, or intellectual property. You should have a basic understanding of what matters.

First pass is typically 15 to 25 items. Assign a primary owner to each before scheduling.

Running the Sessions

30 to 45 minutes per system. Keep a shared document open and record answers in real time where all participants can see. Confirm the consequence classification before ending each session.

The most important facilitation task is countering optimism. Owners consistently underestimate the consequence of their own systems being compromised. When answers seem low, redirect to specifics: "If an attacker had the credentials of the most privileged account with access to this system, what could they do?" That produces more accurate answers than asking about consequence in the abstract.

The Questions

Ask these in order. Each builds context for the one after it.

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 give more honest answers to the existential question after they have already described specific consequences rather than when it is asked cold at the start.

Classifying Each System

Existential: realistic worst case produces an unrecoverable outcome. Regulatory action that exceeds the organization's capacity to absorb, permanent destruction of data the business cannot reconstruct, financial loss or liability that exceeds survival capacity, or compromise that permanently destroys customer trust. Calibrate existential to the organization's actual financial and reputational capacity, not to an abstract standard.

High-recoverable: costly but the organization survives. Revenue loss measured in days or weeks, absorbable fines, customer attrition that can be addressed over time, operational disruption requiring significant recovery effort.

Low-impact: contained consequence, non-sensitive data, readily restored.

When uncertain between existential and high-recoverable, classify as existential. Rank within categories. The top of the existential list is where hardening and security survivability work starts.

The Output

A table with one row per system:

| System | Function | Data held | Worst realistic scenario | Classification | Recovery status | Owner |

Recovery status is tested (with date), untested (procedure exists but has not been run), or unknown.

A sample row:

Customer auth service | Stores credentials and session tokens | Worst case: credentials extracted, full customer impersonation, pivot to internal systems via service accounts | Existential | Untested | Platform team.

Failure Modes

Optimism bias is the most consistent problem in every mapping session. Counter it by grounding the existential question in the specific answers already collected in that session, not by asking about impact in the abstract.

Probability creep is when participants push to add likelihood scores to the classification. Redirect directly: the map uses consequence only, because likelihood estimates are too easy to manipulate and too hard to verify. The question is what happens if it occurs, not how likely it is.

Running sessions with only the security team produces a fictional map. The business and technical owners must be in the room.

Adapting for Maturity

If you are just starting, run sessions for five systems only: authentication, customer data storage, payment processing if applicable, production deployment pipeline, and source code. An honest map of five systems is more useful than an optimistic map of twenty. Expand coverage each quarter.

For regulated environments, the regulatory consequence of a breach will dominate the existential classification. Systems touching regulated data and the systems controlling access to them will consistently sit at the top.

For SaaS companies, authentication, multi-tenant data isolation, and the production deployment pipeline typically produce existential classifications because compromise of any of them affects all customers simultaneously.

Keeping It Current

Review quarterly: new systems added, existing systems significantly changed, business context shifted.

Full refresh annually, and after significant organizational change: an acquisition, a new regulated market, a major architectural change, or a new product line with a meaningfully different data or access profile.

How it’s Different

Most security diagrams try to describe a system. They show components, boundaries, and known risks. What exists, where it lives, and what might be wrong with it. You end up with a picture of the environment and a list of concerns attached to different parts.

A consequence map does something more direct. It tells a story about failure. You start with a single compromise or fault and follow it forward step by step, watching how it turns into real damage. Instead of asking "what are the risks here?", you’re asking "if this breaks, what happens next, and where/how does it end?"

Traditional diagrams tend to feel static; they’re snapshots of a system. A consequence map is dynamic. It’s a chain of cause and effect, where each step leads to the next until you reach something the business actually cares about, like downtime, data loss, or legal exposure. It helps you understand and confront the outcome.