Replace vague 'live where client works' with three ordered options:
Option 1 (default): ADO Work Items
ASTRAL is already in ADO; Work Items are built in, zero additional
tooling. Board setup guidance included. M365 Planner/To Do sync
via ADO connector or Power Automate: non-technical owners see
assigned findings in their daily task list without opening ADO.
ASTRAL integration: link Work Items to drift PRs directly.
Option 2 (upgrade): CISO Assistant
For clients building toward formal GRC. Bridges backlog to risk
register: findings promoted from operational backlog to documented
risks with treatment plans and compliance evidence links. Docker
Compose, self-hosted, 30 minutes to deploy.
Option 3 (fallback): Git flat file
For clients with technical capability and preference for minimal
tooling. Template retained. Limitation noted: no notifications,
no Planner sync - if the IT lead needs nudging, use ADO instead.
Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
New: assessment-templates/findings-backlog.md
Design principles: lives where client works, every finding has an owner,
feeds the housekeeping stream, accumulates from all sources.
Format: 6-field minimal entry (ID, finding, source, priority, owner,
status) with optional target date/effort/notes/closed date.
P0/P1/P2 priority using kill chain test.
Flat file template for Git-based clients.
Population guide: Day 30 (from Brownhat), subsequent modules, continuous
tools (ASTRAL drift, PULSAR alerts, Elysium, BloodHound).
Monthly housekeeping cycle structure.
Relationship to formal risk register explained.
Backlog health indicators (warning signs it is not functioning).
Wired into existing framework:
move-fast-and-fix-things.md: Rule 4 now names the backlog as the queue
rapid-modernisation-plan.md: Day 30 item 7 and Phase 1 action updated
engagement-model.md: Section 4 deliverables table updated at all stages
assessment-templates/README.md: Production-ready templates section added
index.md: Findings Backlog added to Assessment and Tools table
Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
Remove 'Cloud AI vendor price shock' (not a security risk; unverifiable
number) and 'Competitive intelligence loss from AI training' (inaccurate
claim that contradicts corrections made throughout the framework).
Replace with:
- Incident response and forensics (EUR 150-500K, real range)
- Business interruption during recovery (client-specific daily revenue)
All five rows now map directly to risks the programme addresses and
are quantifiable in a CFO conversation.
Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
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>
rapid-modernisation-plan.md:
- Add honest framing section: what 180 days delivers vs. what takes 2-3 years
- Extend Phase 1 from 30 to 60 days; rename to Visibility
- Remove dangerous 'disable all unknown accounts in week 1-2' instruction
- Replace Phase 3 (AI Sovereignty) with Signal and Retained Capability
- Phase 3 now: detection engineering, alert runbooks, knowledge transfer
- Phase 4 made explicitly open-ended (not complete at day 180)
- Fix success metrics: remove unverifiable targets, replace with honest ones
- Remove 'compress Phases 1-2 into 30 days for small orgs' adaptation
- Add 'What This Plan Is Not' practitioner section
- ASTRAL and PULSAR integrated as Phase 1 deliverables
- AI Sovereignty moved to multi-year parallel initiative
business-case-template.md:
- Break-even corrected: Day 90 -> 12-18 months post-programme
- Phase budget table updated: 30/30/30/90 -> 60/60/60/ongoing
- Phase names and deliverables aligned with revised RMP
- AI sovereignty removed from core deliverables
- Sensitivity analysis: 3 scenarios -> 4 including abort condition
- Alternatives table: AI sovereignty removed from Antifragile programme description
- ROI table: cloud AI cost line replaced with audit preparation time saving
- The Ask: 30-day first gate -> 60-day first gate
Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
AOC -> PULSAR across 10 files (engagement-model, retained-capability,
modular-engagements, blue-purple-team-foundation, about-cqre, about-cqre-cs,
consultant-field-guide, ai-assisted-tvm, m365-e3-hardening,
sovereign-tool-stack, risk-register-example).
Training-data framing corrected in:
- executive-summary.md: opening paragraph and risk table
- README.md: 90% solution claim -> 30-60% in 180 days
- modular-engagements.md: public API data use claim
- cis-controls-mapping.md: data protection framing
- antifragile-risk-register.md: risk entry softened to accurate framing
- azure-openai-sovereignty-bridge.md: consumer vs enterprise API distinction
Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
move-fast-and-fix-things.md: 'The Critical Infrastructure Adaptation'
section in Rule 5. OT/NT environments where full greenfield is impossible.
Five-layer adapted stack: IT greenfield protects OT, OT config as code,
manual operation as fallback, compartmentalisation as partial burn,
long-cycle planned refresh. OT greenfield test with 4h/48h/2w targets.
vertical-power-utilities.md: New 'The Controlled Burn Adaptation' section.
Full treatment of when greenfield is not an option. Five-layer OT-adapted
stack. Explicit acceptance statement framework for genuinely irreplaceable
OT components (name, isolate, monitor, plan replacement). The OT greenfield
test. Reference back to Rule 5.
Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
move-fast-and-fix-things.md: Three Rules -> Five Rules.
Rule 4: Housekeeping as a permanent stream (named owner, cadence, queue).
Rule 5: Greenfield capability as standard operational activity every 5 years.
Updated pillar mapping table.
antifragile-manifest.md: Pillar 1 Antifragile Moves: greenfield capability
as the ultimate expression of structural decoupling. Controlled burn framing.
Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
Speed Is a Security Control: Replace overconfident '90% solution today'
with honest target: 30-60% in 180 days. Real comparison is progress vs.
the 0% that stays when waiting for the perfect plan.
New section 'When the Vulnerability Surface Is Effectively Infinite':
AI-scale vulnerability discovery (e.g. Project Glasswing) does not call
for AI-assisted patching. It calls for architecture that makes most
vulnerabilities matter less: kill chain prioritisation, blast radius
limitation, assume-breach posture, known-good baseline. Architecture
beats velocity in the vulnerability race.
Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
Distills philosophical insights from emergent systems thinking into
five enterprise-applicable principles, mapped to the antifragile
manifest pillars. Excludes all anarcho-taoist references.
- New: core/spontaneous-order-principles.md
- Updated: core/antifragile-manifest.md (cross-references)
- Updated: index.md (navigation and document tables)
New section: 'When to Partner Commercially: The Partnership Doctrine'
Addresses the practical reality of a 5-person consultancy growing to
15-20: where open-source wins, where commercial wins, and the decision
framework for choosing between them.
Partnership Decision Framework:
- Capability (24/7 eyes-on-glass = partner)
- Compliance (audit demands vendor logo = partner)
- Scale (>5,000 endpoints = partner)
- Time to value (<30 days = partner)
- Margin (recurring revenue without proportional labour = partner)
- Differentiation (partner makes us generic = refuse)
Tier 1 Strategic Partnerships (deeply integrated):
- Huntress: Managed EDR for 24/7 coverage we cannot staff
- Thinkst Canary: Enterprise deception, high margin, low touch
- Tenable: Compliance-auditable VM for regulated clients
Tier 2 Situational Partnerships (deploy as needed):
- Delinea (PAM), KnowBe4 (awareness), Veeam (backup),
Proofpoint/Mimecast (email gateway)
Tier 3 Consultant Productivity (not resold):
- Burp Suite Pro, Cobalt Strike/Sliver, training
Also documents what we REFUSE to partner with (all-in-one platforms,
generic SIEM, opaque AI startups, M365 management competitors) and
provides a Year 1 vs Year 3 partnership portfolio roadmap.
E3 includes Entra ID P1 (conditional access, SSPR) and Defender for
Endpoint P1 (AV, device control, ASR audit mode), not just 'Free'/'AV only'.
Key corrections:
- m365-e3-hardening.md: Entra ID P1 with conditional access is now
correctly listed as included; Intune is full not 'basic'; ASR audit
mode is available in P1; risk-based gap reframed as 'No Entra ID P2'
- zero-budget-hardening.md: E3 comparison table now shows Entra ID P1
and Defender for Endpoint P1 correctly; pitch text updated
- modular-engagements.md: MFA description now reflects conditional
access availability in E3
- m365-antifragile-project.md: Conditional Access heading now correctly
notes E3 includes P1; E3 baseline mentions conditional access
- endpoint-management-entry-vector.md: Intune described as full MDM/MAM
Claude Sonnet 4.6
tomas.kracmar