This guide turns the Security Brutalism and Survivability Engineering framework into a sequence of actions for a program that is starting from a minimal/weak or nonexistent baseline, inside an organization where, like most places, politics and compliance obligations already shape most of the agenda. It assumes you cannot restructure the org, replace the tool stack, or win every argument with leadership in month one. It assumes you can, however, get five systems mapped, a handful of identities revoked, MFA everywhere, and one restoration tested for real. Doing those things changes what the organization can survive.

The central question behind every decision here is how long the business stays failed if a consequential system gets compromised today. Everything else, tools, frameworks, and audits, gets judged against whether it moves that number down.

Security and compliance run on separate tracks

This is important and it's needed for clarity, so state this early and repeat it often, because it is the single biggest source of wasted effort in an immature program: a control that satisfies an auditor and a control that improves survivability are different things, even when a single action happens to produce both.

Compliance work has its own owner, its own calendar, and its own deliverables, typically driven by a framework like SOC 2 or PCI, and by contractual obligations from customers or regulators. That work needs to happen, period. It funds headcount, it unblocks sales, and skipping it creates business risk. Let it run in parallel, staffed and scheduled on its own track, and resist the urge to let audit season set the security roadmap. Security work is different and has one question behind it, does this reduce the paths an attacker can use to reach a consequential system, limit what they can do once inside, or shorten how long the business stays broken? A policy document that satisfies an auditor but nobody follows fails that question. A quarterly access review that also happens to satisfy an auditor passes it twice, and that overlap is welcome when it appears, but it is not the reason to do the work.

When a compliance requirement and a survivability priority point in the same direction, do the work once and let it count for both. When they diverge, and they will, do not let the audit deadline reorder the security priority list. A pentest scheduled to close an audit finding is not the same thing as a red team exercise run against your actual consequence map, and treating the first as a substitute for the second is how programs end up with a certificate and no idea how long they would stay failed.

Phase 0: choose an owner and set the constraint

Before any technical work starts, choose a single person accountable for this program, not a team or a committee. Diffuse ownership is how a baseline decays the moment its builder leaves. If that person is you, say so out loud to whoever you report to, and get the executive backing you need. Executive leadership must mandate, in writing, that security priorities get evaluated on survivability, and compliance priorities run on their own track. You will need to point back to that more than once.

Set the resourcing expectation realitically; everything in Phase 1 through Phase 3 below is achievable by a small security team with the help of some infrastructure and IT folks within a few months. Nothing here requires a large budget or a mature organization behind it. However, it does require access to the identity provider, the cloud consoles, the code repositories, and thirty minutes each from five people who understand how the business runs.

Phase 1: build the consequence map

Start here, not with tools or a risk register full of color-coded heat maps and probability scores. You are building a ranked list of what actually ends the business if it fails, because that list decides where every dollar of effort after this point gets spent.

Pick five systems to start, maybe choose: authentication, customer data storage, payment processing if it applies to you, the production deployment pipeline, and source code. For most organizations these five cover the scenarios that would truly end the business, so map them before touching anything else.

For each system, run a thirty to forty five minute session with the technical owner and the business owner in the room together, security facilitating rather than filling in the form alone, and finance or legal joining when the system touches revenue, regulated data, or contractual obligations. Work through these questions in order, because the sequence really is important: what the system does in one plain sentence, what it connects to and what depends on it, what data it holds, what breaks if it is unavailable for an hour, a day, or a week, what happens if its data is corrupted or destroyed rather than just taken offline, what happens if its data is exfiltrated with no visible disruption and who gets impersonated as a result, what recovery looks like today and whether anyone has actually timed a restore, for real, then, at the end, whether any realistic scenario produces an outcome the organization does not recover from.

Ask that existential question, "whether any realistic scenario produces an outcome the organization does not recover from", last. People give more realistic answers to it after they have already walked through specific consequences earlier in the conversation. If you ask that question first, it almost always comes back too optimistic. When someone tries to attach a likelihood score to a system instead of answering what happens if it fails, redirect them. The map runs on consequence alone because likelihood estimates shift downward under pressure and consequence does not.

Classify each system as "existential", meaning the realistic worst case is an outcome the organization does not recover from, "high recoverable", costly but survivable, or "low impact", where it stays contained and gets restored without much drama. When a system sits between existential and high recoverable, call it existential. Overprotecting something slightly less critical costs less than underprotecting something that turns out to matter more than you assumed.

You will hit two forms of resistance here that you need to be aware of. 1) political resistance shows up as a system owner reluctant to admit their system could end the company, because that admission implies responsibility. Counter it by tying the existential question back to specifics that already came out earlier in the same conversation, rather than asking about impact in the abstract. 2) compliance resistance will come up as someone wanting to fold this exercise into an existing risk register format with scoring columns that do not map to consequence. Keep the map separate. It can feed the compliance risk register later, but it should not be built to satisfy one.

Phase 2: build a working inventory, starting with identity

You cannot scope exposure for a system you do not know exists, and you cannot revoke access you have not found. This phase runs in parallel with Phase 1 rather than after it, since the mapping sessions will surface systems the inventory missed and the inventory will surface systems that need to be added to the mapping.

