For Security Architects and Engineers

This phase assumes the consequence map already exists, built the way Building the Consequence Map and The Second Job describe. Everything below gets applied depth-first to the systems at the top of that list. Full, accurate coverage of your five highest-consequence systems is worth more than partial coverage spread across everything you run, so if capacity is limited, that is where it should go first.

Know: Inventory in Practice

Inventory covers four areas: identities, trust relationships, data flows, and external attack surface. The goal is accurate, queryable knowledge of what can reach what, not a configuration database that drifts out of date the moment it is built.

Start identity inventory with a query of your identity provider for every non-human identity, service accounts, API keys, OAuth tokens, pipeline credentials, and long-lived tokens. Most organizations find three to ten times more of these than expected. For each one, check what it can access, when it was last used, and whether it has a current, documented owner. Anything with no recent use and no owner gets revoked first, since an attacker who compromises a credential like that pays no operational cost. No legitimate process is watching it.

Trust relationship mapping traces what can actually reach your consequential systems, not what an architecture diagram claims should reach them. The two diverge constantly through firewall exceptions, new integrations, and ordinary growth. Work backward from each consequential system, asking what has a path or trust relationship to it, and what that thing connects to in turn. Repeat until the dependency graph is complete.

External attack surface follows the same logic outward. Something reachable from the internet needs a follow-up question for each reachable component, asking what it can touch internally if compromised. Third-party integrations and SaaS tools with access to internal systems belong on this list too, each one documented for what it can reach if the vendor behind it gets breached. The format of this documentation is less important than one thing you should be able to answer: "if system X is compromised, what can the attacker reach?" in under ten minutes, any day of the year.

Harden: Subtractive Work First

Hardening starts with removal, then moves to structural change. Adding controls before cutting unnecessary complexity is a common mistake, and it usually leaves the environment harder to defend.

Run every tool in your stack through the three questions from the frame, asking whether it reduces susceptibility, damage, or recovery time for a high-consequence system. Being purchased or occasionally used is not enough to keep a tool in place. Demonstrable improvement to survivability is the bar, and it is a critical bar since security tooling itself has served as the entry point in several supply chain compromises. Every tool in the stack is a potential target in its own right.

Access gets the same treatment. Enumerate every standing permission, long-lived credential, and service account grant touching a consequential system, and require a current, documented business need for each one. Anything that cannot be justified gets revoked, and this goes on the quarterly calendar permanently, since access accumulates, often without control, through normal operations whether anyone intends it to or not.

Integrations follow the same pattern, forcing you to map every third-party connection to a consequential system. Remove what is not actively used, and for what remains, document what becomes reachable if that integration is compromised.

A handful of structural principles follow directly from this. No standing access to a consequential system means access gets granted for a specific task, scoped to the minimum needed, with an expiration built in, implemented through just-in-time workflows with full audit trails. The point is that compromising a credential today should not hand someone months of unreviewed standing permission along with it. Separating duties for high-consequence actions, deleting production data, changing access controls, deploying to production, moving significant funds, means a second person or a mandatory review stands between intent and execution, not for compliance reasons but because it slows an attacker down and opens a detection window that would not otherwise exist. Blast radius by design brings segmenting systems to the picture so that full compromise of a neighbor does not hand over access automatically. Ask, for every high-consequence system, what an attacker could do if everything with a trust relationship to it were fully owned, and if the answer is everything, the segmentation needs to change. Friction, applied deliberately through re-authentication and step-up verification before irreversible actions, slows an attacker's progress and creates a detection opportunity, at the cost of some friction for legitimate users too, a tradeoff worth accepting in proportion to what the action can actually damage. Minimal footprint is not a one-time pass but an ongoing habit, since every running service, open port, and unused permission left in place is attack surface sitting idle.

See: Detection Engineering

The standard for detection is whether you know your consequential systems are under attack before the attacker reaches the objective, not whether a SIEM is deployed or an EDR coverage number looks good on a slide.

Build detection around the consequence map and the attack paths already identified during inventory. Knowing the realistic paths toward each high-consequence system means instrumenting the chokepoints on those paths, instead of chasing uniform coverage everywhere at once. Behavioral baselines on those systems form the foundation, since normal access follows recognizable patterns, specific identities, times, and operations, and any real deviation on a high-consequence system should trigger an alert immediately rather than showing up in a weekly summary.

