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 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; 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. For board conversation guidance, see C-Suite Conversation Guide.

---

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.

---

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 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 and Azure OpenAI Sovereignty Bridge.

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 and the Critical Infrastructure Adaptation in Move Fast and Fix Things.

---

Next: Implementation Playbook Previous: T0 Asset Framework