Pull from sources that already track what exists rather than building from a blank sheet. Query the identity provider for every application with an SSO or SAML integration, which surfaces most of what employees actually touch in a single pull. Pull the cloud provider's resource inventory across every account and region you have, since orphaned accounts with resources still running show up constantly after reorgs and acquisitions. Pull the full DNS zone and check certificate transparency logs for anything issued against your domains that you did not authorize. Pull SaaS subscriptions from accounts payable and compare that list against what IT already knows, because a payment approval trail catches shadow IT.

Then talk to five people. I would start with an engineering lead, the IT lead, a product lead, an operations lead, and the most senior engineer in the organization. Give each of them thirty minutes and one question: which systems does your team own or depend on that would cause the most damage if compromised or broken. This surfaces the legacy dependency nobody documented, and it consistently finds something the automated pull missed.

Identity is where the real exposure hides, and it is almost always larger than expected. Service accounts, API keys, OAuth tokens, CI/CD credentials, and machine identities usually outnumber human users by a wide margin, and they accumulate, without you knowing, through integrations built and forgotten, automation that outlived its purpose, and staff turnover where nobody thought to revoke what the departing person had provisioned. Find them by querying the identity provider for non-interactive accounts, pulling IAM roles and service principals from every cloud account, checking CI/CD systems for stored credentials, and running secret scanning across every code repository, since tokens left in source or in environment variables are a common and usually unreviewed access path.

For every non-human identity (NHI) you find, record what it accesses, when it was last used, and whether a current, documented owner exists. Anything with no recent activity and no owner gets revoked immediately, before the consequence map is even finished. An unused credential with no owner is unambiguous exposure regardless of what it happens to touch.

Phase 3: the baseline, in order

With a rough consequence map and a working identity inventory in hand, work through the baseline in the following sequence. Each step is small enough to finish in weeks, not quarters, and the order is chosen so early steps make later ones easier.

1. Put MFA on every authentication path reachable from the internet, with a passkey where you can manage it. This single control removes a large share of credential-based attack paths and returns more survivability per hour of effort than anything else on this list, which is why it goes first regardless of what else is competing for attention that week.

2. Revoke standing access with no current business need. Take every long-lived credential and every standing permission to a consequential system and require a documented reason for it to keep existing. Anything that cannot produce one gets revoked. Treat a broken process that surfaces from a revocation as useful information about an undocumented dependency, not as a reason to restore the credential without understanding it first.

3. Remove tools and controls that cannot answer what they improve. For everything currently in the security stack, ask whether it reduces exposure on a path toward a consequential system, limits damage once someone is inside, or shortens detection and recovery time. If nobody in the room can answer with evidence, that tool is a candidate for removal, not a permanent fixture defended by the fact that it was purchased for a reason once. Elevated-privilege tools with no clear answer need to be checked first, since they generate alert volume that dulls sensitivity to real signals and can expand the attack surface they were bought to shrink.

4. Deploy honeytokens in at least three places: a canary credential in a configuration file that is no longer active, a fake API key sitting in an internal wiki page, and a canary database credential in an old backup directory. These cost almost nothing to build or maintain and produce near-zero false positives, so any activation deserves immediate attention. This is real detection capability available to a security function of one or two people with no SIEM in place yet.

5. Set up logging on the five systems from the consequence map, shipped to an immutable store the systems can write to but never read, modify, or delete, and configured to alert on first-time access, access at unusual hours, changes to access controls, and unusual data volume. Build this as write-only and out-of-band from the start. Immutable logging cannot be added retroactively once an incident is underway, because the window that is critical, the time before detection fired, has already passed by then. This single architectural choice, made once at setup, is what makes every later forensic claim about scope trustworthy instead of a guess resting on logs an attacker could have already touched. And make sure a human actually reads what gets logged. An alert nobody reads is only a storage bill.

6. Run one real restoration. Pick the single most consequential system on your map, restore it from backup into a test environment, time the whole process end to end, and write down what broke or was missing, including documentation issues, who doesn't know what to do, and whether the data is actually restorable. This one exercise will tell you more about that system's actual survivability than anything else on this list, and if the restoration fails, that failure is worth knowing now rather than during a real incident when the cost of finding out runs far higher.

Name an owner for each item above, one person per item, not a team.

Testing whether the baseline is "real"

A baseline that exists in a document and one that actually works are different. The only way to tell them apart is to test it under conditions that resemble pressure.

Run the survivability test on your single most consequential system. Assume it is compromised right now and measure three numbers with a stopwatch. Check how long before someone notices, how long to revoke all access to it, and how long to restore it from the last backup to a known-good state. Write the numbers down and compare them to what you assumed before running the test. The delta between the two is what you are actually working with.

Trigger one honeytoken by hand and time how long the alert takes to reach a human, meassure the time the person takes to understand what happened, and how long before an investigation actually starts. If that chain takes hours or lands on someone who does not know what to do with it, the detection capability is not functioning yet and you need to focus on that.