A short list of anomalies deserves an immediate alert every time. First-time access from any identity to a consequential system is one. Access at unusual hours or from unusual locations for that identity is another, alongside an unusual volume of data access or export, a new process running on critical infrastructure, and any change to access controls or audit logging on a high-consequence system.

Lateral movement needs instrumentation on the paths between systems, not just at the endpoints, since an attacker moving from a workstation to an internal service to a database should be visible at each stage, not only on arrival. Honeytokens belong in this same layer as one of the highest-signal investments available for the effort required, since a canary credential or file placed somewhere no legitimate user would look produces almost no false positives and needs almost no upkeep after deployment. Placing them at several layers, a canary credential in a build artifact, a fake key on an internal wiki page, a stale credential in an unused config file, means any activation becomes a priority investigation on its own.

Alert volume is part of the engineering work. An alert nobody reads is not detection, it is noise with a logging cost, and if a team has already normalized skipping alerts because there are too many, the fix is pruning the rules until every remaining alert gets investigated, even if that means accepting fewer low-confidence signals in exchange for full attention on the ones that count. Behavioral detection catches what signature-based tools miss, since a signature has to be written after someone already knows what an attack looks like, while a deviation from normal shows up regardless of the specific technique behind it. A useful gut check for all of this asks whether, if every piece of security tooling went dark tonight, there's a concrete thing that would still tell you an attack is happening. If not, detection is more fragile than it looks on paper.

Recover: Building Recovery Capability

Recovery is usually where the difference between assumed and actual postures is most evident. In general, you can see this in backups that exist but have never been restored under real conditions, and in procedures that are documented but have never run under pressure, so the gap stays invisible until the day it isn't.

There are four measurements that make up the a more realistic posture for each consequential system, and each one needs, or rather requires, evidence behind it, not an estimate. Assuming compromise right now means asking what a realistic attacker can reach, take, or pivot to from current access, which defines today's actual blast radius. Time to detect asks, based on current monitoring, how long until a person is looking at the right data and understands what's happening, measured from the realistic path rather than a theoretical alert time. Time to contain focuses on how long it takes to revoke access, isolate the system, and stop further damage, with tested procedures behind each step rather than a plan that has only ever been written down. Time to restore shows whether a verified working state can actually be restored from backup, and how long that takes today.

The use of "kill switches" turn this into an architectural requirement. Every consequential system needs the ability to have all access revoked within minutes, which means knowing every identity with access to it and having tested that revocation end to end, not just reading through the runbook. If revoking a compromised service account takes hours and several teams coordinating manually, that duration is the real blast radius window, whatever the documentation claims. Tested restoration means actually running the restore in a test environment on a quarterly cadence for consequential systems, timing it end to end, and writing down what broke or was missing, since a gap found during a scheduled test gets fixed calmly, while the same gap found during a real incident becomes a much harder problem under time pressure.

Incident response exercises work best built from the same realistic attack paths identified during inventory, run with the actual people who would respond, rather than a generic tabletop where everyone already knows how it ends. The gaps that turn up this way are rarely technical. They tend to be unclear ownership, slow escalation, and communication breaking down once pressure builds. Chaos engineering extends the same idea to infrastructure. Introduce a controlled failure along a realistic attack path in a non-production environment, and measure how long it takes to alert, to human acknowledgment, to real understanding, and to containment. An assumption like "the SIEM will catch that" or "we can revoke credentials in five minutes" should get demonstrated this way rather than taken on faith.

Entropy Management

Security starts degrading the moment a system goes live. As we saw, access accumulates as teams change, firewall exceptions get approved and never revisited, and service accounts outlive their purpose. None of this reflects a lapse in anyone's vigilance, it's the natural state of things. It is what any production environment does under continuous change, and the discipline here is pushing back against that drift on a predictable schedule rather than waiting for it to surface on its own.

Every quarter, review every access grant to a consequential system against current business need, and revoke anything that cannot be justified against the actual list rather than the list as it's supposed to look. Run a restoration test for at least one consequential system the same quarter, rotating through systems so each one gets tested at least once a year. Once a year, run a red team exercise scoped specifically to the consequence map, aimed at finding which realistic attack paths succeed against current controls rather than hunting CVEs in general.

Continuously, run every proposed tool, integration, or access grant through the same three questions before it gets approved, and keep triage discipline on alerts, since a high-confidence alert buried under a pile of low-quality ones is functionally invisible until someone investigates it. A simple monthly habit ties all of this together. Pick one consequential system, walk through its current access list, network paths, and detection coverage, and ask what changed since the last look. Something always has. Catching that drift while it is still small is the entire point.