How to Read This Article

This article is written for two audiences. Choose your path:

  • If you are a Decision-Maker or Manager: Start at Why PfC Is a Business Decision, then jump to the 30/60/90 Roadmap and Operational Metrics. The technical sections give you the depth to evaluate your team's work.
  • If you are a Senior Engineer or Architect: Read linearly. The attack surface scoring example, the ACL delegation drift case, and the ownership model are built for you.

Introduction: PfC Is a Leadership and Operations Discipline

Are we in danger? Yes. In any connected enterprise, identity systems operate under continuous adversarial pressure: phishing, credential theft, token abuse, supply-chain compromise, insider misuse, and configuration drift. These are not hypothetical risks. They are the daily operational reality of every Active Directory environment of meaningful size.

Can compromise be fully avoided? No. You can reduce probability and blast radius. You can layer controls, harden configurations, and enforce least privilege. But you cannot reduce risk to zero, and the organizations that act as though they can are the ones that spend the worst day of their year deciding core containment steps for the first time under fire.

The useful question is no longer "if we get compromised." That question is retired. The only questions that matter operationally are: when, how far it spreads, how quickly your team contains it, and how much of that response was pre-decided rather than improvised in a crisis.

Planning for Compromise (PfC) is the operating model that transforms this reality into repeatable action: identify what matters most, pre-design containment paths, rehearse response decisions, and continuously correct weak points before adversaries find them first. It is not a framework you implement once. It is a discipline you run continuously, with named ownership, measurable outcomes, and a cadence that survives leadership change.

Plan for Compromise
Plan for Compromise (PfC) is a continuous discipline, not a one-time project. It is the operational counterpart to hardening: hardening reduces probability, PfC reduces impact and recovery time.

Table of Contents

Why PfC Is a Business Decision

Manager Fast-Track

This section is written directly for decision-makers. It does not require technical background. Engineers: this section gives you the language to make the case to your leadership.

Every enterprise security conversation eventually lands on the same question: "How much is enough?" The honest answer is that no investment makes compromise impossible. The practical answer is that the right investment makes compromise survivable — quickly, with bounded damage and a pre-rehearsed response.

What PfC costs is structured time: time to inventory what matters, time to map how it can be reached, time to write and test response playbooks, and a named owner to keep that work current. What PfC avoids is the far higher cost of an ad-hoc response during a live identity-tier incident: extended outages, unclear decision rights, legal exposure from inadequate containment documentation, and the organizational damage of a public breach response that looked improvised — because it was.

The three questions a manager should be able to answer after PfC is in place:

  1. If our most privileged account is compromised tonight, what happens in the first 30 minutes — and who authorizes each action?
  2. When did we last rehearse that response, and what changed as a result?
  3. Who is responsible for keeping that playbook current between incidents?

If those questions cannot be answered without a meeting, PfC is not yet operational. The 30/60/90 Roadmap at the end of this article defines what a realistic path to operational looks like, including deliverables and timelines.

What Is PfC?

Planning for Compromise (PfC) is a structured readiness model that assumes at least one critical security control will eventually fail — not because your controls are weak, but because adversaries are adaptive, environments are complex, and time is on the attacker's side. PfC defines in advance:

  • What business and identity assets are most critical and what constitutes a meaningful compromise of each.
  • What attack paths can reach those assets from realistic starting points.
  • What containment actions are pre-authorized and executable in the first minutes.
  • How decisions are made, by whom, and with which data under time pressure.
  • How to recover service while preserving forensic integrity.
  • Who maintains this model between incidents so it does not decay into a document no one reads.

PfC is not a replacement for hardening. It is the operational counterpart to hardening, and both are required. Hardening reduces the probability that a given attack path succeeds. PfC reduces the impact and recovery time when one does. An organization that hardens well but has no PfC is one good exploit away from improvised crisis management. An organization that has PfC but does not harden is planning to fail gracefully rather than planning to win. The combination is what mature security operations looks like.

For hardening foundations, the Active Directory Hardening Checklist (2026), the Enterprise Access Model (EAM), and the AD CS Enterprise PKI Hardening Checklist provide the technical baseline. PfC sits above and alongside those — it is what you do when those controls are not enough.

PfC aligns directly with the Zero Trust principle of “never trust, always verify.” Where Zero Trust applies that principle to every access control decision at the perimeter, PfC applies it to incident response decisions: during a compromise, no account, token, certificate, or log entry can be assumed trustworthy until verified against a known-good baseline. This is why establishing that baseline before an incident is a hard prerequisite — you cannot verify against a baseline you build under adversarial conditions.