Revoke your own access to a production system that should not have standing access in the first place, and watch what happens. A broken, undocumented process points something that needs fixing. Silence for several days tells you how much standing access in your environment sits idle rather than in active use.

Try answering three questions from evidence rather than memory, focuson on who has access to your most consequential system right now, what else could an attacker reach from it if it were compromised this moment, and when a backup was last successfully restored. Any question that takes more than ten minutes to answer, or comes back as nobody knows, marks the next problem to close.

Handling what cannot be fixed yet

Some systems in your environment will not reach the standard the top of the consequence map deserves, whether because they are legacy, because the team that owns them has other priorities, or because organizational authority to force change does not exist yet. Mark these as accepted risk rather than pretending they are covered. Note them in a risk register, if you have one, but don't just let them be there, follow up. Contain what you can around them, tightening network segmentation and stripping unnecessary access, and monitor what you cannot fix. A clearly documented gap is a far better position than a control that looks handled on a slide but was never actually verified. Again, do not foget these. Revisit them every 30 days to see if they can reach the standard.

Organizational authority is usually the hardest constraint in an immature or compliance-driven program; this work sometimes requires saying no to a deployment against real business pressure, and most security functions do not have that authority on day one. Build it through evidence rather than argument. A survivability test with real numbers attached, or a restoration that failed in a scheduled exercise instead of during an incident, moves a room in a way that a policy document never will.

Cadence to keeping the baseline from rotting

Security degrades the moment a system goes live. Access always expands and integrations pile up without documentation. Exceptions get approved and never revisited because... No one knows. Controls that were enforced on day one drift into theoretical ones by month six, as the different teams get busy with other things. Nothing here is anyone's fault specifically. It is what happens to any environment under continuous change, and the only response is a standing cadence that catches the drift while it is still small.

Monthly, walk through one consequential system's current access, network paths, detection coverage, and what changed since last time. Something always has. The discipline is in catching it while it is still small enough to be able to be fixed.

I would aim at quarterly reviewing every access grant to a consequential system against current business need and revoking what fails the test. Then continue with a review of every integration against current use. Finally, and it might be hard, run one timed restoration test, rotating through consequential systems so each gets covered at least once a year.

Run a red team exercise a year scoped to your actual consequence map rather than generic perimeter testing or CVE hunting, and measure real detection and response time under sustained pressure against the paths that would actually damage the business.

Evaluate every proposed tool, integration, or access grant against the three survivability questions continuously before it gets approved, and decline anything that cannot answer them.

Choosing metrics

Report the numbers that show whether the program works. Tool counts, vulnerability totals, and compliance scores describe inputs and effort, but they do not answer the question the program exists to answer.

Instead, track time to detect, measured from when an event happens to when a human understands it; time to contain and time to restore, both measured from real incidents and real test exercises rather than estimated from a runbook; track also blast radius per consequential system, tested rather than assumed. Alert signal quality is key here, make the share of alerts that turn out to represent something worth investigating a numer in your metrics too.

These take experienced security people and operational discipline to produce, and they are the only numbers that answer whether the program is getting better at the one thing it should be doing, and that is shrinking how long the business stays failed.

What comes after the baseline

Once the foundation is in place, with a consequence map, an accurate identity inventory, hardened access on consequential systems, detection that produces usable signal, and at least one tested restoration, there is one more thing you need to do, and that is beginning to secure agentic AI.

Agent security, which applies the same four steps of know, harden, see, recover, to every autonomous agent running with tool access in your environment, treating each one as an identity whose blast radius is set by whatever tools it can reach. Inventory every agent and every tool it can call; default every agent to read-only with explicit, time-bound grants for anything else. Log every tool call and flag sequences that look unusual regardless of what triggered them, and build a real kill switch that can stop a running agent mid-execution. Agents also need a control traditional systems do not, separating instructions from data structurally, since a web page or document an agent processes can carry adversarial instructions through the same channel as its legitimate task, and asking a model to just be careful about that is not a control.

Where to spend the first ninety days

If the list above feels like a lot, the sequence that produces the most survivability per hour of effort, in an organization with limited authority and existing compliance demands already competing for attention, runs roughly like this.

1. Weeks one and two: select the owner for the program, get the one-sentence executive backing for the security and compliance split, and start the consequence map sessions for the five starting systems.
2. Weeks two through six, running in parallel, pull the identity inventory from the identity provider, cloud accounts, and code repositories, and revoke anything with no recent activity and no owner as you find it.
3. Weeks four through eight, focus on MFA everywhere reachable from the internet, and start stripping standing access to the systems that came out existential on the map.
4. Weeks six through ten, stand up the three honeytokens and get immutable logging in place on the five mapped systems.
5. Weeks ten through twelve, run the first timed restoration test on the single most consequential system, and run the survivability test with a stopwatch on that same system.

By the end of ninety days you will have a viable answer to the question that started this: if the most important system in the business gets hit today, how long does it stay broken. That number, measured rather than assumed, is the actual state of the program, and closing the delta between that number and where it needs to be is the work from here forward.