antifragile/antifragile-consulting/playbooks/rapid-modernisation-plan.md

# Rapid Modernisation Plan

> *"We must change our strategy from 'detect the attacker in time' to 'become the target that is not worth attacking.' Reactive mode is unsustainable. We must ensure the game is played on our field."*

## For the Executive Reader

This is not a three-year digital transformation. It is a **180-day foundation programme** with measurable progress at each phase gate.

| Phase | Timeline | What the Board Sees |
|-------|----------|---------------------|
| **Visibility** | Days 0–60 | We know the kill chain. T0 assets are identified, critical privileges are mapped, and logging is operational. |
| **Control** | Days 60–120 | The highest-risk kill chain nodes are closed. MFA is enforced on privileged accounts. Critical gaps have evidence-backed remediation. |
| **Signal** | Days 120–180 | Detection capability is built on the hardened foundation. Housekeeping is running as a permanent stream. The organisation can operate and maintain what was built. |
| **Antifragility** | Ongoing | Structural improvement, retained capability, and progressive reduction of technical debt. This phase does not end. |

**What 180 days delivers**: A hardened foundation, closed kill chain, operational detection capability, and the processes to sustain them. Not a complete transformation — a credible, maintained starting point.

**What 180 days does not deliver**: Elimination of all technical debt (that takes years), full AI sovereignty (that is a multi-year journey), or zero vendor dependencies (that is an ongoing programme). Promising otherwise is dishonest and destroys client trust when reality arrives.

**Investment principle**: Configuration first. Procurement only if justified. Most value is extracted from existing tools before any new purchase is discussed.

**Governance**: Weekly check-in with named client lead. Monthly steering committee. Hard go/no-go gates at days 30, 90, and 180.

**Modularity**: Every phase can be delivered as an independent, fixed-scope module. See [Modular Engagements](../core/modular-engagements.md) for the standalone engagement menu.

---

## Milestone Deliverables: What You Hold in Your Hands

The three milestone dates — Day 30, Day 90, Day 180 — are not arbitrary progress checkpoints. Each produces a specific, verifiable set of deliverables. A client who stops at Day 30 still holds something of lasting value. A client who reaches Day 180 holds everything below in a form they can operate without us.

### Day 30: Intelligence and Immunity

*Precondition: Brownhat Diagnostic complete, access provisioned by kickoff.*

| # | Deliverable | Verified by |
|---|-------------|-------------|
| 1 | **Brownhat Diagnostic report** — kill chain identified, up to 5 immediate quick wins, prioritised module roadmap | Delivered document |
| 2 | **ASTRAL deployed** — complete M365 tenant configuration snapshot committed to Git; drift detection running; event-driven change probe active | First drift PR visible in ADO |
| 3 | **PULSAR deployed** — all M365 admin audit events ingesting; logs searchable from day 1 forward; 12-month retention accumulating | Oldest log entry confirmed in UI |
| 4 | **T0 accounts hardened** — every Global Admin, Domain Admin, and high-privilege service principal identified; MFA enforced; documented with owner | CA sign-in logs show MFA enforced for T0 accounts |
| 5 | **Public attack surface report** — all internet-facing assets enumerated; P0 findings (internet-exposed + critical CVE) identified and prioritised | Delivered report |
| 6 | **Quick wins closed** — up to 5 immediate improvements from Brownhat findings, using existing tools, zero procurement | Closed items documented in change log |
| 7 | **Findings backlog opened** — all Brownhat Diagnostic findings entered with P0/P1/P2 priority, owner assigned per item, monthly cadence confirmed; this is the input queue for the housekeeping stream | Backlog visible in agreed system; all findings from items 1–6 above entered |

**The Day 30 value**: You know your kill chain. Your M365 configuration is under version control and your audit logs are being retained — permanently, from this day. Your most privileged accounts are hardened. This stands on its own regardless of what follows.

*Day 30 is a hard gate. If ASTRAL and PULSAR are not deployed and T0 accounts are not confirmed as MFA-enforced by day 30, the engagement has a resourcing or access problem that must be resolved before proceeding.*

---

### Day 90: Kill Chain Closed

*Everything from Day 30, plus:*