PfC is compatible with established incident response frameworks. It maps to NIST SP 800-61r3 (Computer Security Incident Handling Guide) and extends naturally into MITRE ATT&CK-based detection engineering for Active Directory. The Five Eyes advisory on AD compromises serves as a ready-made scenario library for PfC exercises: each of the 17 documented attack techniques is a valid runbook candidate. What PfC adds to those frameworks is the identity-plane-specific operational layer: a named asset inventory, scored attack paths, pre-authorized containment actions, and the ownership model that keeps the program current between incidents.

PfC vs. BCP/DR — Not the Same Thing

The most common objection to dedicating resources to PfC is one that sounds reasonable on the surface: "We already have Business Continuity and Disaster Recovery planning. We run tabletops. This is covered."

It is not covered. Here is why that objection fails under examination.

Dismantling the “We Already Do This With DR” Objection

BCP/DR and PfC operate on fundamentally different assumptions. Conflating them is not a planning efficiency — it is a blind spot.

Dimension BCP / DR Planning for Compromise (PfC)
Failure assumption Known failure modes: hardware loss, datacenter outage, natural disaster, power failure. The failure is usually accidental and predictable in category. Adversarial, adaptive, and deliberate failure. The attacker chooses the timing, the vector, and the scope. The failure mode is unknown until it happens — and designed to avoid your existing detection.
Goal Restore service. Get back to operational state as defined by RTO and RPO. Contain damage first. Preserve forensic integrity. Recover without re-introducing the attacker. Restoration is phase three, not phase one.
Identity posture Identity systems are assumed intact. DR restores from backup and resumes service. The assumption is that the identity plane is trustworthy. Identity systems are the primary target. The first assumption in an identity-tier incident is that the identity plane is not trustworthy — and that credentials, tokens, and certificates may already be compromised.
Response sequence Detect → Escalate → Restore → Validate. Detect → Triage → Contain → Eradicate → Investigate → Recover → Validate. Each step has a pre-authorized action and a decision owner.
Tabletop coverage DR tabletops test known scenarios against documented runbooks. Success is measured by whether service is restored in time. PfC exercises test adversarial decision-making under uncertainty. Success includes whether the team correctly identified what not to trust — including their own tools, accounts, and logs.
Decay risk DR plans decay slowly; infrastructure changes drive updates. PfC decays immediately when the threat landscape changes, when privilege assignments drift, when new attack paths emerge, or when personnel responsible for containment actions leave.

The critical distinction is this: BCP/DR assumes the failure mode is known in advance. PfC assumes the attacker has already studied your environment and is exploiting the gaps your DR plan does not cover.

A DR runbook that says "restore DC from backup" is useless if the backup was enrolled under a compromised CA and the restoration process re-introduces attacker persistence. PfC asks — and pre-answers — the questions that DR does not reach: Which of our accounts can we still trust? Which certificates are suspect? Can we authenticate to our recovery infrastructure without using the identity plane we are trying to contain?

These are not DR questions. They are PfC questions. And they need to be answered before the incident, not during it.

How to Introduce PfC: Mindset Change

Most organizations stall on PfC not because the concept is rejected, but because the conversation never moves past prevention-only language. Every meeting starts with: "What are we doing to stop this?" That is the wrong first question. The right question is: "What are we doing when our controls fail — and how do we know we are ready?"

Shifting this conversation requires changing the vocabulary at the leadership level first. Engineers already know the controls will eventually fail. Managers often need the permission to say it out loud without it sounding like a concession of failure.

Legacy Mindset PfC Mindset Behavior Change
We focus on blocking everything. We block what we can and pre-plan for what we cannot block. Build and rehearse playbooks for top compromise scenarios, not just control checklists.
Risk reviews are annual. Risk reviews are continuous. Run monthly drift checks and attack-path reviews. Treat a changed privilege assignment as a risk event.
Incidents are ad-hoc. Incidents are rehearsed operations. Run quarterly tabletop and semiannual technical exercises. Measure elapsed time and decision quality, not just whether the scenario resolved.
Security owns response alone. Security, AD operations, platform, legal, and leadership co-own response. Define decision rights and an escalation matrix before an incident. Know in advance who authorizes emergency token revocation at 2 AM.
Proving we are safe. Proving we are ready. Replace compliance checkbox reporting with exercise outcomes and metric trends. Present MTTD and MTTC data, not just control coverage percentages.

War Story: Good Controls, No Playbook

Scenario: The Controls Held. The Response Did Not.

The environment: A mid-size financial services firm, approximately 4,000 AD accounts, hybrid identity with Entra ID Connect, MFA enforced on all internet-facing access, EDR deployed on all endpoints, and network segmentation between user and server tiers. By conventional measures, a mature security posture.

