cqrenet/antifragile
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Add concrete milestone deliverables at Day 30/90/180

Browse Source 
rapid-modernisation-plan.md: New 'Milestone Deliverables' section with
23 numbered, verifiable deliverables across three milestones.

Day 30 (7 deliverables): Brownhat Diagnostic, ASTRAL deployed, PULSAR
deployed, T0 accounts hardened, attack surface report, quick wins closed,
stale account queue opened. Hard gate: if ASTRAL/PULSAR not deployed,
the bottleneck is access provisioning not scope.

Day 90 (9 more deliverables): MFA for all users enforced (not enrolled),
legacy auth blocked, CA baseline, P0/P1 vulns closed, BloodHound before/
after, vendor access hardened, T0 backup verified, ASTRAL restore drill,
PULSAR top 5 alert rules with runbooks.

Day 180 (7 more deliverables): Alert runbooks, custom detection rules,
client IT lead independence (live walkthrough), housekeeping 3 cycles,
module completion packages, risk register closure evidence, retained scope.

Each milestone includes the verifiable evidence column and a 'what this
value stands alone' statement. Section closes with honest timeline
modifiers (large AD, high user count, OT environments).

business-case-template.md: The Ask updated to quote the three milestones
explicitly.

Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
This commit is contained in:
Claude Sonnet 4.6
2026-06-05 09:54:49 +00:00
parent 878fca3f0b
commit 3b69f255ec
2 changed files with 82 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
antifragile-consulting/playbooks/business-case-template.md
+1 -1
View File
@@ -150,7 +150,7 @@ Present as: *"This program delivers a [X]% return in year one, rising to [Y]% in
**The Ask (Full Programme)**:
> *"We recommend approval of a 180-day antifragile enterprise programme, structured in three 60-day phases with hard go/no-go gates. The initial 60-day investment is €[X] with a defined deliverable: the kill chain documented, T0 accounts hardened, and ASTRAL/PULSAR deployed. If the kill chain is not closed by day 60, the programme stops with no further obligation. The 180-day programme produces a hardened foundation and a client team that can operate it independently — not a complete transformation. What comes after that is a retained capability engagement, scoped separately."*
> *"We recommend approval of a 180-day antifragile enterprise programme with three hard milestones. By Day 30: your kill chain is documented, ASTRAL and PULSAR are live, and your most privileged accounts are hardened. By Day 90: MFA covers the entire organisation, your kill chain is closed, and you have detection capability on M365. By Day 180: your team operates the systems independently, housekeeping is running as a permanent stream, and everything we built is in your repository. That is the 180-day programme. What comes after is a retained scope — scoped separately, renewed quarterly."*
**The Ask (Modular Alternative)**:
antifragile-consulting/playbooks/rapid-modernisation-plan.md
+81 -1
View File
@@ -19,10 +19,90 @@ This is not a three-year digital transformation. It is a **180-day foundation pr
**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 60, 120, and 180.
**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 | **Stale account queue opened** — full list of candidates generated and prioritised; named owner and monthly cadence confirmed | Queue visible in agreed tracking system |
**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).*