| # | Deliverable | Verified by |
|---|-------------|-------------|
| 8 | **MFA enforced for all users** — not just enrolled; enforced via Conditional Access policy | CA sign-in logs: zero successful authentications without MFA for in-scope users |
| 9 | **Legacy authentication blocked tenant-wide** | CAExporter export + sign-in logs: zero legacy auth sign-ins in past 7 days |
| 10 | **Conditional Access baseline deployed** — device compliance, sign-in risk, location policies active and tested | CA policy set exported by CAExporter; test sign-in matrix documented |
| 11 | **P0 and P1 vulnerabilities closed** — from Day 30 attack surface report | Rescan confirming closure; residual items in risk register |
| 12 | **AD attack paths reduced** — BloodHound before/after comparison showing measurable reduction in paths to Domain Admin | BloodHound report: path count comparison |
| 13 | **Vendor remote access hardened** — time-bounded, MFA-required, session-recorded for all third-party access | Vendor access log showing new controls enforced |
| 14 | **T0 backup integrity verified** — at least one successful restore per T0 system, timed and documented | Backup test report per T0 system |
| 15 | **ASTRAL: first restore drill** — a rejected drift PR has triggered the restore pipeline; restore validated against a real change | ADO restore pipeline run log |
| 16 | **PULSAR: top 5 alert rules operational** — rules written, test-triggered, runbooks drafted for each | Alert rule set visible; test trigger documented |

**The Day 90 value**: Your kill chain is closed. MFA covers the entire organisation. The highest-risk attack paths are measurably reduced. Any incident from this point has a detection and response capability behind it — and your configuration is auditable back to day 1.

---

### Day 180: Operational Independence

*Everything from Day 90, plus:*

| # | Deliverable | Verified by |
|---|-------------|-------------|
| 17 | **Alert runbooks complete** — documented response procedure for every active PULSAR alert rule; escalation paths defined | Runbook set reviewed and signed off by client IT lead |
| 18 | **Custom detection rules** — at least 3 rules written for client-specific TTPs identified in Phase 1 kill chain | Rules deployed; test-triggered and confirmed |
| 19 | **Client IT lead operational independence** — client IT lead demonstrates ability to: review ASTRAL drift PRs, search PULSAR events, trigger and verify an alert rule | Live walkthrough completed without consultant prompting |
| 20 | **Housekeeping stream running** — 3 consecutive monthly cycles completed; accounts resolved per cycle tracked | Queue status report showing 3 cycles; measurable reduction |
| 21 | **Module completion packages delivered** — every runbook, script, configuration file, and detection rule in client's own repository | Repository contents confirmed; client confirms ownership |
| 22 | **Risk register closure evidence** — before/after comparison for every risk addressed during the programme; residual risks documented | Risk register delivered and reviewed with executive sponsor |
| 23 | **Retained capability scope agreed** — written scope for continuation: cadence, activities, named owner | Signed retained scope or explicit decision to defer |

**The Day 180 value**: You are no longer dependent on us. The systems run, the detections fire, the housekeeping happens on schedule. What continues in the retained scope is enhancement — not maintenance of what we built.

---

### What These Milestones Assume

These deliverables are based on a typical M365-primary environment with:
- A named client lead with 30–40% availability
- Access provisioned before kickoff (accounts, MFA, Global Admin for ASTRAL/PULSAR bootstrap)
- An IT admin who can execute configuration changes with guidance
- Weekly check-ins not cancelled