The incident: A phishing campaign targeting finance department staff yielded one set of credentials for a standard domain user account. The EDR agent caught the initial payload on the user's workstation and quarantined it. The attacker had already extracted the credentials before quarantine completed. Over the following six hours, the attacker authenticated from an overseas IP — not blocked by Conditional Access because the MFA prompt was completed on a previously trusted device that had been enrolled months earlier. From that foothold, the attacker began AD enumeration.

The enumeration itself generated no alerts. Authenticated LDAP queries from a valid user account are not inherently suspicious. Within two hours, the attacker had identified a service account in the Help Desk OU whose GenericWrite permission on a Tier 1 server group had not been audited since a migration three years prior. That service account was Kerberoastable. The password had not been rotated in 847 days.

Where PfC was missing: The security team detected the anomaly when the compromised service account authenticated interactively to a domain controller — an event that should never occur for a service account. Detection elapsed time: 4 hours 22 minutes after initial foothold. The account had DC local admin rights inherited through a stale group nesting. The attacker did not need them; they were a bonus.

Containment failed not because the team lacked technical ability but because no one had pre-decided: Who authorizes disabling a service account that may be running production jobs? What is the process for revoking Kerberos tickets for an account that may have issued tickets to other services? Which services need to be notified before we reset KRBTGT?

These decisions were made by committee, over two hours, via a conference call where three people had the authority to act and none of them were certain of the blast radius of each action. By the time containment was executed, the attacker had pivoted to a second service account and established persistence through a scheduled task on a Tier 1 server.

The lesson: Every technical control in this environment performed correctly. EDR quarantined the payload. MFA was enforced. Segmentation limited lateral movement paths. The organization failed at the one thing that no control can provide: pre-decided response choreography. PfC would not have prevented the initial credential theft. It would have reduced containment time from hours to minutes — which in an identity-tier incident is the difference between a contained event and a full domain recovery.

The ACL drift that enabled the escalation — the stale GenericWrite on a service account — is precisely the attack surface scored in the worked example below.

Define High-Value Assets and Services

PfC begins with a deliberately short list. The purpose of this exercise is not to enumerate every asset in the environment — that is an asset management function. The purpose is to identify the specific assets whose compromise would constitute a catastrophic event: full domain control, sustained business disruption, regulatory breach, or irreversible damage to the identity plane.

The most common error at this stage is marking everything critical. If everything is critical, nothing is. The list should be small enough to fit on a single page, and every entry should have a named owner who is accountable for its security posture and its presence in PfC runbooks.

Asset / Service Why High Value Primary Owner Priority
Domain Controllers / AD DS Identity root of trust. Compromise enables full directory control, credential replay across the entire forest, and the ability to issue or revoke trust for every system in scope. AD Operations Critical
KRBTGT account Compromise enables Golden Ticket attacks — arbitrary TGT issuance with no credential validation, persistent even after password resets of individual accounts. Recovery requires two KRBTGT password resets with replication propagation. Identity Security Critical
Domain Admins / Enterprise Admins / Schema Admins Privilege escalation pivot points. Any identity in these groups can reach every Tier 0 asset. Membership must be treated as a standing incident risk if it contains service accounts or inactive identities. Identity Security Critical
AD CS / Certificate Authorities A misconfigured certificate template or a compromised CA can give an attacker Domain Admin without touching a single credential. ESC1 through ESC16 escalation paths are well-documented and actively exploited. See the AD CS Enterprise PKI Hardening Checklist for the full attack surface. PKI Team Critical
ADFS / Entra ID Connect Sync Account In hybrid environments the Entra ID Connect sync account holds replication-equivalent rights in AD and write access to Entra ID. Compromise allows an attacker to synchronize password hashes, modify cloud identities, or silently disable MFA for cloud accounts. It is the most dangerous pivot between the on-premises and cloud identity planes, and requires simultaneous isolation on both sides. See Azure ARC + On-Premises AD: Hybrid Identity Integration for the full isolation procedure. Cloud Identity / AD Operations Critical
Entra tenant privileged roles / break-glass accounts Cloud control plane takeover risk. In hybrid environments, Entra ID Connect synchronization means on-premises compromise can propagate to cloud if sync accounts are not properly isolated. See Azure ARC + On-Premises AD Hybrid Identity Integration. Cloud Identity High
Privileged Access Workstations (PAWs) The device boundary for Tier 0 and Tier 1 interactive sessions. If PAW integrity is compromised, every session that originates from that device is suspect. The Enterprise Access Model defines the enforcement model. AD Operations / Endpoint High
Backup and recovery systems Last line of resilience after ransomware or destructive action. Backup infrastructure that shares domain credentials with production is not a recovery asset — it is an extension of the attack surface. Backups must be validated as restorable to a pre-compromise state, which requires knowing what the pre-compromise state was. Platform Operations High
DNS infrastructure DNS is the operational prerequisite for nearly every AD service. DNS poisoning, delegation abuse, or zone transfer misconfiguration can redirect authentication, intercept tokens, or silently reroute privileged sessions. See DNS Configuration and Best Practices. AD Operations High

This list is a starting point, not a template. Every environment has specific dependencies — legacy applications with service accounts that hold privileged access, third-party integrations with standing credentials, or operational constraints that create non-standard trust paths. The list must reflect your environment, not a generic model.

Map Attack Surfaces and Score by Criticality

After defining high-value assets, enumerate the reachable attack surfaces that provide a path to those assets. The goal is not a complete threat model — that exercise is valuable but separate. The goal here is to produce a prioritized, actionable list of attack paths that PfC runbooks and containment actions can be built against.

Organize attack surfaces into categories that reflect how privilege moves through the environment:

  • Identity surface: privileged accounts, service accounts, gMSAs, token issuance pathways, delegated rights, and Kerberos delegation configurations. The Role Based Access Control model defines the clean state this surface should reflect.
  • Endpoint surface: admin workstations, jump servers, PAWs, remote management tooling, and any device that initiates privileged sessions. A non-PAW device initiating a Tier 0 session is an attack surface, regardless of whether it is domain-joined.
  • Directory configuration surface: ACL drift, delegation misconfigurations, stale group nesting, AdminSDHolder inconsistencies, and schema modifications. This surface is particularly dangerous because it is often invisible until queried — and adversaries query it systematically during enumeration.
  • Certificate and PKI surface: certificate template permissions, CA ACLs, enrollment agent configurations, and PKINIT trust paths. The Five Eyes advisory explicitly identifies certificate abuse as a primary escalation path. See the full attack map in 17 Active Directory Attacks: Five Eyes Detection and Mitigation Guide.
  • Third-party and supply-chain surface: RMM tools, CI/CD service accounts, vendor VPN access, and backup agents. These frequently hold Tier 0 or Tier 1 credentials and are rarely subject to the same change control as native AD accounts.
  • Credential and authentication surface: NTLM fallback paths, unconstrained Kerberos delegation, LAPS coverage gaps, and accounts with passwords that predate current policy. The Credential Theft Defenses — Kerberos and NTLM Hardening article covers this surface in depth.
  • Tier-to-tier lateral movement paths: any mechanism by which a credential, token, or session validated at one tier can reach a higher-tier asset. This includes cached credentials on non-PAW devices, service accounts with cross-tier SPNs, Kerberos delegation chains that cross tier boundaries, and authentication policy gaps that permit non-PAW logon to Tier 0 or Tier 1 systems. The Tier Model and the Enterprise Access Model define the isolation requirements; this surface is everything that violates those requirements in the current environment.

Scoring Attack Paths

Not every attack path warrants the same response investment. Use a simple multiplicative scoring model to prioritize: Risk Score = Impact × Reachability × Exposure, scored 1 to 5 on each axis.

Axis 1 (Low) 3 (Medium) 5 (High)
Impact Compromise of a single non-privileged resource Compromise of a Tier 1 service or group Compromise of a Tier 0 asset or full domain
Reachability Requires physical access or pre-existing Tier 0 credential Requires authenticated domain user access Reachable without authentication or from internet-exposed surface
Exposure Control exists, is enforced, and is monitored Control exists but is inconsistently applied or unmonitored No control, stale configuration, or actively misconfigured

Maximum score is 125. Paths scoring above 60 should have a dedicated PfC runbook. Paths scoring above 90 are immediate remediation priorities regardless of PfC readiness.

PfC and the Tier Model: Response Priority by Tier

The Tier Model and the Enterprise Access Model (EAM) are not only hardening frameworks — they are the structural foundation for PfC priority decisions during response. The tier boundaries you define under normal operations become the containment boundaries you enforce during an incident. Without that pre-established structure, a compromise of any asset is a potential path to every asset, and response priority defaults to whoever speaks loudest in a conference call rather than to objective risk.

When a compromise is detected, the tier assignment of the affected asset determines containment priority, scope of investigation, and the credibility threshold for evidence and tooling:

Tier Assets in Scope Compromise Impact PfC Priority Containment Sequence
Tier 0 / Control Plane Domain Controllers, KRBTGT, AD CS / CA, ADFS, Entra Connect sync account, PAWs for Tier 0 admins Full forest and tenant control. All lower-tier assets must be treated as potentially compromised. Recovery may require forest rebuild if KRBTGT or CA private key is involved. Immediate — Tier 0 runbook activates automatically Isolate affected DCs from network → disable compromised privileged accounts → flush and re-issue Kerberos sessions → preserve forensic state before any change → execute Tier 0 runbook out-of-band
Tier 1 / Management Plane Member servers, service accounts, management tooling, monitoring infrastructure, jump servers Potential path to Tier 0 via cached credentials, delegation chains, or lateral movement. Impact is containable if tier boundaries are enforced and no Tier 0 credential material was present on the compromised system. High — Tier 0 exposure check is mandatory first step Identify whether any Tier 0 credential was exposed → isolate server → rotate service account credentials → audit Kerberos delegation chains that reach Tier 0 → verify no PAW or DC was accessed from the compromised host
Tier 2 / User Access Plane User workstations, standard user accounts, helpdesk endpoints, internet-facing systems Initial foothold for most attacks. Risk is lateral movement upward. Contained within Tier 2 if boundaries are correctly enforced and no privileged credential material was present on the endpoint. Standard — verify no tier boundary was crossed Isolate affected workstation → reset affected user credentials → confirm no Tier 1 or Tier 0 credential was cached on the endpoint → scan peer workstations for the same indicator of compromise

The value of this model during an incident is not the table — it is the decision habit the table represents. Every containment action in a PfC response starts with the same question: which tier is affected, and has the compromise crossed a tier boundary? If the answer is yes, or if the answer is currently unknown, treat the higher tier as affected until proven otherwise. Optimism is not a containment strategy.

Tier Boundary Failure Is the Most Expensive PfC Failure

An organization with the Tier Model on paper but without tier-boundary enforcement in its response actions has a model that provides no incident-time value. The most dangerous scenario is not the attacker who immediately reaches Tier 0. It is the attacker who sits at Tier 1 for hours while the response team treats the event as a Tier 2 workstation incident — unaware that a stale delegation chain or a cached service account credential provides a Tier 0 escalation path that is not yet visible in logs. Every Tier 1 or Tier 2 incident must include a mandatory Tier 0 exposure check as its first technical step, regardless of initial appearance.

This is also why PfC and the Tier Model must be maintained together. A new tier assignment, a new delegation, or a new trust path that is not reflected in the PfC asset inventory and attack surface map means the tier boundary exists administratively but not operationally when it matters most.

Worked Example: ACL Delegation Drift to Tier 0

ACL delegation drift is one of the most consistently underestimated attack surfaces in Active Directory environments. Unlike a misconfigured firewall rule or an unpatched service, delegation drift is silent, accumulates over time, and is rarely visible without deliberate enumeration. It is also one of the most common paths to unexpected Tier 0 write access — the exact condition an attacker enumerates for immediately after gaining authenticated domain user access.

The scenario below is representative of conditions found in real enterprise environments, particularly those that have undergone migrations, reorganizations, or delegated help desk provisioning without subsequent ACL cleanup.

Scenario

During a routine Active Directory housekeeping review, an engineer queries the ACL of the Domain Controllers OU and discovers that a group called SG_HelpDesk_Provisioning holds GenericWrite on all objects in the OU. This permission was delegated four years earlier to allow help desk staff to update description fields on DC objects during an asset management initiative. The initiative ended. The delegation was never revoked.

GenericWrite on a Domain Controller object enables an attacker who controls any member of that group to write arbitrary attributes — including msDS-AllowedToActOnBehalfOfOtherIdentity, which controls Resource-Based Constrained Delegation (RBCD). From RBCD write access on a DC, an attacker can impersonate any user, including Domain Admins, to that DC. This is a complete Tier 0 compromise path from a help desk group membership.

Attack Surface Score

Axis Score Reasoning
Impact 5 RBCD write on a DC enables impersonation of any user to that DC — full Tier 0 compromise. Attacker can DCSync, extract KRBTGT, and achieve forest-wide persistence.
Reachability 3 Requires authenticated domain user account that is a member of SG_HelpDesk_Provisioning, or the ability to add an account to that group. Standard domain user cannot reach this directly, but help desk staff or anyone who can control a help desk account can.
Exposure 4 The delegation exists and is unmonitored. No alerting is configured for msDS-AllowedToActOnBehalfOfOtherIdentity modifications on DC objects. The group membership is not reviewed on any cadence. Not a 5 only because the group is not directly accessible to all domain users.

Risk Score: 5 × 3 × 4 = 60. This path sits at the threshold that mandates a dedicated PfC runbook. Given the Tier 0 impact, it should also be treated as an immediate remediation item.