**What shifts the timeline:**
- Large or complex AD environments add 2–4 weeks to Day 90 work
- High user count (500+) adds 2–4 weeks to MFA rollout change management
- Constrained IT team availability is the single most common cause of slippage — budget for it honestly in the scope
- OT environments: see the [Critical Infrastructure Adaptation](move-fast-and-fix-things.md#the-critical-infrastructure-adaptation); Day 90 timelines for network segmentation work are longer

**What does not shift the Day 30 milestone:** ASTRAL and PULSAR deploy in hours. The Brownhat Diagnostic is 2 half-day workshops. T0 account hardening is 1–2 weeks of focused work. If Day 30 deliverables are not met, the bottleneck is access provisioning or client availability — both of which are addressable before kickoff.

*For the business case and financial justification, see [Business Case Template](business-case-template.md).*
*For board conversation guidance, see [C-Suite Conversation Guide](../core/c-suite-conversation-guide.md).*

---

## For the Practitioner

### What This Plan Is Not

Before using this roadmap with a client, be honest about what it commits to.

**Not a sprint.** The most common failure mode is treating security modernisation as a project that ends. It does not end. The 180-day programme establishes processes and capabilities that must run permanently. If the client does not have the internal resources to continue what we build, we need to have that conversation before we start.

**Not a full audit.** Phase 1 does not produce a complete identity inventory, a comprehensive vulnerability assessment, or an exhaustive compliance gap analysis. It produces a kill chain map and enough visibility to close existential risks. The full audit takes months and tends to produce reports that paralyse rather than mobilise.

**Not compatible with staff paralysis.** Organisations dealing with active incidents, leadership changes, or major concurrent projects cannot execute this plan on the stated timeline. The timeline is predicated on a named client lead with 30–40% availability and access provisioned before day 1.

**Not vendor-agnostic in execution.** The plan references Microsoft 365 environments as the primary context because that is most clients' reality. Non-Microsoft environments follow the same logic but require different specific tools. See the Platform Adaptation appendix in [Modular Engagements](../core/modular-engagements.md).

---

## Phase 1: Visibility (Days 0–60)

**Theme**: *You cannot defend what you cannot see. You cannot fix what you cannot prioritise.*

The first 60 days are about **kill chain mapping and critical visibility** — not about fixing everything. The goal is a clear, ranked picture of what would end the organisation, and initial closure of the most accessible existential gaps.

> **Why 60 days, not 30**: A 30-day identity blitz sounds fast. It is also the fastest path to disabling a service account that runs payroll at 2 AM on Friday. Week 1 is documentation and baseline. Fixes require understanding the environment first. See the engagement model's week 1 discipline — it applies to every phase of this plan.

### Weeks 1–2: Baseline and Kill Chain Mapping

**No changes in week 1.** Document and understand.

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Export current identity state: all accounts, groups, privilege assignments | IAM / Security | Identity inventory — stale, active, privileged, service |
| Run BloodHound collection; run Elysium password audit | Security | AD attack path map; compromised credential list |
| Run CAExporter for Conditional Access documentation | Security | Human-readable CA policy register with gaps highlighted |
| Deploy ASTRAL for M365 configuration baseline | Security | Committed tenant baseline; first drift detection operational |
| Map all public-facing assets | Security | External attack surface register with P0 classification |
| Identify the kill chain: shortest path from "nothing bad" to "organisation fails" | Security Architect | Kill chain document — maximum 2 pages; reviewed with executive sponsor |

### Weeks 3–4: T0 Identity Hardening

Target: privileged accounts only. Not all accounts.

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Force-reset accounts identified as compromised by Elysium (P0) | IAM | Password reset log with verification |
| Enforce MFA on all T0 accounts: Global Admins, Domain Admins, backup admins, service principals with high privilege | IAM | MFA coverage report for T0 accounts |
| Review and disable accounts that are clearly orphaned: departed employees confirmed by HR | IAM | Disable log — only accounts with confirmed ownership resolution |
| Rotate KRBTGT and critical service account passwords | AD | Rotation log; tested without service disruption |
| Review and remove direct Global Admin assignments; move toward PIM or named individual accounts | IAM | Privilege assignment review |

> **What we do not do in weeks 3–4**: We do not attempt to disable all unknown accounts. We do not attempt to resolve all service account ownership. We do not attempt to achieve 100% MFA on all users. These are Phase 2 activities, started after the kill chain is closed and the environment is understood.

### Weeks 5–6: Logging, Perimeter, and Critical Asset Inventory

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Deploy PULSAR for M365 audit log ingestion | Security | Audit events ingested; watermarks established; search operational |
| Enable logging for T0 systems where it is missing | Security | Logging coverage report for T0/T1 assets |
| Audit all vendor and third-party remote access paths | Security / Procurement | Vendor access inventory with remove/restrict list |
| Scan public-facing assets for critical CVEs | Security | Prioritised findings: P0 (internet-facing, critical CVE), P1, P2 |
| Seed CMDB with T0 assets | IT / Security | T0 asset register with ownership, backup status, recovery procedure |
| Validate backup integrity for T0 assets | Backup Admin | Backup test report — at least one successful restore per T0 system |

### Weeks 7–8: Kill Chain Closure and Phase 1 Wrap

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Close P0 vulnerabilities identified in week 5–6 scan | Security | Remediation log with verification |
| Restrict or close the highest-risk vendor access paths | Security / Procurement | Vendor access changes confirmed |
| Implement basic network segmentation between IT and OT (if applicable) | Network / OT | Segmentation policy; validated firewall rules |
| Phase 1 review: re-run BloodHound and Elysium against week 1 baseline | Security | Before/after comparison; revised kill chain assessment |
| Establish findings backlog: all Phase 1 findings entered with priority, owner, target date | IAM / Security | [Findings Backlog](../assessment-templates/findings-backlog.md) populated; named owner; monthly housekeeping cadence confirmed |

### Phase 1 Exit Criteria

- [ ] Kill chain documented and reviewed with executive sponsor
- [ ] T0 accounts: MFA enforced, privilege reviewed, compromised credentials reset
- [ ] P0 vulnerabilities (internet-facing, critical CVE) closed
- [ ] ASTRAL deployed; M365 baseline committed
- [ ] PULSAR deployed; M365 audit logs ingesting
- [ ] T0 asset CMDB complete with backup integrity verified
- [ ] Vendor access inventory complete; highest-risk paths closed
- [ ] Housekeeping stream established: named owner, cadence, populated queue

**What "complete" does not mean at day 60**: All identities validated. All shared accounts eliminated. MFA on 100% of users. Zero legacy protocols. These are legitimate targets — they belong in the housekeeping queue and Phase 2 work, tracked, resourced, and given realistic timescales.

---

## Phase 2: Control (Days 60–120)

**Theme**: *Close the kill chain. Build on what is understood, not what is assumed.*

Phase 2 takes the kill chain map from Phase 1 and systematically closes the structural gaps. The work is less about discovery and more about verified remediation with proper change management.

### Weeks 9–10: MFA and Identity Hardening (Broad Rollout)

Phase 1 hardened T0. Phase 2 extends to all users — with proper change management.

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Enforce MFA on all remote access: not just T0, but all users | IAM | MFA coverage report (% of users) — target 100% enforced, not just enrolled |
| Block legacy authentication protocols tenant-wide | IAM | Legacy auth block confirmed via CAExporter and sign-in log review |
| Deploy Conditional Access baseline: device compliance, location, sign-in risk | IAM | CA policy set deployed and tested; rollback documented |
| Continue housekeeping queue: first monthly cycle | IAM | Accounts resolved this cycle; queue status report |

> **Change management is the constraint here, not technical complexity.** MFA rollout for 500 users requires helpdesk preparation, communication, exception handling, and at minimum two weeks of lead time. Scope this honestly. A rollout that generates 200 support tickets and forces an exception for the CEO because his phone broke is a rollout that gets walked back.

### Weeks 11–12: Attack Surface Reduction

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Deploy Intune compliance policies; enforce device compliance in CA | Endpoint / IAM | Compliance policy set; non-compliant device access blocked |
| Harden admin access: dedicated admin accounts, PAW where feasible | Security | Admin account architecture; PAW deployed for T0 admins |
| Implement ASR rules on all managed endpoints | Endpoint Security | ASR policy deployed; compliance measured |
| Review and remove excessive application permissions (OAuth grants, service principals) | IAM | App permission audit; high-risk grants reviewed and reduced |

### Weeks 13–14: Network Hardening and Vendor Governance

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Implement DNS security: filtering and logging | Network | DNS security coverage report |
| Harden vendor remote access: time-bounded, MFA, session recording | Security / Procurement | Vendor access gateway operational; access policy enforced |
| Patch P1 vulnerabilities from Phase 1 scan | Security | Remediation log; rescan confirming closure |
| Establish change window discipline: all production changes through approved process | IT / Security | Change management process documented and operational |

### Weeks 15–16: Verification and Phase 2 Wrap

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Re-run BloodHound, Elysium, and CAExporter against Phase 1 baseline | Security | Attack path reduction report; before/after metrics |
| Run Purple Knight / E8-CAT against AD and M365 | Security | Security score comparison; residual findings list |
| Review ASTRAL drift log for Phase 1–2 period | Security | Configuration change audit; unauthorised drift incidents |
| Review PULSAR audit log: anomalous events flagged, investigated, resolved | Security | Audit review report |
| Update risk register: what Phase 1–2 closed, what remains open, what Phase 3 addresses | Security | Updated risk register signed off by client lead |
| Housekeeping queue: second monthly cycle | IAM | Queue status; cumulative accounts resolved |

### Phase 2 Exit Criteria

- [ ] MFA enforced for 100% of users (not just enrolled — enforced via CA policy)
- [ ] Legacy authentication blocked tenant-wide
- [ ] CA baseline deployed and tested
- [ ] ASR rules active on all managed endpoints
- [ ] P1 vulnerabilities from Phase 1 scan closed
- [ ] Vendor remote access hardened and inventoried
- [ ] Attack path reduction measurable against Phase 1 BloodHound baseline
- [ ] Housekeeping queue running; two cycles completed

---

## Phase 3: Signal and Retained Capability (Days 120–180)

**Theme**: *Build detection on the hardened foundation. Build the capability to sustain what was built.*

Phase 3 starts only after Phase 2 exit criteria are met. Detection engineering on an unhardened environment is waste — the signal-to-noise ratio is too low to produce actionable intelligence.

> **Why not AI Sovereignty in Phase 3**: AI sovereignty — local models, owned inference infrastructure, sovereign cognitive capability — is a multi-year programme, not a 30-day sprint. Hardware procurement alone typically takes 6–12 weeks. Claiming it as a Phase 3 deliverable sets up the engagement to fail. AI sovereignty begins with the audit work in Phase 1 (AI usage inventory, classification, assessment of vendor terms) and continues as a separate parallel initiative. The Azure OpenAI Sovereignty Bridge is the appropriate near-term stepping stone. See [AI Sovereignty Framework](../core/ai-sovereignty-framework.md) and [Azure OpenAI Sovereignty Bridge](../core/azure-openai-sovereignty-bridge.md).

### Weeks 17–18: Detection Engineering Foundation

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Write initial PULSAR alert rules: CA policy changes, new Global Admin assignments, bulk mailbox export, app permission grants outside change window | Security | Alert rule set deployed; test-triggered and validated |
| Review SIEM coverage: which T0 events generate alerts, which do not | Security | Detection coverage map against MITRE ATT&CK top 10 for M365 |
| Tune ASTRAL rolling PRs: configure reviewer notification, test reject/restore flow | Security | ASTRAL review workflow operational; first restore test completed |
| Establish alert response runbooks: who gets notified, what they do, what they escalate | Security / Client Lead | Runbooks for top 5 alert types |

### Weeks 19–20: Endpoint and Identity Detection

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Deploy Wazuh or verify existing EDR coverage for on-premise systems | Security | Endpoint detection coverage report |
| Write custom detection rules for kill chain-specific TTPs identified in Phase 1 | Security | Custom rule set tuned to client environment |
| Establish weekly threat review cadence: PULSAR event summary + ASTRAL drift review | Security / Client Lead | First weekly review completed; format agreed |
| AI usage audit: classify current AI workflows by data sensitivity and vendor agreement | Security / Legal | AI usage register; high-risk workflows flagged for remediation |

### Weeks 21–24: Knowledge Transfer and Handover

The most important deliverable of Phase 3 is **the client's ability to operate everything without us.**

| Action | Owner | Deliverable |
|--------|-------|-------------|
| Runbook completion: every system built or modified has an operating runbook | Security / Client Team | Runbook set reviewed and signed off by client IT lead |
| Client training: ASTRAL drift review workflow, PULSAR event search, alert response | Security | Training delivered; client IT lead can demonstrate competency |
| Housekeeping queue: third and fourth monthly cycles | IAM | Queue status; cumulative resolution metrics |
| Document what was built: configuration baseline document for every module | Security | Module completion package delivered |
| Phase 3 review: risk register update, metrics summary, Phase 4 / retained capability recommendation | Security | Final 180-day programme review with executive sponsor |

### Phase 3 Exit Criteria

- [ ] PULSAR alert rules operational for top 5 M365 risk scenarios
- [ ] ASTRAL drift review workflow operational; first restore tested
- [ ] Custom detection rules written for client-specific TTPs
- [ ] Weekly threat review cadence established and running
- [ ] All runbooks completed and signed off by client IT lead
- [ ] Client IT lead can operate ASTRAL and PULSAR without consultant support
- [ ] AI usage registered and high-risk workflows flagged
- [ ] Housekeeping queue: four consecutive cycles completed

---

## Phase 4: Antifragility (Ongoing)

**Theme**: *The programme does not end. The organisation learns faster from disruption than competitors do.*

Phase 4 is not a 30-day sprint. It is an ongoing operational posture. The 180-day programme establishes the foundation; Phase 4 is what happens when that foundation is maintained and extended over months and years.

**Phase 4 activities** (initiated at 180 days; sustained indefinitely):

- **Retained capability**: Monthly ASTRAL drift review, PULSAR event summaries, quarterly Elysium/BloodHound scans, housekeeping queue advancement
- **Detection engineering**: Progressive extension of alert rule coverage; tuning based on real events; quarterly rule review
- **Structural improvement**: Exit architectures for vendor dependencies, progressive elimination of legacy systems, planned OT technology refresh
- **Chaos engineering**: Controlled failure exercises — starting with non-production, progressing to production once detection and recovery capability is confirmed
- **Red team exercises**: Annual structured adversarial testing — not before Phase 2 is complete and detection is operational
- **AI sovereignty programme**: Local inference infrastructure, where justified by workload and capability; AURORA deployment for M365 governance intelligence; sovereign AI as a parallel multi-year initiative
- **Greenfield capability building**: Configuration as code for all managed systems; tested migration procedures; documented rebuild path

**What makes Phase 4 real**: A named person who owns the housekeeping queue. A calendar-blocked weekly threat review. A quarterly retained capability scope. Without these, Phase 4 does not happen — and everything built in 180 days begins to rot.

---

## Success Metrics

| Dimension | Metric | Realistic Target |
|-----------|--------|-----------------|
| **Kill chain** | Kill chain nodes closed | 100% of P0 nodes closed by day 120 |
| **Identity** | MFA enforcement on privileged accounts | 100% of T0 accounts by day 60; 100% of all accounts by day 120 |
| **Configuration** | ASTRAL drift detected and reviewed | Weekly; 100% of unauthorised drift investigated within 48h |
| **Audit trail** | PULSAR retention operational | 12+ months of M365 audit events retained by day 60 |
| **Housekeeping** | Stale accounts resolved per quarter | Measurable queue reduction each cycle; not a fixed % target |
| **Recovery** | T0 system recovery test completed | At least one per T0 system within 180 days |
| **Handover** | Client IT lead operational independence | All built systems operable without consultant by day 180 |

> **On metrics and honesty**: Avoid targets that sound like achievements but are not verifiable. "100% of identities validated" cannot be verified in 180 days in any organisation with meaningful history. "All T0 accounts with MFA enforced and verified via CA sign-in logs" is verifiable. Write metrics you can prove, not metrics that sound ambitious.

---

## Governance and Cadence

### Weekly Check-In (30 minutes, every week)

- Change log review: what was completed, what is blocked
- Client decisions required this week
- Risks and open items

*If this meeting is consistently cancelled by the client, the engagement pauses until it resumes.*

### Monthly Steering Committee (60 minutes)

- Phase progress against exit criteria
- Risk register review
- Housekeeping queue status
- Budget and scope review
- Next phase / retained capability planning

### Phase Gate Reviews (Days 60, 120, 180)

Hard go/no-go decisions. Not formalities. If phase exit criteria are not met, the programme does not advance — it addresses the gaps.

---

## Adaptation Guide

### Small Organisations (< 100 employees)

- Phase 1 focus: kill chain, T0 accounts, ASTRAL/PULSAR deployment. Skip broad identity audit — it is not necessary for small populations.
- Phase 2 focus: MFA for all users (achievable quickly at small scale), basic CA, device compliance.
- Phase 3 focus: runbooks and handover. Detection engineering is proportional to environment complexity.
- **Do not compress the timeline further.** The bottleneck at small organisations is almost always IT resource availability and change management, not technical complexity.

### Regulated Industries (Finance, Healthcare, Critical Infrastructure)

- Extend Phase 1 to 90 days where regulatory mapping and OT inventory are required.
- Add compliance validation gates at each phase exit — specific evidence requirements for NIS2/DORA/GDPR.
- The housekeeping stream is non-negotiable for regulators who require demonstrable continuous control.

### Organisations with Heavy Technical Debt

- Accept explicitly, in writing, that 20 years of debt will not be cleared in 180 days.
- Phase 1 focus is kill chain only. The full debt picture goes into the housekeeping queue and the Phase 4 backlog.
- The rapid modernisation plan addresses existential risk. The housekeeping stream addresses accumulated risk over time. Both are necessary; neither replaces the other.
- Adjust Phase 2 exit criteria to reflect the realistic pace of MFA rollout in high-debt environments — legacy systems often require extended exception handling.

### OT/Critical Infrastructure Environments

- Phase 1 must include OT asset inventory and IT/OT connection map.
- Phase 2 segmentation work (IT/OT boundary) is the primary kill chain closure, not identity hardening.
- See [Vertical: Power and Utilities](../reference/vertical-power-utilities.md) and the Critical Infrastructure Adaptation in [Move Fast and Fix Things](move-fast-and-fix-things.md#the-critical-infrastructure-adaptation).

---

*Next: [Implementation Playbook](implementation-playbook.md)*
*Previous: [T0 Asset Framework](../core/t0-asset-framework.md)*