PfC Response Actions for This Path

  • Detection trigger: Alert on any write to msDS-AllowedToActOnBehalfOfOtherIdentity on objects in the Domain Controllers OU (Event ID 5136, attribute msDS-AllowedToActOnBehalfOfOtherIdentity). This attribute should never change in normal operations.
  • Pre-authorized containment: Immediate removal of SG_HelpDesk_Provisioning from the Domain Controllers OU ACL. Pre-authorized with AD Operations lead; no approval committee required at 2 AM.
  • Forensic preservation: Before ACL modification, capture current ACL state, group membership of SG_HelpDesk_Provisioning, and recent Event ID 5136 entries for DC objects. These are required for the post-incident review.
  • Remediation: Revoke the delegation. Review all OUs for equivalent stale GenericWrite, WriteDACL, and WriteOwner delegations. The RBAC delegation model defines the clean-state target.

This example illustrates why attack surface mapping is not a one-time exercise. The delegation was clean when it was applied. It became a Tier 0 attack path when the business context changed and the cleanup step was omitted. Environments drift. PfC must account for that drift, not assume the hardened baseline persists.

How to Plan, Evaluate, and Maintain PfC

Plan

The planning phase produces the artifacts that make response fast and pre-decided. The goal is not documentation for compliance — it is documentation that an engineer can execute from memory in a stressful environment, with an offline copy available when the identity plane cannot be trusted.

  • Create "first 15 minutes," "first 60 minutes," and "first 24 hours" runbooks for the top five identity compromise scenarios in your environment. For most AD environments, those scenarios are: domain admin credential compromise, KRBTGT compromise, DC ransomware or destructive action, AD CS CA compromise, and Entra ID Connect account compromise in hybrid environments.
  • Pre-authorize emergency controls. Every containment action that requires approval is a containment action that will be delayed. Decide in advance: who can authorize account disable, token revocation, host isolation, and traffic blocks — and under what conditions can those actions be taken without escalation. Document this in the runbook, not in a separate policy document that no one will find at 3 AM.
  • Define the response chain: incident commander, technical lead, communications lead, and executive decision owner. Each role has a primary and a backup. Each backup knows they are the backup and has read the runbook.
  • Prepare offline references and out-of-band communication channels for identity-plane incidents. If your incident response tooling authenticates against Active Directory, it may be unavailable or untrustworthy during an AD compromise. This is not a hypothetical — it is a documented failure mode in multiple large-scale incidents.
  • Integrate PfC into your existing operations cadence. Monthly drift reviews are not additional work — they are the mechanism by which PfC stays current.

Runbook Minimum Viable Structure

Every PfC runbook must contain at minimum:

  • Trigger condition: the specific detection signal or indicator that activates this runbook — not a category, a specific event ID, alert name, or observable behavior.
  • First action (T+0 to T+5 min): the single most important step to execute immediately — typically isolation or forensic evidence capture before any change is made.
  • Decision owner: named individual (with a named backup) who can authorize each containment action without committee approval. Include phone number on the offline copy.
  • Pre-authorized action register: the full list of containment steps executable without escalation, and the conditions that trigger each one.
  • Escalation threshold: the condition that requires executive notification, legal notification, or regulatory disclosure. Defined in advance, not during the incident.
  • Forensic checklist: what to capture before any change is made — ACL state, event log window, group membership snapshot, active session list.
  • Out-of-band contact list: phone numbers and communication channels that do not require AD authentication. If your incident response tooling authenticates against the directory you are trying to contain, it is not available during a Tier 0 incident.

Evaluate

A plan that has never been tested is a hypothesis. PfC exercises are how you convert hypotheses into confidence. They also produce the most actionable findings for remediation: brittle dependencies, unclear decision rights, and detection gaps that only become visible when you simulate the actual event.

  • Run quarterly tabletop exercises with realistic adversarial scenarios. Do not run scenarios that are too easy to be useful. If the team resolves every tabletop scenario cleanly in 20 minutes, the scenario was not realistic — or the team has already rehearsed it enough that a harder scenario is overdue.
  • Run technical simulations — red team, blue team, or purple team — at least twice per year. These surface detection gaps that tabletops cannot. The Five Eyes AD Attack techniques provide a ready-made scenario library for technical exercises.
  • Validate every runbook step with evidence: command output, log entries, elapsed times, and decision logs. A runbook step that says "isolate the compromised host" is not validated until someone has executed the isolation command, confirmed it in monitoring, and recorded the elapsed time.
  • Review and revise assumptions after each exercise. Every exercise will expose at least one assumption that was wrong. That revision is the deliverable, not the exercise completion certificate.

Maintain

PfC decays faster than BCP/DR plans because the threat landscape, the privilege assignments, and the attack paths in your environment change continuously. The maintenance cadence must match that rate of change.

  • Review the high-value asset inventory monthly. Not because the list changes frequently, but because the ownership and the security posture of each item does.
  • Review the attack surface map monthly or after any significant architecture change. A new service account, a new application integration, or a new firewall rule can open an attack path that did not exist in last month's map.
  • Update runbooks immediately after incidents, exercises, or organizational changes. A runbook that references a team member who left three months ago is worse than no runbook — it creates false confidence.
  • Track remediation backlog for identified weak points to closure, not just risk acceptance. Risk acceptance is a valid decision when made deliberately. It is not a substitute for fixing a known Tier 0 attack path that scores above 90 on the risk model.
  • Incorporate LAPS coverage gaps into monthly reviews. Accounts without LAPS-managed local credentials represent reachable lateral movement paths that are easy to track and should never appear on a stable environment's attack surface map without an active remediation ticket.

Post-Incident Review

Every incident — whether a contained near-miss or a full domain recovery — is the highest-quality PfC input you will ever receive. Real events update attack surface scores with observed data, expose runbook gaps under real conditions, and generate the organizational momentum needed to close long-deferred remediation items. An incident that produces no PfC improvements is an incident that will be repeated.

  • Conduct the post-incident review within 72 hours of incident closure, while details and decision timelines are still fresh and before the team is absorbed by the next operational priority.
  • The review must answer four questions: What was the initial indicator and when was it actionable? What delayed detection or containment? Which runbook step was missing, wrong, or unclear under real conditions? Which attack surface risk score was underestimated?
  • Update the high-value asset inventory, attack surface map, and affected runbooks within 14 days of the review. Every finding that identifies a control gap enters the remediation backlog with a named owner and a due date — not a risk acceptance note.
  • Brief leadership with findings and remediation commitments, not just an incident timeline. The period immediately after a contained incident is the highest-leverage moment to invest in PfC improvements before organizational urgency fades.

PfC Ownership: Who Runs This Between Incidents?

The most reliable way to ensure PfC fails is to assign ownership to a committee. Committees schedule meetings. Ownership without a named individual accountable for outcomes is shared ownership, which in practice means no ownership. When the next incident arrives, the committee will convene — and discover that the runbooks were last updated fourteen months ago by someone who has since left.

PfC requires a named PfC owner: a senior engineer or identity security lead who is accountable for the program's operational state between incidents. This person is not solely responsible for writing every runbook or conducting every exercise. They are responsible for ensuring those things happen on schedule, that the deliverables meet the standard, and that leadership has accurate visibility into the program's state.

What the PfC Owner Does Between Incidents

Cadence Activity Output
Weekly Review security event summary for Tier 0 indicator categories. Review any changes to privileged group membership, DC ACLs, or CA configuration from the prior week. Flag items requiring runbook update or attack surface re-scoring.
Monthly High-value asset inventory review. Attack surface map review. LAPS and privileged account coverage check. Verify offline reference materials are current and accessible. Updated asset register and attack surface map. Remediation tickets for new findings.
Quarterly Tabletop exercise planning and execution. Runbook review against current environment. Metric reporting: MTTD, MTTC, runbook coverage. Exercise findings report. Updated runbooks. Metric trend report for leadership.
Semiannual Technical simulation (red/blue/purple). Full attack surface re-scoring. Review of decision rights and escalation matrix for personnel changes. Technical exercise report. Revised attack surface scores. Updated response chain.

Why a Committee Kills PfC

Committees are appropriate for governance decisions. They are not appropriate for operational maintenance of a security readiness program that degrades in real time. A committee cannot be paged at 2 AM. A committee cannot make a pre-authorized containment decision. A committee will defer the monthly attack surface review to next month when three members are traveling — and next month will repeat the pattern.

The PfC owner requires organizational authority commensurate with the responsibility: the ability to require updates to runbooks from other teams, to schedule and mandate participation in exercises, and to escalate unresolved remediation items to leadership without it being treated as an interpersonal conflict. If the PfC owner cannot require participation, PfC is advisory rather than operational — and advisory PfC is indistinguishable from no PfC when the incident happens.

Operational Metrics That Prove PfC Works

PfC is not a qualitative program. It produces measurable outcomes, and those outcomes should be reported to leadership on a regular cadence. If the metrics are not tracked and reported, PfC will be the first program cut when budget pressure arrives — because there will be no evidence of what it is preventing.

Metric Target Why It Matters
MTTD — Mean Time to Detect < 15 minutes for Tier 0 indicators Attacker dwell time is the primary driver of blast radius. Every minute of undetected activity is lateral movement opportunity. A 15-minute MTTD for Tier 0 events is achievable with correctly configured alerting and requires validation in every technical exercise.
MTTC — Mean Time to Contain < 30 minutes for privileged account abuse Containment speed determines how far the compromise spreads. Pre-authorized containment actions are the mechanism that achieves this target. If containment requires a committee approval, 30 minutes is not achievable.
MTTR — Mean Time to Recover Defined by business-critical service SLOs Recovery without re-introducing attacker persistence requires knowing what clean state looks like. This requires both a current baseline and a validated restoration process — neither of which can be developed during the incident.
Runbook Coverage 100% for top five identity compromise scenarios No critical scenario should be improvised. A scenario without a runbook is a scenario where response quality depends entirely on who happens to be available — which is not a repeatable outcome.
Exercise Completion Rate Quarterly tabletop + semiannual technical simulation Exercises that do not happen on schedule are exercises that did not happen. Track completion rate and report it. A missed exercise is a risk event, not an administrative oversight.
Remediation Backlog Age No open item above 90 risk score older than 30 days Risk acceptance is a decision. Indefinite deferral is not. Tracking backlog age converts known attack paths from accepted risk into accountability items.

Real-World Examples: Why PfC Is Not Optional

The pattern across major identity-tier incidents is consistent enough to be instructive: initial access is rarely the decisive event. The decisive events are what happens in the hours and days after initial access — specifically, whether the attacker can enumerate privilege paths faster than the defender can contain them.

Incident How the Identity Plane Was Used PfC Lesson
NotPetya (2017) Initial access via a legitimate software update. Credential material on infected systems enabled lateral movement without additional exploitation. Domain-wide propagation occurred within hours across organizations with no administrative tier separation. Organizations with no pre-authorized containment actions made response decisions for the first time during the worst incident of the decade. Damage was not primarily technical — it was response paralysis. PfC lesson: pre-authorized isolation of domain-joined systems must not require committee approval at 2 AM.
SolarWinds Compromise (2020) Supply-chain access via a trusted update mechanism. Attackers moved from on-premises to cloud environments by exploiting SAML token forging and over-provisioned application trust paths that were not misconfigured — just never scoped down. No individual control failed; the trust model was the problem. Affected organizations could not quickly answer: which trust paths can we revoke immediately, and what breaks when we do? PfC lesson: trust paths between on-premises AD and cloud identity must be inventoried and have a documented revocation procedure before an incident requires it.
Enterprise Ransomware Campaigns (ongoing) Documented playbook: phishing for initial access, authenticated LDAP enumeration, Kerberoasting or LAPS gap exploitation, Tier 0 credential theft, domain-wide deployment timed to maximize recovery cost. Each step maps to a detectable technique in the Five Eyes AD Attacks guide. Organizations that recover in days rather than weeks had pre-decided at which point in this chain they would execute containment — and who was authorized to call it. PfC lesson: define the specific detection signal at each step of this chain that triggers escalation from “monitoring” to “contain now.”

PfC does not make these events harmless. It ensures that when they happen, your organization executes a rehearsed response against a known adversarial playbook — rather than making foundational decisions about its identity architecture for the first time while the attacker is still present.

30/60/90 PfC Roadmap

The roadmap below assumes no prior PfC program exists. If your organization already has elements of this in place — incident runbooks, tabletop exercises, a named security owner — the value is in assessing gaps against this structure and accelerating the phases where coverage is missing.

Window Focus Deliverables Owner
Day 0–30 Establish baseline High-value asset inventory with named owners.
Attack surface map with initial risk scores.
Top-five compromise scenario list.
Response ownership model: commander, technical lead, communications lead, executive escalation.
Named PfC owner appointed. 		PfC Owner + AD Operations Lead
Day 31–60 Operationalize First 15-minute / 60-minute / 24-hour runbooks for top-five scenarios.
Pre-authorized containment action register with decision rights.
Offline reference package and out-of-band communication tested.
Logging and detection validation for Tier 0 indicator categories.
Baseline MTTD and MTTC measured. 		PfC Owner + Security Engineering
Day 61–90 Stress-test First tabletop exercise conducted with findings documented.
Metric baseline established and reported to leadership.
Remediation backlog created with due dates and owners for items scoring above 60.
Items scoring above 90 escalated for immediate remediation.
PfC cadence scheduled for the following 12 months. 		PfC Owner + Leadership

Day 90 is not the end of PfC — it is when PfC becomes operational rather than a project. The deliverables above are the foundation. The cadence, the exercises, and the continuous review are what make that foundation durable.

Next Steps

Start today with three actions:

  1. Name your top three compromise scenarios and identify who currently owns the response to each. If ownership is unclear, that is your first PfC deliverable.
  2. Query your Domain Controllers OU ACL for any non-default delegations. Score each one against the Impact × Reachability × Exposure model. If any path scores above 60, it requires a runbook this month.
  3. Schedule the first tabletop exercise within 30 days. The scenario does not need to be perfect. The exercise needs to happen.

For a compact operational reference, the PfC entry in Tier Model and Delegation Model Questions and Answers provides a quick reference summary.

Resources and References