feat: Add engagement model, consultant field guide, deliverable templates, CQRE tools integration, and Czech localization

New documents:
- core/engagement-model.md: Full client-facing engagement lifecycle (Sections 1-6) plus consultant delivery discipline (Section 7)
- core/consultant-field-guide.md: Decision models, client qualification, module selection, 10 common mistakes, technical onboarding, proposal writing
- core/about-cqre.md: Company overview template with [PLACEHOLDER] markers for client-facing use
- core/about-cqre-cs.md: Czech version of company overview (O společnosti CQRE)
- core/executive-summary-cs.md: Czech translation of the board executive summary
- assessment-templates/nist-csf-baseline.md: Full Brownhat Diagnostic workshop methodology (NIST CSF 2.0)
- assessment-templates/nist-csf-baseline-cs.md: Czech version of Brownhat Diagnostic (for Czech-language workshops)
- assessment-templates/module-completion-report.md: Module completion package template
- assessment-templates/risk-register-example.md: 8 fully populated risk entries (Meridian Logistics GmbH fictional engagement)
- playbooks/privileged-access-architecture.md: Module 13 - Teleport, Tailscale/Headscale, JIT access, vendor governance
- playbooks/sovereign-communications.md: Module 14 - Delta Chat chatmail relay, Matrix/Element, crisis channels

Updated documents:
- playbooks/sovereign-tool-stack.md: Added Elysium, CAExporter, E8-CAT, macOS_IntuneManagement, IntunePolicyParser, M365-Scripts; updated capability matrix and module pairings
- core/modular-engagements.md: Module 2 now includes CAExporter as first step; Module 6 includes Elysium password audit
- reference/nist-csf-mapping.md: Added back-reference to nist-csf-baseline.md
- assessment-templates/README.md: Changed Q1/Q2/Q3/Q4 to Phase 1/2/3/4, added Status column
- index.md: Registered all new documents; restructured consultant navigation into three labeled groups (1-25)
- README.md: Updated directory tree; updated Quick Start for Consultants

Czech localization pointers:
- executive-summary.md: Added Česká verze pointer
- nist-csf-baseline.md: Added Česká verze pointer
- engagement-model.md: Added note that client-facing Czech translation is planned

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

antifragile-consulting/core/about-cqre-cs.md

@@ -0,0 +1,228 @@
+# O společnosti CQRE · Brownhat
+
+> *Tato stránka představuje CQRE a metodiku Brownhat novým klientům a novým členům týmu. Vyplňte každou sekci označenou `[PLACEHOLDER]` konkrétními, pravdivými informacemi. Vyhýbejte se obecnému konzultantskému jazyku — klienti to poznají. Sekce označené **INTERNÍ POZNÁMKA** obsahují pokyny pro doplnění šablony; před sdílením navenek je odstraňte.*
+>
+> *Anglická verze tohoto dokumentu je k dispozici zde: [About CQRE](about-cqre.md).*
+
+---
+
+## Kdo jsme
+
+**CQRE.NET Ltd** je specializovaná konzultační společnost v oblasti kybernetické bezpečnosti registrovaná v [PLACEHOLDER: Velká Británie / Edinburgh]. Primárně působíme z [PLACEHOLDER: Praha, Česká republika] a pracujeme s klienty po celé [PLACEHOLDER: střední Evropě, Velké Británii a západní Evropě].
+
+> **INTERNÍ POZNÁMKA** — Doporučené zpracování: omezte tento odstavec na 3–5 vět. Uveďte rok založení, geografické zaměření a rozsah klientů (odvětví, velikosti). Neslibujte schopnosti, které momentálně nemůžete poskytnout. Příklad: *„CQRE.NET Ltd byla založena v [roce] [jménem] s cílem poskytovat poctivé, metodologicky řízené poradenství v oblasti bezpečnosti organizacím, které přerostly generické rady. Pracujeme primárně se středně velkými společnostmi, telekomunikačními operátory a energetickými podniky ve střední Evropě — organizacemi se skutečnými prostředími, stávajícími investicemi a konkrétními hrozbami, na které generické rámce nestačí."*
+
+[PLACEHOLDER: popis společnosti v 3–5 větách]
+
+Vůči klientům vystupujeme pod značkou **Brownhat** — název odráží naši základní filozofii: pracujeme v brownfield prostředích (zavedených, obydlených, nesoucích tíhu minulých rozhodnutí) a naším úkolem je kultivovat to, co existuje, dříve než cokoliv doporučíme koupit.
+
+---
+
+## Co děláme
+
+Pomáháme organizacím překlenout propast mezi jejich investicemi do bezpečnosti a jejich skutečnou bezpečnostní pozicí. V praxi to znamená:
+
+- Auditovat to, co existuje, upřímně — nikoli to, co říkají politiky
+- Maximalizovat hodnotu nástrojů a licencí, za které již bylo zaplaceno
+- Uzavřít útočný řetězec — konkrétní sled selhání, který by mohl ukončit podnikání — dříve než cokoliv jiného
+- Budovat interní kompetence u klienta, nikoli závislost na nás
+
+Každý angažmá začíná **Brownhat Diagnostikou** — strukturovaným dvoudenním hodnocením, které přinese upřímný obraz situace organizace a toho, co je nejdůležitější napravit. Neposkytujeme doporučení, dokud nerozumíme prostředí.
+
+*Celý přehled služeb naleznete v [Modular Engagements](modular-engagements.md).*
+
+---
+
+## Jak přemýšlíme
+
+Pět principů formuje každé naše doporučení:
+
+| Princip | Co to znamená v praxi |
+|---------|----------------------|
+| **Strukturální oddělení** | Identifikujeme a odstraňujeme skryté závislosti dříve, než se stanou fatálními. Nepřidáváme složitost, která by vytvářela nové závislosti. |
+| **Zachování opcí** | Investujeme váš rozpočet do věcí, které zachovávají vaši schopnost změnit směr. Každý zbytečný nákup nástroje snižuje vaši strategickou flexibilitu. |
+| **Přeměna stresu na signál** | Každý incident, selhání a téměř-miss jsou zpravodajství. Budujeme systémy, které se z narušení učí, místo aby ho jen přežily. |
+| **Svrchované zpravodajství** | Vaše proprietární data by měla zlepšovat vaše vlastní schopnosti, nikoli modely dodavatele. Budujeme nástroje a systémy, které vlastníte a umíte provozovat. |
+| **Design asymetrického výnosu** | Malé, cílené investice do existenčních rizik přinášejí nepřiměřenou ochranu. Nikdy nerozptylujeme úsilí rovnoměrně — soustřeďujeme ho tam, kde by selhání bylo fatální. |
+
+*Plný filozofický základ naleznete v [The Antifragile Manifest](antifragile-manifest.md).*
+
+---
+
+## Čím se lišíme
+
+> **INTERNÍ POZNÁMKA** — Tato sekce popisuje upřímnou konkurenční diferenciaci. Buďte konkrétní. Vyhýbejte se obecným konzultantským tvrzením („jsme zaměřeni na klienta", „přinášíme hodnotu"). Pojmenujte, co skutečně děláte jinak, a buďte připraveni to dokázat. Šest bodů níže jsou doporučené výchozí body — upravte je tak, aby odrážely vaši skutečnou diferenciaci.
+
+**1. Začínáme tím, co vlastníte.**
+
+Většina konzultantů přichází se seznamem produktů. My přicházíme s diagnostikou. Dříve než se mluví o jakémkoliv nákupu, vyčerpáme schopnosti stávajících nástrojů. Pokud váš tenant Microsoft E3 dokáže mezeru uzavřít, nakonfigurujeme ho. Naše honoráře jsou odměnou za odbornost, nikoli za marže na licencích.
+
+**2. Cenu stanovujeme za výstup, nikoli za hodinu.**
+
+Každý angažmá má definovaný rozsah a definovaný výstup před zahájením práce. Víte přesně, za co platíte. Víte přesně, co budete držet v rukách na konci. Neexistují otevřené smlouvy maskované jako „průběžná podpora".
+
+**3. Vše, co vybudujeme, vám patří.**
+
+Každý skript, pravidlo detekce, konfigurace a runbook vzniklý během angažmá je předán do vašeho vlastního repozitáře. Nenecháváme ve vašem prostředí běžet proprietární nástroje. Za retenčním poplatkem neschovávejme vaši vlastní dokumentaci. Po ukončení angažmá jste provozně nezávislí.
+
+**4. Zveřejňujeme naše obchodní vztahy.**
+
+Máme obchodní partnerství s Huntress, Tailscale, Thinkst Canary a Tenable. Pokud doporučujeme jeden z těchto nástrojů, řekneme to a vysvětlíme, proč open-source alternativa neodpovídá vašim konkrétním potřebám. Nedoporučujeme nástroje kvůli maržím.
+
+**5. Říkáme vám, co neumíme.**
+
+Jsme malá, specializovaná praxe. Neprovozujeme 24/7 operační centrum. Nepodepisujeme compliance audity. Nenahradzujeme váš IT tým. Pracujeme po boku vašich lidí, budujeme kompetence uvnitř vaší organizace a odcházíme. Pokud potřeba přesahuje naši praxi, řekneme to a ukážeme na správného poskytovatele.
+
+**6. [PLACEHOLDER: Vaše šestá diferenciace]**
+
+> **INTERNÍ POZNÁMKA** — Přidejte diferenciaci specifickou pro vaši praxi. Příklady: hluboká odbornost v konkrétním odvětví (OT/energie, české regulatorní prostředí); proprietární nástroje (ASTRAL, AOC, Elysium); jazykové schopnosti; specifické certifikace; metodologický přístup.
+
+[PLACEHOLDER: konkrétní diferenciace s jedním konkrétním příkladem nebo důkazem]
+
+---
+
+## Tým
+
+> **INTERNÍ POZNÁMKA** — Buďte upřímní a konkrétní. Neuvádějte certifikace, které jste si neudrželi, ani odbornost, kterou nemůžete prokázat v praxi. Jeden odstavec na osobu je dostačující. Pokud je tým malý, vlastněte to — „Jsme specializovaná praxe [N] konzultantů" je silnější výrok než snaha naznačit rozsah, který nemáte.
+
+### [PLACEHOLDER: Jméno, role]
+
+[PLACEHOLDER: bio v 2–3 větách. Zahrňte relevantní zkušenosti, certifikace a konkrétní odbornost, kterou tato osoba přináší do angažmá. Např.: „15 let v podnikové bezpečnosti ve finančních službách a kritické infrastruktuře. OSCP, CISSP. Hluboká odbornost v architektuře Active Directory a bezpečnosti Microsoft 365. Hlavní konzultant pro všechna hardening a blue/purple team angažmá."]
+
+### [PLACEHOLDER: Jméno, role — opakujte dle potřeby]
+
+[PLACEHOLDER: bio]
+
+**Certifikace, které tým drží** (k [PLACEHOLDER: datum]):
+
+[PLACEHOLDER: seznam relevantních certifikací — např. OSCP, CISSP, CEH, AZ-500, SC-200 atd.]
+
+---
+
+## Naši klienti
+
+> **INTERNÍ POZNÁMKA** — Buďte konkrétní, aniž byste jmenovali klienty, kteří nedali souhlas. Odvětvové archetypy jsou v pořádku; konkrétní názvy organizací vyžadují souhlas. Formulace „jak vypadají naši typičtí klienti" je upřímná a nevyžaduje zveřejnění.
+
+Pracujeme primárně s:
+
+- **[PLACEHOLDER: odvětví/archetyp]** — [jedna věta popisující, jak tito klienti vypadají a co je k nám přivádí]
+- **[PLACEHOLDER: odvětví/archetyp]** — [popis]
+- **[PLACEHOLDER: odvětví/archetyp]** — [popis]
+
+**Co naši klienti mají společného**: Léta budují a provozují IT infrastrukturu. Nahromadili technický dluh, částečně nasazené nástroje a bezpečnostní mezery, o nichž vědí, ale na systematické řešení nikdy neměli prostředky. Nepotřebují novou platformu — potřebují, aby to, co mají, fungovalo správně.
+
+---
+
+## Vybrané práce
+
+> **INTERNÍ POZNÁMKA** — Anonymizované případové studie jsou věrohodnější než loga klientů. Používejte konzistentní strukturu: odvětví/velikost + problém + co jsme udělali + konkrétní výsledek. Tři příklady stačí. Nevymýšlejte výsledky ani nepřeceňujte rozsah.
+
+### [PLACEHOLDER: Odvětví a velikost, např. „Středně velká logistická společnost, 300 zaměstnanců"]
+
+**Situace**: [PLACEHOLDER: 1–2 věty popisující situaci klienta a podnět k angažmá]
+
+**Co jsme udělali**: [PLACEHOLDER: 1–2 věty o konkrétních modulech nebo provedené práci]
+
+**Výsledek**: [PLACEHOLDER: konkrétní, měřitelný výsledek. Např.: „Počet útočných cest BloodHound k Domain Admin snížen z 4 217 na 23. Skóre PingCastle zlepšeno z 52 na 81. KRBTGT rotováno poprvé za 843 dní."]
+
+---
+
+### [PLACEHOLDER: Odvětví a velikost]
+
+**Situace**: [PLACEHOLDER]
+
+**Co jsme udělali**: [PLACEHOLDER]
+
+**Výsledek**: [PLACEHOLDER]
+
+---
+
+### [PLACEHOLDER: Odvětví a velikost]
+
+**Situace**: [PLACEHOLDER]
+
+**Co jsme udělali**: [PLACEHOLDER]
+
+**Výsledek**: [PLACEHOLDER]
+
+---
+
+## Partnerství a akreditace
+
+> **INTERNÍ POZNÁMKA** — Uvádějte pouze aktivní partnerství a aktuální akreditace. Zaniklé certifikace nebo partnerství, kde nemáte formální dohodu, by se zde neměly objevit.
+
+**Obchodní partnerství** (nástroje, které lze zakoupit a spravovat jménem klientů):
+
+| Partner | Co poskytují | Kdy je doporučujeme |
+|---------|-------------|---------------------|
+| [PLACEHOLDER: např. Huntress] | [PLACEHOLDER: např. Managed EDR, 24/7 threat hunting] | [PLACEHOLDER: např. Klienti bez Defender P2, kteří potřebují 24/7 pokrytí endpointů] |
+| [PLACEHOLDER] | | |
+
+**Akreditace a registrace**:
+
+[PLACEHOLDER: registrační čísla společnosti, relevantní akreditace, členství v profesních organizacích, pojištění kybernetické bezpečnosti atd.]
+
+---
+
+## Co neděláme
+
+> **INTERNÍ POZNÁMKA** — Tato sekce nastavuje upřímná očekávání. Klient, který zjistí „to neděláme" v průběhu angažmá, je nespokojený klient. Je lepší to říct zde.
+
+**Neprovozujeme 24/7 operační centrum.** Nasazujeme, konfigurujeme a zprovozňujeme monitorovací nástroje. Pro nepřetržitou řízenou odezvu spolupracujeme s obchodními partnery (Huntress, Thinkst Canary) nebo pomáháme klientům budovat interní schopnost.
+
+**Nepodepisujeme compliance audity.** Připravujeme klienty na audity — mapujeme kontroly, budujeme balíčky důkazů a uzavíráme mezery. Auditní stanovisko náleží kvalifikovanému auditorovi, kterého vyžaduje váš regulátor.
+
+**Nenahradzujeme váš IT tým.** Pracujeme po boku vašich lidí. Předávání znalostí je součástí každého angažmá. Když odcházíme, váš tým musí být schopen provozovat to, co jsme vybudovali.
+
+**Neprodáváme nástroje, které bychom sami nepoužili.** Každé obchodní doporučení je zveřejněno a vysvětleno. Pokud open-source alternativa splňuje vaše potřeby, nasadíme ji místo komerčního řešení.
+
+**[PLACEHOLDER: páté omezení — co neberete]** [PLACEHOLDER: pokud existují konkrétní oblasti, které odmítáte — konkrétní odvětví, regulatorní režimy, geografie — uveďte je zde. Příklad: „Momentálně nepřebíráme klienty vyžadující certifikaci SOC 2 Type II."]
+
+---
+
+## Jak začít spolupráci
+
+**Výchozím bodem** pro každého nového klienta je Brownhat Diagnostika — dvoudenní strukturované hodnocení, které přinese prioritizovaný obraz vaší bezpečnostní pozice a doporučené pořadí modulů. Jde o placené, ohraničené angažmá, které přináší hodnotu bez ohledu na to, zda bude následovat další práce.
+
+*Plnou metodiku diagnostiky naleznete v [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md).*
+
+**Pro zahájení rozhovoru**:
+
+| | |
+|-|-|
+| **E-mail** | [PLACEHOLDER: primární kontaktní e-mail] |
+| **Web** | [PLACEHOLDER: adresa webu] |
+| **Jazyky** | [PLACEHOLDER: např. čeština, angličtina, slovenština] |
+| **Geografie** | [PLACEHOLDER: např. Česká republika, Slovensko, Velká Británie; vzdálená angažmá po celé EU] |
+| **Doba odezvy** | [PLACEHOLDER: např. Počáteční odpověď do 1 pracovního dne] |
+
+**Shrnutí obchodních podmínek**:
+
+- Angažmá jsou s pevně daným rozsahem a pevnou cenou; výstupy jsou dohodnuty písemně před zahájením práce
+- Platba: [PLACEHOLDER: např. 50 % při zahájení, 50 % při dokončení]
+- Měna: [PLACEHOLDER: CZK / EUR / GBP]
+- Smlouvy se řídí: [PLACEHOLDER: český zákon / anglické právo]
+- [PLACEHOLDER: další standardní obchodní podmínky, které stojí za to uvést předem]
+
+---
+
+## In English
+
+> *This page is also available in English: [About CQRE](about-cqre.md).*
+
+---
+
+## Integrace se stávajícími dokumenty
+
+| Dokument | Integrace |
+|----------|-----------|
+| [Engagement Model](engagement-model.md) | Plný životní cyklus angažmá, cenový model a požadavky na klienty zmíněné v tomto dokumentu |
+| [Modular Engagements](modular-engagements.md) | Kompletní přehled služeb |
+| [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) | Brownhat Diagnostika popsaná v sekci „Jak začít spolupráci" |
+| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | Přesvědčovací skripty pro executive konverzace |
+| [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) | Nástroje a partnerství zmíněná v tomto dokumentu |
+
+---
+
+*Pro popis angažmá viz [Engagement Model](engagement-model.md).*
+*Pro přehled služeb viz [Modular Engagements](modular-engagements.md).*

antifragile-consulting/core/about-cqre.md

@@ -0,0 +1,228 @@
+# About CQRE · Brownhat
+
+> *This document introduces CQRE and the Brownhat methodology to new clients and new team members. Fill every `[PLACEHOLDER]` section with specific, honest information. Avoid generic consulting language — clients can tell. The sections marked **INTERNAL NOTE** contain guidance for completing the template; remove them before sharing externally.*
+>
+> *A Czech-language version of this document is maintained at [about-cqre-cs.md](about-cqre-cs.md).*
+
+---
+
+## Who We Are
+
+**CQRE.NET Ltd** is a specialist cybersecurity consultancy registered in [PLACEHOLDER: United Kingdom / Edinburgh]. We operate primarily from [PLACEHOLDER: Prague, Czech Republic] and work with clients across [PLACEHOLDER: Central Europe, the UK, and Western Europe].
+
+> **INTERNAL NOTE** — Suggested framing: keep this paragraph to 3–5 sentences. Include founding year, geographic base, and the range of clients you work with (industries, sizes). Do not claim capabilities you cannot currently deliver. Example: *"CQRE.NET Ltd was founded in [year] by [name] to provide honest, methodology-driven security consulting to organisations that have outgrown generic advice. We work primarily with mid-market companies, telcos, and utilities across Central Europe — organisations with real environments, existing investments, and specific threats that generic frameworks do not address."*
+
+[PLACEHOLDER: 3–5 sentence company description]
+
+We operate under the **Brownhat** brand when engaging clients — a name that reflects our core philosophy: we work in brownfield environments (built up, lived in, carrying the weight of past decisions) and our job is to recultivate what exists before recommending anything new.
+
+---
+
+## What We Do
+
+We help organisations close the gaps between their security investments and their actual security posture. In practice, this means:
+
+- Auditing what exists, honestly — not what the policies say should exist
+- Maximising the value of tools and licences already paid for
+- Closing the kill chain — the specific sequence of failures that would end the business — before anything else
+- Building retained capability inside client organisations, not dependencies on us
+
+Every engagement begins with the **Brownhat Diagnostic** — a structured two-day assessment that produces an honest picture of where the organisation stands and what matters most to fix. We do not make recommendations before we understand the environment.
+
+*For the full service menu, see [Modular Engagements](modular-engagements.md).*
+
+---
+
+## How We Think
+
+Five principles shape every recommendation we make:
+
+| Principle | What it means in practice |
+|-----------|--------------------------|
+| **Structural Decoupling** | We identify and remove hidden dependencies before they become fatal. We do not add complexity that creates new ones. |
+| **Optionality Preservation** | We spend your budget on things that preserve your ability to change direction. Every unnecessary tool purchase reduces your strategic flexibility. |
+| **Stress-to-Signal Conversion** | Every incident, failure, and near-miss is intelligence. We build systems that learn from disruption rather than merely surviving it. |
+| **Sovereign Intelligence** | Your proprietary data should improve your own capability, not a vendor's model. We build tools and systems you own and can operate. |
+| **Asymmetric Payoff Design** | Small, targeted investments on existential risks yield disproportionate protection. We never distribute effort evenly — we concentrate it where failure is fatal. |
+
+*For the full philosophical foundation, see [The Antifragile Manifest](antifragile-manifest.md).*
+
+---
+
+## What Makes Us Different
+
+> **INTERNAL NOTE** — This section is the honest competitive differentiation. Be specific. Avoid generic consulting claims ("we are client-focused," "we deliver value"). Name what you actually do differently and be prepared to prove it. The six points below are suggested starting points — edit to reflect your actual differentiation.
+
+**1. We start with what you own.**
+
+Most consultants arrive with a shortlist of products. We arrive with a diagnostic. Before any purchase is discussed, we exhaust the capabilities of existing tools. If your Microsoft E3 tenant can close the gap, we configure it. We earn our fees from expertise, not licence margins.
+
+**2. We price by deliverable, not by the hour.**
+
+Every engagement has a defined scope and a defined deliverable before work begins. You know exactly what you are paying for. You know exactly what you will hold at the end. There are no open-ended retainers disguised as "ongoing support."
+
+**3. Everything we build belongs to you.**
+
+Every script, detection rule, configuration, and runbook produced during an engagement is delivered to your own repository. We do not leave proprietary tools running in your environment. We do not hold your own documentation behind a retainer. When an engagement closes, you are operationally independent.
+
+**4. We disclose our commercial relationships.**
+
+We have commercial partnerships with Huntress, Tailscale, Thinkst Canary, and Tenable. When we recommend one of these tools, we say so and explain why the open-source alternative does not meet your specific need. We do not recommend tools because of margin.
+
+**5. We tell you what we cannot do.**
+
+We are a small, specialist practice. We do not run a 24/7 SOC. We do not sign off on compliance audits. We do not replace your IT team. We work alongside your people, build capability inside your organisation, and leave. If a need falls outside our practice, we say so and point you to the right provider.
+
+**6. [PLACEHOLDER: Your sixth differentiator]**
+
+> **INTERNAL NOTE** — Add a differentiator specific to your practice. Examples: deep expertise in a specific vertical (OT/utilities, Czech regulatory environment); proprietary tools (ASTRAL, AOC, Elysium); language capability; specific certifications; methodology approach.
+
+[PLACEHOLDER: specific differentiator with one concrete example or proof point]
+
+---
+
+## The Team
+
+> **INTERNAL NOTE** — Keep this honest and specific. Do not list certifications you have not maintained or expertise you cannot demonstrate in an engagement. A one-paragraph bio per person is sufficient. If the team is small, own it — "We are a specialist practice of [N] consultants" is a stronger statement than trying to imply scale you do not have.
+
+### [PLACEHOLDER: Name, role]
+
+[PLACEHOLDER: 2–3 sentence bio. Include relevant background, certifications, and the specific expertise this person brings to engagements. E.g., "15 years in enterprise security across financial services and critical infrastructure. OSCP, CISSP. Deep expertise in Active Directory architecture and Microsoft 365 security. Lead consultant for all AD hardening and blue/purple team engagements."]
+
+### [PLACEHOLDER: Name, role — repeat as needed]
+
+[PLACEHOLDER: Bio]
+
+**Certifications held by the team** (as of [PLACEHOLDER: date]):
+
+[PLACEHOLDER: list relevant certifications — e.g., OSCP, CISSP, CEH, AZ-500, SC-200, etc.]
+
+---
+
+## Our Clients
+
+> **INTERNAL NOTE** — Be specific without naming clients who have not given permission. Industry archetypes are fine; specific organisation names require consent. The "what our clients typically look like" framing is honest and does not require disclosure.
+
+We work primarily with:
+
+- **[PLACEHOLDER: industry/archetype]** — [one sentence description of what these clients typically look like and what brings them to us]
+- **[PLACEHOLDER: industry/archetype]** — [description]
+- **[PLACEHOLDER: industry/archetype]** — [description]
+
+**What our clients typically have in common**: They have been building and running IT infrastructure for years. They have accumulated technical debt, partially deployed tools, and security gaps they know exist but have not had the resources to address systematically. They do not need a new platform — they need someone to make what they have work properly.
+
+---
+
+## Selected Work
+
+> **INTERNAL NOTE** — Anonymised case studies are more credible than logo walls. Use a consistent structure: industry/size + problem + what we did + specific outcome. Three examples are enough. Do not fabricate outcomes or exaggerate scope.
+
+### [PLACEHOLDER: Industry and size, e.g., "Mid-market logistics company, 300 employees"]
+
+**Situation**: [PLACEHOLDER: 1–2 sentences describing the client situation and the trigger for engagement]
+
+**What we did**: [PLACEHOLDER: 1–2 sentences on the specific modules or work performed]
+
+**Outcome**: [PLACEHOLDER: specific, measurable result. E.g., "BloodHound attack paths to Domain Admin reduced from 4,217 to 23. PingCastle score improved from 52 to 81. KRBTGT rotated for the first time in 843 days."]
+
+---
+
+### [PLACEHOLDER: Industry and size]
+
+**Situation**: [PLACEHOLDER]
+
+**What we did**: [PLACEHOLDER]
+
+**Outcome**: [PLACEHOLDER]
+
+---
+
+### [PLACEHOLDER: Industry and size]
+
+**Situation**: [PLACEHOLDER]
+
+**What we did**: [PLACEHOLDER]
+
+**Outcome**: [PLACEHOLDER]
+
+---
+
+## Partnerships and Accreditations
+
+> **INTERNAL NOTE** — Only list active partnerships and current accreditations. Lapsed certifications or partnerships where you have no formal agreement should not appear here.
+
+**Commercial partnerships** (tools we can procure and manage on behalf of clients):
+
+| Partner | What they provide | When we recommend them |
+|---------|------------------|----------------------|
+| [PLACEHOLDER: e.g., Huntress] | [PLACEHOLDER: e.g., Managed EDR, 24/7 threat hunting] | [PLACEHOLDER: e.g., Clients without Defender P2 who need 24/7 endpoint coverage] |
+| [PLACEHOLDER] | | |
+
+**Accreditations and registrations**:
+
+[PLACEHOLDER: company registration numbers, relevant accreditations, professional memberships, cyber insurance, etc.]
+
+---
+
+## What We Do Not Do
+
+> **INTERNAL NOTE** — This section sets honest expectations. A client who discovers a "we don't do that" during an engagement is a dissatisfied client. Better to say it here.
+
+**We do not run a 24/7 operations centre.** We deploy, configure, and enable monitoring tools. For round-the-clock managed response, we work with commercial partners (Huntress, Thinkst Canary) or help clients build internal capability.
+
+**We do not sign off on compliance audits.** We prepare clients for audits — mapping controls, building evidence packages, and closing gaps. The audit opinion belongs to the qualified auditor your regulator requires.
+
+**We do not replace your IT team.** We work alongside your people. Knowledge transfer is part of every engagement. When we leave, your team must be able to operate what we built.
+
+**We do not resell tools we would not use ourselves.** Every commercial recommendation is disclosed and explained. If an open-source alternative meets your need, we deploy that instead.
+
+**We do not take engagements outside our competence.** [PLACEHOLDER: if there are specific areas you decline — e.g., specific industries, specific regulatory regimes, specific geographies — state them here. "We do not currently take on clients requiring SOC 2 Type II certification" or similar.]
+
+---
+
+## How to Engage
+
+**The starting point** for every new client is the Brownhat Diagnostic — a two-day structured assessment that produces a prioritised picture of your security posture and a recommended module sequence. It is a paid, bounded engagement that delivers value regardless of whether any further work follows.
+
+*For the full diagnostic methodology, see [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md).*
+
+**To start a conversation**:
+
+| | |
+|-|-|
+| **Email** | [PLACEHOLDER: primary contact email] |
+| **Web** | [PLACEHOLDER: website URL] |
+| **Languages** | [PLACEHOLDER: e.g., Czech, English, Slovak] |
+| **Geography** | [PLACEHOLDER: e.g., Czech Republic, Slovakia, UK; remote engagements across EU] |
+| **Response time** | [PLACEHOLDER: e.g., Initial response within 1 business day] |
+
+**Commercial terms summary**:
+
+- Engagements are fixed-scope, fixed-price, with deliverables agreed in writing before work begins
+- Payment: [PLACEHOLDER: e.g., 50% at kickoff, 50% at completion]
+- Currency: [PLACEHOLDER: CZK / EUR / GBP]
+- Contracts governed by: [PLACEHOLDER: Czech law / English law]
+- [PLACEHOLDER: any other standard commercial terms worth stating upfront]
+
+---
+
+## In Czech
+
+> *Tato stránka je k dispozici také v češtině: [O společnosti CQRE](about-cqre-cs.md).*
+
+---
+
+## Integration With Existing Frameworks
+
+| Document | Integration |
+|----------|-------------|
+| [Engagement Model](engagement-model.md) | The full engagement lifecycle, pricing model, and client requirements referenced in this document |
+| [Modular Engagements](modular-engagements.md) | The complete service menu |
+| [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic described in the "How to Engage" section |
+| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | Client-facing persuasion scripts for executive conversations |
+| [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) | The tools and partnerships referenced in this document |
+
+---
+
+*For the engagement process, see [Engagement Model](engagement-model.md).*
+*For the full service menu, see [Modular Engagements](modular-engagements.md).*

antifragile-consulting/core/antifragile-manifest.md

@@ -21,7 +21,9 @@ This is not a security framework. It is a **strategic operating philosophy** for
 
 ## For the Practitioner
 
-This manifest defines the five foundational pillars of an antifragile enterprise. It is not a security framework. It is a **strategic operating philosophy** for organizations that intend to outlast their competitors, their regulators, and their own assumptions.
+This manifest defines the five foundational pillars of an antifragile enterprise. Each pillar describes both a principle and a set of concrete moves. The philosophy is platform-agnostic—these pillars apply whether your client runs Microsoft 365, Google Workspace, AWS, on-premise Linux, or a hybrid OT environment.
+
+Your job as a consultant is to translate each pillar into the specific context of the client. The language should shift (a CISO hears "Stress-to-Signal Conversion" differently than a CFO does), but the underlying logic does not.
 
 For the reasoning *why* these pillars work—drawn from natural systems, distributed networks, and emergent order—see [Spontaneous Order Principles](spontaneous-order-principles.md).
 

antifragile-consulting/core/consultant-field-guide.md

@@ -0,0 +1,372 @@
+# Consultant Field Guide
+
+> *"The philosophy tells you what to value. This document tells you how to make the call when two things you value are in conflict."*
+
+This document is the internal complement to the [Engagement Model](engagement-model.md). The engagement model covers the mechanics of delivery: how engagements are structured, scoped, priced, and handed over. This document covers the thinking behind the work — the mental models, the qualification filters, the prioritisation logic, the failure patterns, and the technical onboarding path.
+
+Read the [Engagement Model](engagement-model.md) first. Then read this.
+
+---
+
+## Part 1: How We Make Decisions
+
+Five types of decisions arise in every engagement. The philosophy documents describe what to value. This section describes how to make the call in practice.
+
+---
+
+### Decision Type 1: Prioritisation
+
+**The question**: Which of the client's ten problems do we fix first?
+
+**The mental model**: The kill chain test.
+
+Ask: *"If this is not fixed and an adversary exploits it, does the organisation fail to operate?"*
+
+- **Yes** → P0. Fix before anything else. Do not leave until it is closed or mitigated.
+- **No, but material damage results** → P1. Close within the engagement.
+- **No** → P2. Document it, put it in the risk register, schedule it for a later module.
+
+P0 examples: Domain admins logging in from email/browsing workstations. Backups that have never been restored. Internet-facing systems with unpatched critical CVEs. MFA not enforced on any account.
+
+The most common prioritisation failure: treating forty findings as equally important because they all appeared in the same scan output. A client who fixes a P2 before their P0 has been made less safe, not more. Rank everything. Communicate the ranking loudly.
+
+---
+
+### Decision Type 2: Tool Selection
+
+**The question**: Do we use what the client owns, an open-source tool, or a commercial product?
+
+**The mental model**: The sovereign test — applied in order.
+
+1. Can we close this gap with what the client already owns or has already paid for? If yes, configure and operationalise it. Do not recommend anything else.
+2. If not, can we close it with an open-source tool in the sovereign tool stack? If yes, deploy it.
+3. If not — because the gap requires 24/7 managed response we cannot staff, compliance genuinely requires a vendor attestation, or the scale exceeds what open-source handles efficiently — then recommend the appropriate commercial partner.
+
+The test for step 3: *"Would I make this recommendation if I earned no more from it than from deploying the open-source alternative?"* If the answer is no, the recommendation is compromised.
+
+When you do recommend a commercial tool, disclose the partnership relationship at the moment of recommendation. Not in the footnotes.
+
+---
+
+### Decision Type 3: Scope
+
+**The question**: Is this request within scope? If the scope needs to change, how?
+
+**The mental model**: The completion-criteria test.
+
+A scope is defined only when you can write a sentence of the form: *"The work is complete when [verifiable condition]."* If you cannot write that sentence, the scope is not defined. Undefined scope is undeliverable.
+
+For scope changes during delivery:
+- Is the request something the agreed completion criteria would reasonably require? → Absorb it.
+- Is it genuinely new work? → Change order, written, before execution.
+- Is it something you should have scoped initially but missed? → Absorb it and note it as a scoping lesson.
+
+Never retroactively charge for out-of-scope work you did without a change order. Never silently absorb work that should be a change order. Both erode trust, in different directions.
+
+---
+
+### Decision Type 4: Communication
+
+**The question**: How do I communicate a difficult finding, a risk, a scope problem, or a project delay?
+
+**The mental model**: The "would I want to know?" test — applied to timing and framing.
+
+- Say it early. The client's distress from a critical finding is proportional to how long they were not told about it.
+- Say it plainly. No hedging, no softening, no burying in a paragraph of context.
+- Say what it means in business terms, not technical ones. "Your KRBTGT password is 847 days old" is a technical finding. "An attacker who compromises any domain account can forge authentication tokens valid for up to 847 days, which means we cannot trust any AD authentication even after we reset passwords" is a business finding.
+- Then say what we do about it.
+
+The sequence: *finding → business impact → recommended action → timeline*. Always in that order.
+
+---
+
+### Decision Type 5: Recommendation
+
+**The question**: What should the client do next?
+
+**The mental model**: The independence test.
+
+Before making any recommendation, ask: *"If I had no commercial relationship with any vendor and no financial stake in the client's decision, would I still make this recommendation?"* If yes, make it. If no, find the recommendation you would make under those conditions, and make that one instead.
+
+A recommendation that enriches you at the client's expense is not a recommendation. It is a conflict of interest wearing a consultant's jacket. The long-term value of independence — referrals, retained relationships, reputation — always exceeds the short-term value of a compromised recommendation.
+
+---
+
+## Part 2: The Discovery Call
+
+The discovery call happens before the Brownhat Diagnostic. Its purpose is not to sell anything. It is to determine whether this client is a fit for our work and whether we are a fit for their situation.
+
+### What to ask
+
+**The trigger question**: *"What happened recently that made you call us?"*
+
+Listen for: a specific incident, an audit finding, a regulatory deadline, a new hire who saw problems, a breach at a peer organisation. The trigger shapes everything — it tells you which domain is most sensitive, who the executive sponsor is, and how much urgency is real versus performed.
+
+**The accountability question**: *"Who in your organisation is ultimately accountable for security outcomes?"*
+
+Listen for: a specific person with budget authority. "Everyone is responsible" means no one is. Without a named executive sponsor who can make decisions and approve changes, the engagement will die in committee.
+
+**The tools question**: *"What tools do you have? M365 licensing level? Any existing EDR, SIEM, or PAM?"*
+
+This tells you how much existing tooling can be leveraged before any purchase is needed. An E5 client with underused Defender has a different engagement structure than an E3 client with no EDR at all.
+
+**The history question**: *"Have you had any incidents or near-misses in the past two years?"*
+
+Incidents reveal the actual threat landscape, the real response capability, and what the organisation already knows about its weaknesses. Post-incident clients have more internal urgency — and often more political complexity.
+
+**The success question**: *"What does success look like at the end of this engagement?"*
+
+Listen for specificity. "We want to be more secure" is not a success definition. "We want to pass our NIS2 audit in Q2 without findings" is. Clients who cannot articulate success criteria cannot be satisfied — they will always want more, differently, and retroactively.
+
+---
+
+### What disqualifies a client
+
+Some client situations are not a fit. Recognising them before starting an engagement is a service to the client and to yourself.
+
+| Signal | What it means | Response |
+|--------|--------------|---------|
+| No executive sponsor with decision authority | The engagement will require every decision to go through a committee that never meets | Ask who can approve changes in 24 hours. If the answer is unclear, do not start. |
+| "We just need a compliance certificate" | They want a stamp, not resilience | Redirect to a compliance auditor who will produce the stamp. We produce evidence; the stamp is a side effect. If they only want the side effect, we are the wrong provider. |
+| "We already know what we need, skip the diagnostic" — and no documentation to support this | High risk of undiscovered scope and mid-engagement surprises | See the [Engagement Model](engagement-model.md), Section 7. Never skip without equivalent documentation. |
+| The named project contact has no visibility into IT operations | You will spend half your time waiting for access and information | Escalate to the executive sponsor; require a named IT lead with operational access as a kickoff prerequisite. |
+| Budget so constrained that the Brownhat Diagnostic consumes most of it | There is no room to act on the findings; the diagnostic becomes a dead-end exercise | Have an honest conversation: the diagnostic is valuable standalone, but acting on it requires further investment. Confirm the client understands and accepts that constraint. |
+
+---
+
+### When to say no
+
+Decline engagements where:
+
+- The client wants findings presented to a regulator as "third-party validation" of work the client designed themselves, without independent assessment
+- The client has been vague or inconsistent about material facts during discovery — this will worsen during delivery
+- The scope involves active offensive operations against third parties without written authorisation from the targets
+- The client's goal is to reduce a finding's severity in an existing audit rather than to close the actual gap
+
+Saying no is not a failure. It is judgment. A reputation for honesty about fit is worth more than any single engagement.
+
+---
+
+## Part 3: Module Selection — When the Client Can Only Afford One
+
+The Brownhat Diagnostic produces a prioritised module roadmap. When the client has budget for one module and multiple problems, the selection logic is:
+
+**Step 1: What is the kill chain?**
+
+From the diagnostic findings, identify the shortest path from "nothing bad has happened yet" to "the organisation fails." The module that closes the highest-priority node on that path is the right recommendation.
+
+**Step 2: If two modules address the same node, choose the faster time-to-value.**
+
+Module 6 (AD Hardening) closes more attack paths faster than Module 12 (Blue/Purple Team) for a client with a degraded AD. But Module 12 produces detection capability that persists. If both are equal by kill-chain analysis, choose the module that produces durable, operational output over the module that produces a point-in-time fix.
+
+**Step 3: Never recommend a later-stage module when an earlier-stage gap is unaddressed.**
+
+Detection engineering (Module 12) is waste if identity is uncontrolled (Module 2). A red team engagement (Module 10) will find what the kill chain already shows if the basic hygiene isn't done. The right answer is almost always the module that fixes the foundation — not the module that tests it.
+
+---
+
+### Common single-module scenarios
+
+| Client situation | First module | Rationale |
+|-----------------|-------------|-----------|
+| "Our AD is a mess — stale accounts, no tiering, legacy configs" | **Module 6** | Closes the most attack paths fastest; produces durable structural improvement |
+| "We had a phishing incident; accounts were compromised" | **Module 2** | The exploit path was identity; fix the foundation before adding detection on top of it |
+| "We have no visibility — we would not know if we were breached" | **Module 1** then **Module 12** | Endpoint management establishes the asset baseline; blue/purple team builds detection on top |
+| "DORA audit in 5 months" | **Brownhat Diagnostic** first | The diagnostic maps the gaps to specific controls; module selection follows from the audit findings |
+| "Our MSSP generates 300 alerts a day and nothing gets fixed" | **Module 12** | The MSSP problem is a detection engineering problem; retained capability closes it |
+| "We are moving to M365 and want to do it right" | **Module 1** → **Module 2** → **Module 3** | In sequence: endpoint baseline, identity security, then hardening |
+| "We have OT and IT on the same flat network" | **Module 8** | The segmentation gap is existential; close it before any other work |
+
+---
+
+## Part 4: The Ten Most Common Mistakes
+
+These are the failure patterns that appear most often in first engagements. They are not failures of competence. They are failures of discipline — usually under client pressure, time pressure, or social discomfort.
+
+---
+
+**1. Starting with recommendations before understanding**
+
+Recommending modules, tools, or configurations before the Brownhat Diagnostic is complete. The savings in week 1 cost three times as much in week 5 when the undiscovered scope surfaces.
+
+---
+
+**2. Scope without completion criteria**
+
+Agreeing to "improve AD security" or "harden the M365 tenant" without writing down what "improved" and "hardened" mean in verifiable terms. The work never ends; the client never feels satisfied; the invoice is always a surprise.
+
+---
+
+**3. Absorbing scope creep silently**
+
+Doing out-of-scope work to avoid the discomfort of raising a change order. This trains the client that scope is negotiable and invoices are estimates. It feels worse at billing time than the conversation would have felt mid-engagement.
+
+---
+
+**4. Leaving without runbooks**
+
+Completing technically excellent work without documenting how to operate it. Three months later, something changes or breaks, and nobody on the client side knows how the system works. The client calls back — but not with gratitude.
+
+---
+
+**5. Recommending a purchase before demonstrating existing-tools value**
+
+Proposing a new commercial tool in week 2 before showing the client what their existing investments can do. This looks like reselling, not consulting. It destroys the credibility of the "existing tools first" principle in the same engagement where you invoked it.
+
+---
+
+**6. Hiding bad news**
+
+Discovering a critical finding and softening it to manage the client's reaction. The client's distress from a critical finding is proportional to how long they were not told about it. Say it plainly, frame the remediation, and let the client's reaction be what it is.
+
+---
+
+**7. Over-promising timelines**
+
+Committing to module durations based on the nominal calendar, knowing that the client's access provisioning, decision-making cadence, and existing workload will add weeks. Scope to the realistic case; under-promise and over-deliver.
+
+---
+
+**8. Treating all findings as equally urgent**
+
+Producing a finding list with thirty items where a P0 and a P2 look identical. The client picks items by recognition or by urgency they invent, and the kill chain remains open. Make the priority structure impossible to miss — it should be the first thing a client sees, not something they have to infer.
+
+---
+
+**9. Making changes without explicit client approval**
+
+Even obviously correct changes. The technical work is not the only product of the engagement — trust is also a product. Trust is built on consent, not just competence. Every production change has explicit written approval before execution.
+
+---
+
+**10. Confusing baseline for delivery**
+
+Week 1 produces the baseline. It does not produce improvements. Clients sometimes interpret a week of scanning and documentation as slow progress and apply pressure to start making changes. The week 1 discipline is non-negotiable. Explain why: *"Everything we change in week 2 will be benchmarked against what we documented in week 1. Without the baseline, we cannot measure the improvement. And we cannot improve safely what we do not yet understand."*
+
+---
+
+## Part 5: Technical Onboarding
+
+### CQRE tool repositories
+
+Before leading a module, you need to be able to deploy and use the tools that module depends on. All CQRE tools are hosted at git.cqre.net:
+
+| Tool | Repository | Used in |
+|------|-----------|---------|
+| **ASTRAL** | `cqrenet/astral` (public) · `cqrenet/Intune` (internal, full version) | Modules 1, 2, 3 |
+| **AOC** | `cqrenet/aoc` | Modules 2, 3, 12; retained capability |
+| **macOS_IntuneManagement** | `cqrenet/macOS_IntuneManagement` | Module 1; tenant migrations |
+| **Elysium** | `cqrenet/elysium` | Module 6, 10 |
+| **CAExporter** | `vibecoding/CAExporter` | Modules 2, 3 |
+| **E8-CAT** | `vibecoding/E8-CAT` | Modules 1, 3 |
+| **IntunePolicyParser** | `vibecoding/IntunePolicyParser` | Module 1; alongside ASTRAL |
+| **M365-Scripts** | `cqrenet/M365-Scripts` | Module 1 (MDE device lifecycle) |
+
+Each repository contains its own README with deployment instructions. Read the README and deploy the tool in a lab environment before using it with a client. Do not learn a tool at a client's expense.
+
+### Required competencies before leading each module
+
+This is the minimum bar for leading (not shadowing) a module. If you are not there yet, shadow the module first.
+
+| Module | Minimum competency |
+|--------|-------------------|
+| **Module 1** (Endpoint) | PowerShell 7+; Intune policy structure; ASTRAL deployment and configuration; E8-CAT scoring |
+| **Module 2** (Identity) | Entra ID architecture; Conditional Access design; PIM/PAM concepts; AOC deployment; CAExporter export and analysis |
+| **Module 3** (M365 Hardening) | Modules 1 and 2 competency; Prowler Azure audit; ASTRAL drift detection; ASR rules |
+| **Module 6** (AD Hardening) | Active Directory architecture; BloodHound collection and analysis; DSInternals and Elysium operation; LAPS deployment; GPO design; Sysmon configuration |
+| **Module 8** (OT Security) | OT/IT network segmentation concepts; NIS2 Article 21 and 23 requirements; SCADA/ICS risk framing; Zeek or Suricata basics |
+| **Module 12** (Blue/Purple Team) | MITRE ATT&CK framework; KQL or Sigma rule authoring; Wazuh deployment; TheHive and Shuffle basics; detection engineering fundamentals |
+| **Module 13** (Privileged Access) | WireGuard protocol; Tailscale and Headscale deployment; Teleport architecture and session recording; SSH certificate authority concepts |
+| **Module 14** (Sovereign Communications) | Delta Chat and chatmail relay deployment; Matrix/Synapse basics (for enterprise deployments); out-of-band communication design |
+
+### Building your lab environment
+
+Before your first client engagement, build a personal lab that lets you safely test deployments:
+
+- **M365 developer tenant** — Microsoft's free developer programme provides an E5 tenant. Use it for ASTRAL, AOC, CAExporter, and M365 module testing. Register via the Microsoft 365 Developer Programme.
+- **A small Linux VM (any cloud)** — For chatmail relay, Wazuh, TheHive, and Shuffle deployments. A €5–10/month VPS is sufficient for personal lab use.
+- **A Windows Server VM** — For AD module testing: BloodHound, Elysium, LAPS, Sysmon. Can be local (Hyper-V, VMware) or cloud.
+- **A CQRE internal environment** — Ask for access to the shared lab environment used for tool testing and client demos.
+
+The rule: you must have deployed and operated every tool you plan to use with a client, in a controlled environment, before the client engagement begins.
+
+---
+
+## Part 6: Writing a Proposal
+
+A Brownhat engagement proposal has four parts, in this order:
+
+---
+
+### Part 1: What we found
+
+Two to five specific findings from the Brownhat Diagnostic or discovery call. Not generic risk language. Specific observations:
+
+> *"Your Active Directory contains 847 user accounts, of which 312 have not been accessed in over 12 months. Eleven domain administrator accounts exist; six are used for daily workstation tasks including email and web browsing. The KRBTGT password has not been rotated in 1,247 days."*
+
+The client should recognise their environment in this section. If they do not, the discovery was not thorough enough.
+
+---
+
+### Part 2: What we recommend
+
+One specific module — the one that closes the highest-priority gap from the diagnostic. With an explicit scope: the deliverables, the completion criteria, and what is out of scope.
+
+> *"We recommend Module 6: On-Premise AD Hardening. Scope: BloodHound attack path analysis and remediation report; Elysium password audit with prioritised remediation list; LAPS deployment to all domain-joined workstations (confirmed 100% coverage); KRBTGT rotation; reduction of Global Administrator accounts to a documented minimum; operating runbook for ongoing AD hygiene.*
+> *Out of scope: Azure AD Connect hardening (Module 2), endpoint EDR deployment (Module 1), and any changes to OT network infrastructure.*
+> *Complete when: LAPS coverage is verified at 100%, KRBTGT rotation is confirmed, and the privileged account count and BloodHound attack path count are documented against the post-engagement baseline."*
+
+---
+
+### Part 3: What you will receive
+
+The Module Completion Package for this specific module. Restate the standard package (from the [Engagement Model](engagement-model.md)) with module-specific additions:
+
+> *"At completion of this engagement, you will receive: a configuration baseline document; the BloodHound and Elysium output files delivered to your own repository; operating runbooks for LAPS management, KRBTGT rotation cadence, and privileged account review; an updated risk register entry for each finding; a before-and-after AD security score (PingCastle); and a recommended next module with rationale."*
+
+---
+
+### Part 4: Investment
+
+| Item | Detail |
+|------|--------|
+| **Consultant effort** | [N] days |
+| **Calendar timeline** | [Start date] → [Completion date] |
+| **Infrastructure** | [Any costs, e.g., chatmail relay €5–10/month] |
+| **External licensing** | [None / or specify] |
+| **Total** | [Fixed fee in €] |
+
+Include a note on payment terms (e.g., 50% at kickoff, 50% at completion).
+
+---
+
+### What never goes in a proposal
+
+| Never include | Why |
+|---------------|-----|
+| Vague risk language ("your organisation faces significant cybersecurity risks") | Every client already believes this. It adds no information and signals you do not know their specific situation. |
+| Tool shopping lists before the diagnostic | Recommending specific products before understanding the environment is reselling, not consulting. |
+| Pricing ranges | A range signals that you do not know the scope. Scope it properly and give a fixed price. |
+| Multi-year commitments in a first proposal | The client has not yet seen you work. Earn the next engagement. |
+| Best-case timelines presented as the estimate | The client will hold you to them. Scope to the realistic case. |
+| A list of everything you found rather than a prioritised narrative | Volume is not insight. A proposal is not a scan report. |
+
+---
+
+## Integration With Existing Frameworks
+
+| Document | Relationship |
+|----------|-------------|
+| [Engagement Model](engagement-model.md) | The operational complement: delivery mechanics, client requirements, pricing structure, communication cadence. Read first. |
+| [Move Fast and Fix Things](move-fast-and-fix-things.md) | The source of the "existing tools first" and "fix the kill chain first" principles operationalised in Part 1 |
+| [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic: the entry point for every new client, referenced throughout Parts 2 and 3 |
+| [Modular Engagements](modular-engagements.md) | The full module menu: descriptions, durations, investment levels, and per-module deliverables referenced in Parts 3 and 6 |
+| [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) | The tool selection doctrine (sovereign test), the per-module tool pairings, and the commercial partnership framework |
+| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | The client-facing persuasion scripts and objection handling that complement the internal decision models in this document |
+| [Antifragile Risk Register](../assessment-templates/antifragile-risk-register.md) | The risk register format used in the module completion package and referenced in prioritisation |
+
+---
+
+*For delivery mechanics and pricing, see [Engagement Model](engagement-model.md).*
+*For module descriptions and selection, see [Modular Engagements](modular-engagements.md).*
+*For client-facing scripts, see [C-Suite Conversation Guide](c-suite-conversation-guide.md).*

antifragile-consulting/core/engagement-model.md

@@ -0,0 +1,510 @@
+# Engagement Model: Working with Brownhat / CQRE
+
+> *"A consultant who cannot tell you exactly what you will receive and when is not a consultant. They are a process."*
+
+This document explains how engagements with CQRE work in practice — the sequence from first contact to completed work, what we ask of you, and what you will hold in your hands at the end.
+
+**Sections 1–6 are written for clients.** They describe the client experience: the lifecycle, the requirements, the deliverables, the pricing structure, and the communication rhythm.
+
+**Section 7 is written for consultants.** It covers scoping, pricing conversations, delivery discipline, and how to handle difficult situations. It is not typically shared with clients.
+
+---
+
+## Why This Document Exists
+
+Most consulting engagements fail not because the work is wrong but because expectations were misaligned. The client expected a report; the consultant delivered a roadmap. The client expected thirty days; it took ninety. The consultant believed the scope was fixed; the client believed it was a starting point.
+
+This document eliminates that by making the engagement model explicit before work begins. Both sides should be able to answer:
+
+- What happens first, and what comes after that?
+- What does the client need to provide, and when?
+- What will the client hold in their hands at the end of each stage?
+- How is the work priced, and what is never billable?
+- What does success look like, and how is it measured?
+
+---
+
+## Section 1: The Entry Point — The Brownhat Diagnostic
+
+**We do not begin with recommendations. We begin with understanding.**
+
+The Brownhat Diagnostic — a structured NIST CSF 2.0 baseline assessment — is the mandatory entry point for every new client. It is not a free scoping call. It is a paid, bounded engagement that produces a deliverable of value regardless of whether any further work follows.
+
+**Why we insist on this**: Every consulting failure we have witnessed started with a recommendation made before the environment was understood. Clients are told they need a SOC before anyone has mapped their assets. They buy an EDR platform before anyone has verified that Defender already covers the gap. They engage a penetration tester before knowing what their actual attack surface looks like. The Brownhat Diagnostic prevents this. We earn the right to recommend anything only after we understand your specific reality.
+
+**What the client receives from the Brownhat Diagnostic**:
+
+- A current-state assessment across all six NIST CSF 2.0 domains (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER)
+- An identified kill chain: the shortest path from "nothing bad has happened yet" to "the organisation cannot operate"
+- Up to five quick wins — things improvable within 30 days using existing tools and no budget
+- A prioritised remediation roadmap mapped directly to the antifragile module menu
+- Auditable evidence of due diligence that can be presented to a regulator, board, or auditor
+
+**The one exception**: Clients experiencing an active incident or a hard deadline (ransomware recovery in progress, regulatory submission in 30 days) may engage directly with the relevant module. In this case, the Brownhat Diagnostic is scheduled for after the immediate work, not instead of it.
+
+*For the full Brownhat Diagnostic methodology, see [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md).*
+
+---
+
+## Section 2: The Engagement Lifecycle
+
+A standard engagement moves through five stages. Not every engagement completes all five — some clients take a single module and stop. That is a valid outcome. The structure is designed to be modular, not mandatory end-to-end.
+
+```
+Stage 1: Brownhat Diagnostic
+         ↓
+Stage 2: Module Selection and Proposal
+         ↓
+Stage 3: Engagement Kickoff
+         ↓
+Stage 4: Delivery
+         ↓
+Stage 5: Completion and Handover
+         ↓ (optional)
+Stage 6: Retained Relationship
+```
+
+---
+
+### Stage 1: Brownhat Diagnostic
+
+*Duration: Two half-day workshops + five business days for report delivery.*
+
+A structured workshop with the client's executive sponsor, IT lead, and one business process owner. No tools are installed. No systems are accessed. No changes are made. The output is a clear, honest picture of where the organisation stands and what matters most to fix.
+
+*See [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) for the full workshop methodology, questionnaires, and report structure.*
+
+---
+
+### Stage 2: Module Selection and Proposal
+
+*Duration: 1–5 business days after diagnostic delivery.*
+
+Based on the Brownhat Diagnostic findings, we present a recommended module sequence:
+
+- Which modules address the identified kill chain (P0 — existential risk)
+- Which modules address critical but non-existential gaps (P1)
+- Which modules can wait until P0 and P1 work is complete (P2)
+- An estimated timeline and investment level for each recommended module
+- A recommended starting point: one module, bounded scope, defined deliverable
+
+We do not propose a comprehensive multi-year programme and request a blanket signature. We propose the next logical module, explain exactly why, and let the client decide whether to proceed. Each module stands alone. Committing to one does not commit to any other.
+
+---
+
+### Stage 3: Engagement Kickoff
+
+*Duration: 1–3 days.*
+
+Before delivery begins, we establish:
+
+| Item | Detail |
+|------|--------|
+| **Named client lead** | One person with authority to approve changes, answer questions, and make decisions within 24 hours. This person is not optional. Without a named lead, the engagement does not start. |
+| **Access and credentials** | All required access provisioned before day 1, not on day 1. Accounts, MFA, and permissions confirmed in writing. |
+| **Communication channels** | A shared channel (Teams or Slack) for day-to-day communication + a Delta Chat channel on an independent chatmail relay for sensitive material and out-of-band escalation |
+| **Scope agreement** | A written document listing exactly what is in scope, what is explicitly out of scope, and what the completion criteria are. Signed before work begins. |
+| **Weekly check-in slot** | A standing 30-minute slot with the named client lead. Calendar-blocked before kickoff. |
+
+---
+
+### Stage 4: Delivery
+
+*Duration: Module-specific. See [Modular Engagements](modular-engagements.md) for per-module timelines.*
+
+Delivery follows a consistent rhythm regardless of which module is active.
+
+**Week 1 — Documentation and baseline. No changes.**
+
+Every module begins with reading before writing. We export current configuration state, run baseline assessments, collect existing documentation, and confirm that the agreed scope matches the discovered reality. We make no changes in week 1. This discipline exists because changes made without understanding the environment create new problems; because the client needs to see our process before they trust our execution; and because a clean baseline is required to measure progress.
+
+**Weeks 2–N — Iterative delivery with daily change log.**
+
+Every change is documented the day it is made. The client's named lead sees what changed and why. Nothing is deployed to production without their explicit approval. The pace is set by what can be done safely, not by a calendar.
+
+**Weekly check-in — 30 minutes, every week.**
+
+Structure:
+1. What was completed since last week (change log review)
+2. What is being worked on this week
+3. Decisions the client needs to make
+4. Risks and open issues
+
+Meeting notes shared within 24 hours. Action items have owners and dates. If the check-in is consistently cancelled by the client, the engagement is paused until it resumes.
+
+**Escalation before execution.**
+
+If a change carries production risk, requires budget beyond the agreed scope, or touches a system requiring executive sign-off, we escalate before we execute. We do not ask forgiveness.
+
+---
+
+### Stage 5: Completion and Handover
+
+*Duration: 3–5 business days for documentation + 1 final presentation.*
+
+Every completed module produces a **Module Completion Package**:
+
+| Deliverable | Description |
+|-------------|-------------|
+| **Configuration baseline document** | A record of the state before the engagement, every change made, and the rationale for each change |
+| **Scripts, rules, and automation** | Delivered into the client's own repository. The client owns everything we write. |
+| **Operating runbooks** | Step-by-step instructions for the client's team to operate and maintain what was built — with cadences, alert handling procedures, and escalation paths |
+| **Risk register update** | What the module closed (with evidence), what remains open, and what the next recommended work would address |
+| **Metrics baseline** | A measurable before-and-after snapshot: the score against which the next engagement can be benchmarked |
+| **Next-module recommendation** | One or two sentences on the logical next step. No obligation — a signpost. |
+
+**The handover principle**: At the end of every engagement, the client's team must be able to operate everything we built without calling us. If they cannot, the handover is not complete. Knowledge transfer is a deliverable, not a bonus.
+
+---
+
+### Stage 6: Retained Relationship
+
+*Optional. Available after at least one project module is complete.*
+
+Some clients want ongoing support rather than discrete projects. Three models:
+
+| Type | Description | Typical cadence |
+|------|-------------|----------------|
+| **Retained advisory** | A fixed number of hours per month for questions, threat model reviews, architecture reviews, and strategic guidance. No new module delivery — advisory only. | Monthly retainer, 8–16 hours/month |
+| **Retained capability support** | Active support operating tools we deployed: reviewing ASTRAL alerts, tuning AOC detection rules, running quarterly AD scans with Elysium and PingCastle, reviewing Huntress findings. | Monthly or quarterly, scoped per tool set |
+| **Module continuation** | Ongoing delivery of a multi-module programme at a structured cadence. Each module planned and scoped before it begins. | Quarterly module delivery |
+
+Retained relationships are renewed quarterly. Either side can exit with 30 days' notice.
+
+---
+
+## Section 3: What We Ask of the Client
+
+The most common cause of engagement delay is access that should have been provisioned before day 1 but was not. These are the standing requirements:
+
+### Mandatory for every engagement
+
+| Requirement | Why it matters |
+|-------------|---------------|
+| **Named client lead with decision authority** | One person who can approve changes, unblock access, and respond within 24 hours. Without this, every decision becomes a committee meeting. |
+| **Administrative access — provisioned before day 1** | Read access for the baseline week; write access confirmed before changes begin. Accounts, MFA enrollment, and permissions confirmed in writing before kickoff. |
+| **Existing documentation** | Whatever exists: network diagrams, asset lists, previous audit reports, incident post-mortems. Imperfect documentation is far better than none. |
+| **Weekly 30-minute check-in** | Standing, calendar-blocked before kickoff. The engagement rhythm depends on it. |
+| **Tolerance for uncomfortable findings** | The Brownhat Diagnostic and the first week of any module will surface things nobody wanted to surface. That is the point. The client's job is to receive findings honestly. |
+
+### Module-specific requirements
+
+Each module documents its prerequisites in detail in [Modular Engagements](modular-engagements.md). Common examples:
+
+| Scenario | Access requirement |
+|----------|-------------------|
+| M365 modules (1–5) | Global Admin access or appropriately scoped Graph API permissions; pipeline access for ASTRAL deployment |
+| AD Hardening (Module 6) | Domain Admin access; access to all domain controllers; a maintenance window for KRBTGT rotation |
+| OT Security (Module 8) | OT network diagram; OT engineer participation (not just IT); vendor contact list for OT systems |
+| Blue/Purple Team (Module 12) | Written authorisation for red team activities; defined out-of-scope systems list; incident response lead identified |
+| Privileged Access (Module 13) | Network topology; full list of privileged accounts and service accounts; existing PAM tool inventory |
+
+### What we do not require
+
+- **A clean environment.** We work in brownfield by design. If your environment were clean, you would not need us.
+- **Pre-approved budgets for new tools.** Every engagement starts with what you own. Purchases are recommended only after we demonstrate the gap cannot be closed with existing investments.
+- **A dedicated project team.** Most modules require one named lead and part-time IT admin access. We bring the methodology; you provide the context.
+
+---
+
+## Section 4: What the Client Receives
+
+| Stage | Deliverable |
+|-------|-------------|
+| Brownhat Diagnostic | Current-state assessment report (6-domain, kill chain, quick wins) + prioritised module roadmap |
+| Module kickoff | Written scope agreement; access checklist confirmation; communication channel setup |
+| Weekly (during delivery) | Change log update; check-in summary (decisions made, items pending, risks) |
+| Module completion | Configuration baseline document; scripts/rules in client repository; operating runbooks; risk register update; metrics baseline; next-step recommendation |
+| Retained relationship | Monthly advisory summary or capability review report |
+
+**Ownership**: Every script, detection rule, query, configuration file, and document produced during an engagement belongs to the client permanently. We do not retain privileged access to client environments after an engagement closes. We do not license anything we build — it is yours.
+
+**Format**: Deliverables are produced in Markdown, delivered to the client's own repository (our preference). Word or PDF formats are available on request. We do not lock clients into proprietary tools for accessing their own documentation.
+
+---
+
+## Section 5: Pricing and Commercial Model
+
+### The Brownhat Diagnostic
+
+The Brownhat Diagnostic is priced as a fixed-scope engagement:
+
+| Component | Hours |
+|-----------|-------|
+| Pre-engagement preparation | 2 |
+| Workshop Session 1 (half-day) | 4 |
+| Workshop Session 2 (half-day) | 4 |
+| Report preparation | 4–8 |
+| Report presentation and Q&A | 2 |
+| **Total consultant time** | **16–20 hours** |
+
+Travel and accommodation billed at cost for in-person delivery. Remote delivery (camera-on, strongly preferred for the diagnostic) carries no additional charge.
+
+### Module Pricing
+
+Modules are priced on a **fixed-scope, fixed-deliverable basis** — not time and materials. Before an engagement starts, the client knows exactly what they are paying for and exactly what they will receive. The price is agreed in writing before work begins. There are no end-of-engagement surprises.
+
+Module investment levels correspond to estimated consultant effort:
+
+| Level | Estimated consultant effort |
+|-------|-----------------------------|
+| **Very low** | Under 3 consultant days |
+| **Low** | 3–8 consultant days |
+| **Low to medium** | 8–15 consultant days |
+| **Medium** | 15–30 consultant days |
+| **Medium to high** | 30–50 consultant days |
+| **High** | 50+ consultant days; typically multi-phase programmes |
+
+Per-module investment levels are documented in [Modular Engagements](modular-engagements.md). The specific day rate applied to these estimates is stated in each engagement proposal and agreed before kickoff.
+
+### Infrastructure and licensing costs
+
+Some modules carry small infrastructure costs that are invoiced separately at cost:
+
+| Item | Typical cost | Module |
+|------|-------------|--------|
+| Delta Chat chatmail relay (VPS) | €5–10/month | All engagements — out-of-band channel |
+| Matrix/Element hosting | Varies by deployment model | Module 14 (Sovereign Communications) |
+| Teleport Enterprise licensing | Per-user, varies | Module 13 for non-qualifying clients |
+| Tailscale | Per-user, varies | Module 13 where Headscale is not preferred |
+
+Open-source tools (BloodHound, Wazuh, Elysium, CAExporter, E8-CAT, and the rest of the sovereign tool stack) carry no licensing cost.
+
+### Multi-module programmes
+
+Clients committing to a multi-module programme (typically 3+ modules, scoped in advance) receive:
+- A single programme scoping session replacing individual module kickoffs
+- A programme-level risk register maintained continuously across all modules
+- Priority scheduling with module slots reserved in advance
+- A reduced overall rate versus individual module pricing (agreed at programme scope)
+
+### Retained relationship pricing
+
+Retained advisory and capability support is billed monthly at a fixed rate for a minimum quarterly commitment. The rate reflects reserved hours per month and the agreed response-time commitment.
+
+### What is never billable
+
+- Repeat work caused by our own errors
+- Re-delivery of documentation that was deficient at handover
+- Out-of-scope additions we accepted without a written change order
+- Tools and scripts we produce — these are included in the module, not licensed separately
+
+### The "existing tools first" principle and its commercial implication
+
+Our explicit commitment to maximising existing investments before recommending purchases means our engagements are priced primarily on labour, not licence margins. We earn the same whether we deploy Wazuh (free) or recommend Huntress (commercial partnership). We do not earn more from an engagement if the client buys new tools.
+
+When we recommend a commercial tool, the recommendation is because the gap genuinely requires it. When we have a commercial partnership (Huntress, Tailscale, Thinkst Canary, Tenable), that relationship is disclosed at the time of recommendation.
+
+*For the ROI and risk quantification framework, see [Business Case Template](business-case-template.md).*
+
+---
+
+## Section 6: Communication and Governance
+
+### The standing check-in
+
+Every active module has a 30-minute weekly check-in with the named client lead. This is the primary governance mechanism for the engagement. It is not optional and not reschedulable without 24 hours' notice.
+
+**Agenda**:
+1. Change log review (5 minutes): what was completed since last week
+2. Active work (10 minutes): what is being delivered this week
+3. Client decisions required (10 minutes): approvals, access requests, scope questions
+4. Risks and open issues (5 minutes)
+
+Meeting notes are shared within 24 hours. All action items have a named owner and a due date.
+
+### The steering committee (for multi-module programmes)
+
+For programmes spanning multiple modules or involving significant organisational change, a monthly 60-minute steering committee is recommended:
+
+- **Attendees**: Executive sponsor, named client lead, CQRE consultant lead
+- **Agenda**: Module progress summary, risk register review, next module decision, budget review
+- **Output**: Written decision record, updated programme plan
+
+### Escalation
+
+| Situation | Action |
+|-----------|--------|
+| Change carries significant production risk | Written approval from named client lead before execution |
+| Change requires budget beyond agreed scope | Escalated to executive sponsor; work paused until approved |
+| Security incident discovered during engagement | Client notified immediately; scope adjusted by written agreement; incident response activated if required |
+| Named client lead unavailable for more than 5 business days | Engagement paused; billing suspended |
+| Scope extension requested by client | Written change order agreed and signed before additional work begins |
+
+### The out-of-band channel
+
+Before any module begins, all named participants — client lead, executive sponsor, key technical contacts, and the CQRE consultant lead — are enrolled in a Delta Chat channel on an independent chatmail relay. This setup takes under 10 minutes and costs nothing.
+
+This channel is used for:
+- Sensitive findings that should not travel through corporate email or Teams
+- Incident coordination when corporate channels are unavailable or compromised
+- Out-of-hours escalation for urgent decisions
+
+**This channel is not optional.** The rationale is simple: if the engagement is active when corporate infrastructure is experiencing an incident, we need a communication path that does not depend on the infrastructure under attack.
+
+*For setup instructions, see [Sovereign Communications](../playbooks/sovereign-communications.md).*
+
+---
+
+## Section 7: For the Consultant — Scoping, Pricing, and Delivery
+
+*This section is for internal use. It is not typically shared with clients.*
+
+---
+
+### The rules you cannot break
+
+**1. The Brownhat Diagnostic is always the entry point.**
+
+A client who wants to skip the diagnostic and go straight to a module is a client whose scope will be undefined, whose success criteria will be undefined, and whose hidden problems will surface mid-engagement. The diagnostic is not a formality — it is how we prevent the most common failure mode in consulting. The one exception (active incident) is documented in Section 1.
+
+**2. Fixed scope, fixed deliverable, written before work starts.**
+
+Never begin delivery without a signed scope agreement that lists exactly what will be produced and what the completion criteria are. "We will improve the client's AD security" is not a scope. "We will deliver: a BloodHound attack path analysis; an Elysium password audit with remediation list; LAPS deployed to 100% of domain-joined workstations; KRBTGT rotation; a Tier 0 admin account audit; and a runbook reviewed and signed off by the client lead" — that is a scope.
+
+**3. The client owns everything we produce.**
+
+Scripts go into the client's repository. Detection rules are documented in the client's SIEM. Runbooks live in the client's wiki. Nothing should require our return. If at the end of an engagement the client cannot operate what we built without calling us, the handover is not complete.
+
+**4. Knowledge transfer is a deliverable.**
+
+Build time for knowledge transfer into every scope estimate. A runbook is not a knowledge transfer. A runbook plus a walkthrough with the client's team is a knowledge transfer. The test: can the client's named IT lead explain to a new colleague how to use what we built, without asking us?
+
+**5. Week 1 is always documentation and baseline — no changes.**
+
+This is non-negotiable. The temptation to start fixing things immediately is understandable. Resist it. The discipline of a baseline week protects both the client and the consultant. It makes the before-and-after visible. It surfaces scope surprises before they become billing disputes.
+
+---
+
+### Scoping discipline
+
+When estimating a module, use this framework:
+
+**Step 1: Root the estimate in the Brownhat Diagnostic findings.**
+
+What specific gaps does this module close? How severe and how complex are they? A Module 6 engagement for a 200-seat organisation with 15 years of AD debt takes materially longer than the same module for a recently built 50-seat environment. The diagnostic findings should drive the estimate, not the module's nominal duration.
+
+**Step 2: Assess client capacity.**
+
+How available is the named client lead? Does the client have an IT admin who can own parts of the rollout, or must we do everything? A capable internal sysadmin who can execute the LAPS deployment while we focus on the AD architecture review is a different scope than a client where we are the only technical resource.
+
+**Step 3: Identify prerequisites and risks.**
+
+Missing prerequisites mean delay. Scope estimates that assume prerequisites are already met are optimistic estimates. For any prerequisite that is "in progress" rather than "confirmed," add buffer.
+
+**Step 4: Define completion criteria explicitly.**
+
+Not "when we've improved the client's identity security." But: "when MFA is enforced for 100% of users (verified via Conditional Access sign-in logs), legacy authentication is blocked tenant-wide (verified via CAExporter export and sign-in log review), all Global Admin accounts have been converted to JIT access via PIM or manual process, and the runbook is reviewed and signed off by the client lead." Completion criteria that cannot be verified are not completion criteria.
+
+**Step 5: Write the scope agreement before kickoff — not during, not after.**
+
+---
+
+### Pricing conversations
+
+**The Brownhat Diagnostic pitch**:
+
+> *"Before we recommend anything, we need to understand exactly where you are. This assessment takes two half-days and produces a report you can use independently of us — your strengths, your gaps, and the three things that matter most to fix first. It is a paid engagement because our time has value and your assessment has value. If you decide not to proceed with any module, you still have a prioritised roadmap. That is a good outcome for you."*
+
+**The fixed-scope pitch**:
+
+> *"We price by deliverable, not by the hour. You know exactly what you are paying for before we start, and you know exactly what you will receive. There are no 'the scope was larger than we expected' surprises at invoice time. If scope changes, we write a change order before we do the work."*
+
+**The "existing tools first" pitch**:
+
+> *"We do not earn more if you buy new tools. Our first obligation is to extract the value you have already paid for. The recommendation to buy something comes only when we can demonstrate that your existing tools cannot close the specific gap."*
+
+**When the client asks for a discount**:
+
+Do not discount the Brownhat Diagnostic. It is already priced below its value — the roadmap alone is worth more than the workshop cost for most clients. For module pricing, a multi-module commitment justifies a programme rate. A single module discount signals that the price was not honest to begin with.
+
+---
+
+### Handling scope creep
+
+Scope creep is expected — the client discovers adjacent problems as we work. The correct response is not to absorb unlimited scope silently and then present a large invoice, and it is not to refuse everything that was not in the original document.
+
+1. Note the new request in writing in the same session it is raised
+2. Assess: is it within the agreed completion criteria?
+   - **Within scope**: absorb it; document it in the change log; no charge
+   - **Outside scope**: write a change order before doing the work
+3. The change order states the additional effort, the revised completion criteria, and the additional cost — agreed and signed before execution
+4. Never retroactively charge for out-of-scope work that you did without a change order
+
+The most common form: *"While you're in here, can you also look at X?"* The correct answer: *"Yes, we can include that. Let me scope it — probably [N] additional days. I'll send a change order this afternoon. Do you want to confirm before we start on it, or shall I include it in the current sprint?"*
+
+---
+
+### When the client pushes back on open-source
+
+Three underlying objections, each with a different correct response:
+
+**"Our auditor requires a vendor-backed tool."**
+Establish whether this is a real requirement or an assumed one. Many "needs a vendor tool" requirements are actually "needs documented evidence" — which open-source produces equally well. Ask: "What specifically does the auditor require?" If it genuinely requires a vendor logo and attestation, route to the appropriate commercial partnership. If it requires evidence and documentation, show them that BloodHound + CISO Assistant produces audit-ready evidence that any commercial tool would produce.
+
+**"We tried open-source before and it was too complex."**
+This is a deployment and maintenance problem, not a capability problem. Address the real concern directly: *"Who will maintain it after we leave?"* If the answer is "nobody reliable," the sovereign stack requires a retained capability support arrangement, or the commercial partnership tier is the right recommendation.
+
+**"We want vendor support."**
+Respect this as a legitimate position. Not every client wants to own their tools. For these clients, the commercial partnership tier (Huntress, Tenable, Tailscale) is the right answer, supplemented by our managed deployment and ongoing advisory retainer. Document the trade-off (cost, sovereignty) so the client makes an informed decision.
+
+---
+
+### When the client wants to skip the diagnostic
+
+*"We know what we need. Just do Module 6."*
+
+A client with recent, credible environment documentation — a post-incident forensic report, a recent third-party assessment, or a previous Brownhat Diagnostic — can proceed to module scoping with a condensed discovery session rather than the full diagnostic. If they have that documentation, use it.
+
+If they do not have it, the honest response is:
+
+> *"The diagnostic costs less than the overtime we will spend fixing scope surprises mid-module. I will never recommend skipping it unless you have equivalent documentation. What do you have?"*
+
+If they insist without adequate documentation, document the risk in writing, scope conservatively, and add buffer for the discoveries week 1 will produce.
+
+---
+
+### When the client's IT team is resistant
+
+Internal IT teams sometimes perceive external consultants as a threat to their position or a criticism of their work. Signs: slow access provisioning, minimal engagement in check-ins, information provided grudgingly.
+
+The correct posture:
+- Make the IT lead a co-deliverer, not a subject. Their knowledge of the environment is essential; frame the engagement as structured support, not inspection.
+- Credit their existing work publicly in the kickoff and in every report
+- Never phrase findings as failures of the IT team — phrase them as consequences of resource constraints, technical debt, or changing threat landscape
+- If resistance is blocking delivery, escalate to the named client lead privately, not in a group setting
+
+---
+
+### The first week checklist
+
+Regardless of module, week 1 produces:
+
+- [ ] Configuration export (ASTRAL snapshot for M365; BloodHound + Purple Knight run for AD; CAExporter export for identity; or equivalent)
+- [ ] Baseline security score (E8-CAT, PingCastle, or module-appropriate tool)
+- [ ] Gap analysis against module completion criteria: is the agreed scope still the right scope?
+- [ ] Updated scope confirmation signed by client lead: proceed as scoped / amend scope / escalate
+- [ ] Week 2 plan with explicit client approval of any changes to be made
+
+---
+
+## Integration With Existing Frameworks
+
+| Document | Integration |
+|----------|-------------|
+| [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic methodology, questionnaires, and report structure |
+| [Modular Engagements](modular-engagements.md) | Module descriptions, durations, investment levels, and completion deliverables |
+| [Move Fast and Fix Things](move-fast-and-fix-things.md) | The Brownhat methodology and engagement posture that underlie Section 7 |
+| [Sovereign Communications](../playbooks/sovereign-communications.md) | Delta Chat out-of-band channel setup referenced in Section 6 |
+| [Retained Capability](retained-capability.md) | The retained relationship model described in Section 2 |
+| [Business Case Template](../playbooks/business-case-template.md) | ROI and risk quantification framework for the pricing conversations in Section 5 and 7 |
+| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | Executive communication scripts that complement the engagement framing in this document |
+| [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) | The commercial partnership doctrine and the "existing tools first" principle referenced in Section 5 |
+
+---
+
+*For the entry assessment, see [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md).*
+*For the module menu, see [Modular Engagements](modular-engagements.md).*
+*For financial justification, see [Business Case Template](../playbooks/business-case-template.md).*
+
+> *Sections 1–6 of this document are client-facing. A Czech translation for use with Czech-speaking clients is planned as `engagement-model-cs.md`.*

antifragile-consulting/core/executive-summary-cs.md

@@ -0,0 +1,76 @@
+# Antifragilní podnik — Výkonné shrnutí
+
+> *Pro představenstvo, generálního ředitele a vedení společnosti. Jedna strana. Pět minut. Rozhodnutí, které určí, zda organizace přežije svůj příští otřes.*
+
+---
+
+## Problém v jedné větě
+
+Vaše organizace se v tuto chvíli podílí na **rozsáhlém neplacené výzkumu pro konkurenci** — odesílá vlastnická data, strategické uvažování a provozní informace do cloudových platforem, které mají zájem na znehodnocení vašeho odvětví.
+
+## Co je v sázce
+
+| Kategorie aktiv | Současné riziko | V případě kompromitace nebo zcizení |
+|----------------|----------------|--------------------------------------|
+| Strategické zpravodajství | Pronajato od poskytovatelů cloudové AI | Konkurenti kopírují vaši výhodu; vaše strategie se stává veřejnými trénovacími daty |
+| Důvěra zákazníků | Chráněna formálními procesy | Regulatorní pokuty, odpovědnost za škody, nevratné poškození reputace |
+| Provozní kontinuita | Závislá na stabilitě dodavatele | Jediná změna API nebo geopolitická událost zastaví procesy kritické pro příjmy |
+| Technické talenty | Plýtvají se na údržbu fragilních systémů | Vyhoření, odchody, neschopnost přilákat bezpečnostně orientované inženýry |
+| Regulatorní licence | Předpokládaná, ne prokázaná | DORA, NIS2, PSD2 a národní regulátoři nyní vyžadují prokazatelnou odolnost — ne papíry |
+
+## Antifragilní alternativa
+
+Antifragilní organizace nezahyne při otřesu. **Každý incident produkuje strukturální zlepšení. Každý neúspěch konkurence vytváří tržní příležitost. Každý regulatorní požadavek je splněn důkazy, ne sliby.**
+
+### Pět pilířů (v jazyce vedení)
+
+| Pilíř | Co vedení slyší |
+|-------|----------------|
+| **Strukturální oddělení** | „Nikdy nebudeme znovu rukojmím jednoho dodavatele, jeho ceníku, podmínek nebo existence." |
+| **Zachování opcí** | „Zachováváme si právo změnit směr za 90 dní, ne za 9 měsíců." |
+| **Přeměna stresu na signál** | „Každý neúspěch nás učiní chytřejšími a strukturálně silnějšími." |
+| **Svrchované zpravodajství** | „Naše proprietární data zlepšují naše vlastní modely, ne modely konkurentů." |
+| **Design asymetrického výnosu** | „Malé, cílené investice nás chrání před existenčními riziky." |
+
+## Strategický mandát: AI suverenita
+
+Současné paradigma AI je **extraktivní**. Každý dotaz odeslaný do cloudové AI učí tento systém, jak vás nahradit. Provozováním umělé inteligence na infrastruktuře, kterou kontrolujete, dosáhnete:
+
+- **Ochrany duševního vlastnictví** — nebude součástí veřejných trénovacích dat
+- **Provozní kontinuity** — bez závislosti na rozhodnutích dodavatele, geopolitice nebo změnách API
+- **Snížení dlouhodobých nákladů** — nepředvídatelné ceny za dotaz se změní na fixní infrastrukturní výdaje
+- **Prokázání regulatorní zralosti** — auditorům, kteří stále více prověřují umístění dat a rizika třetích stran
+
+> *„Kdyby podnikové zpravodajství vaší společnosti bylo hromadou fyzické hotovosti, uložili byste ji ve veřejné bance, která si účtuje 'tréninkový poplatek' z každé koruny a vyhrazuje si právo přes noc změnit měnu? Nebo byste ji uchovávali ve vlastním trezoru?"*
+
+Lokální AI je trezor.
+
+## Závazek na 180 dní
+
+Nenavrhuji tříletou transformaci. Navrhuji **čtyři fáze, 180 dní, měřitelné výsledky**:
+
+| Fáze | Časový horizont | Výsledek pro podnik |
+|------|----------------|---------------------|
+| **Hygiena** | Dny 0–30 | Viditelnost. Vidíme každou identitu, každé aktivum, každou mezeru, která by mohla společnost zničit. |
+| **Kontrola** | Dny 30–60 | Omezení. Zavíráme nejrizikovější expozici stávajícími nástroji — bez nových nákupů. |
+| **Suverenita** | Dny 60–90 | Vlastnictví. Přebíráme kontrolu nad proprietárními informacemi a ověřujeme schopnost zotavit se z incidentu. |
+| **Antifragilita** | Dny 90–180 | Výhoda. Přeměňujeme narušení na ponaučení a ponaučení na tržní pozici. |
+
+## Rámec investic
+
+Toto není nákladové středisko. Je to **pojistka zachování opcí**.
+
+- **Náklady programu**: Primárně konfigurace a procesy — nejprve se využívají stávající nástroje.
+- **Náklady nečinnosti**: Průměrná záchrana po útoku ransomwarem stojí 4,5 mil. EUR. Jedna pokuta dle DORA může dosáhnout 2 % celosvětového obratu. Jeden konkurent natrénovaný na vašich datech znehodnotí vaši proprietární výhodu.
+- **Návratnost investic**: Snížení rizika je viditelné do 30 dní. Regulatorní důkazy jsou prokazatelné do 90 dní. Konkurenční výhoda ze svrchovaného zpravodajství se kumuluje po dobu 12–24 měsíců.
+
+## Požadované rozhodnutí
+
+Potřebujeme **jednoho výkonného sponzora s pravomocemi**, **jedno setkání řídícího výboru týdně** a **toleranci k dočasným narušením** v prvních 30 dnech. Alternativou je pokračovat v provozu se skrytými závislostmi, nemapovanými riziky a strategií zpravodajství, která obohacuje konkurenci.
+
+---
+
+*Pro podrobný strategický argument viz [The Antifragile Manifest](antifragile-manifest.md).*
+*Pro průvodce konverzací s vedením viz [Průvodce rozhovorem s vedením](c-suite-conversation-guide.md).*
+*Pro finanční zdůvodnění viz [Šablona obchodního případu](../playbooks/business-case-template.md).*
+*Anglická verze: [Executive Summary](executive-summary.md)*

antifragile-consulting/core/executive-summary.md

@@ -73,3 +73,4 @@ We need **one executive sponsor with authority**, **one steering committee meeti
 *For the detailed strategic argument, see [The Antifragile Manifest](antifragile-manifest.md).*
 *For the board conversation guide, see [C-Suite Conversation Guide](c-suite-conversation-guide.md).*
 *For financial justification, see [Business Case Template](../playbooks/business-case-template.md).*
+*Česká verze: [Výkonné shrnutí](executive-summary-cs.md)*

antifragile-consulting/core/modular-engagements.md

@@ -68,6 +68,7 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
 
 **What is delivered**:
 - Full identity census: human accounts, service accounts, guests, enterprise apps
+- **CA policy register** (CAExporter export): readable documentation of every Conditional Access policy before any changes are made
 - MFA enforcement for 100% of users (conditional access with MFA for E3; risk-based conditional access and PIM for E5)
 - Legacy authentication blocked tenant-wide
 - Privileged access workstation (PAW) architecture for admins
@@ -189,6 +190,7 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
 
 **What is delivered**:
 - Full AD identity census with orphan and privilege analysis
+- **Elysium password audit**: weak and compromised credential check across all domain accounts; P0 remediation list for accounts on high-value attack paths
 - KRBTGT password rotation (if > 180 days stale)
 - LAPS deployment to all domain-joined workstations
 - Sysmon deployment with SwiftOnSecurity configuration
@@ -362,7 +364,7 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
 |-----------|--------|
 | **Typical duration** | 60-90 days |
 | **Typical investment** | Medium (labor; leverages existing Microsoft security stack) |
-| **Prerequisites** | Microsoft Defender (E5) or equivalent EDR; at least one security analyst; willingness to learn |
+| **Prerequisites** | An operational EDR — Microsoft Defender E5, CrowdStrike, SentinelOne, or open-source Wazuh+Sysmon (see [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) for the zero-cost path); at least one security analyst; willingness to learn |
 | **Standalone value** | Operating rhythm for SOC; first guided threat hunt; purple team charter; 12-month capability roadmap |
 | **Typical client** | Organizations that own E5/Defender/Sentinel but underutilize them; SOC drowning in noise; no hunt discipline; red and blue teams do not collaborate |
 
@@ -385,6 +387,72 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
 
 ---
 
+### Module 13: Privileged Access Architecture
+
+**The Access Control Module. Replace VPN Sprawl With a Two-Layer Architecture.**
+
+| Attribute | Detail |
+|-----------|--------|
+| **Typical duration** | 30-60 days |
+| **Typical investment** | Low to medium (labor; Teleport CE is free for qualifying clients; Tailscale is per-user commercial) |
+| **Prerequisites** | Administrative access to network infrastructure; identity provider (Entra ID, Okta, Google, or any OIDC provider) |
+| **Standalone value** | Legacy VPN replaced or supplemented; privileged access recorded; vendor access time-bounded and auditable |
+| **Typical client** | Any organisation with legacy VPN sprawl; OT clients with uncontrolled vendor remote access; post-breach clients needing access hardening |
+
+**What is delivered**:
+- Access architecture design: which layer handles network access, which handles protocol-aware PAM
+- Teleport CE or Enterprise deployment (SSH, RDP, Kubernetes, database proxying; session recording; JIT access)
+- Tailscale or Headscale + WireGuard deployment (network-level mesh access)
+- Access policy design: who reaches what, when, recorded how
+- Vendor access governance: time-bounded, request-approve-record workflow for all third-party access
+- Admin training and operational handover
+
+**Executive pitch**:
+
+> *"Your VPN gives everyone on it access to everything behind it. Your vendor credentials have not been rotated in two years. Your admins log into production servers from laptops they also use for email. In 30 days, we replace that with a system where every access request is approved, every session is recorded, and every credential expires the moment it is no longer needed. Your auditor will be able to watch a video of every administrative action ever taken on every critical server."*
+
+**Natural next modules**: Module 2 (Identity Security), Module 6 (On-Premise AD), Module 8 (OT Security)
+
+**See**: [Privileged Access Architecture](../playbooks/privileged-access-architecture.md)
+
+---
+
+### Module 14: Sovereign Communications
+
+**The Resilience Module. Communication That Survives an Incident.**
+
+| Attribute | Detail |
+|-----------|--------|
+| **Typical duration** | 1-5 days (Delta Chat chatmail); 2-10 days (Matrix/Element) |
+| **Typical investment** | Very low (€5-10/month infrastructure for Delta Chat chatmail relay; labor minimal) |
+| **Prerequisites** | None — this module has no technical prerequisites |
+| **Standalone value** | An operational out-of-band communication channel independent from corporate IT; tested and documented in the incident response plan |
+| **Typical client** | Any organisation whose incident response plan assumes Teams or email will be available; OT/utilities/telco operators; organisations with recent breaches or near-misses |
+
+**What is delivered**:
+
+*Tier 1 — Delta Chat (always delivered):*
+- Chatmail relay deployed on independent cloud infrastructure (10 minutes; €5-10/month)
+- Key personnel enrolled: incident response team, executives, OT operators (as applicable)
+- Out-of-band channel documented in incident response runbooks
+- Crisis channel tested with a simulated incident
+
+*Tier 2 — Matrix/Element (if full platform warranted):*
+- Synapse server deployed (CQRE-managed or client on-premises)
+- SSO integration (Entra ID, Okta, Google Workspace)
+- Persistent rooms configured for operational teams, incident response, management
+- Migration guide for users moving from Teams/Slack
+
+**Executive pitch**:
+
+> *"Your incident response plan says to use Teams. Teams runs on Microsoft's infrastructure, authenticated by your Active Directory, connected through your network. If any of those three things are the incident, your response channel is gone too. We deploy a €7/month server today — it takes ten minutes — that gives your entire response team an encrypted channel on their personal phones, completely independent from everything else you run. This is the cheapest, fastest risk reduction in this entire engagement."*
+
+**Natural next modules**: Module 7 (Recovery & Resilience), Module 8 (OT Security), Module 2 (Identity Security)
+
+**See**: [Sovereign Communications](../playbooks/sovereign-communications.md)
+
+---
+
 ## Module Selection Guide
 
 ### For the Client Who Knows Their Pain
@@ -404,22 +472,32 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
 | "We don't feel in control" | Module 11: Embedded Quality Assurance | 60-90 days |
 | "We own tools but can't use them" | Module 12: Blue/Purple Team Foundation | 60-90 days |
 | "Our outsourced SOC underperforms" | Module 12 (+ Retained Capability Audit) | 60-90 days |
-| "Mythos/AI will find all our vulnerabilities" | AI-assisted TVM Sprint | 30-90 days |
+| "AI-powered attackers will outpace our response" | AI-Assisted TVM Sprint | 30-90 days |
+| "Our VPN is a mess / vendors have too much access" | Module 13 (Privileged Access Architecture) | 30-60 days |
+| "We need a crisis communication channel" | Module 14 (Sovereign Communications) | 1-5 days |
+| "We don't know where to start" | Brownhat Diagnostic (NIST CSF Baseline) | 5-10 days |
 
 ### For the Client Who Does Not Know Where to Start
 
-**The Diagnostic Path**:
+**The Brownhat Diagnostic** — a paid, structured [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md):
 
-1. **Week 1: Kill Chain Assessment** (included in scoping; no charge)
-   - Interview stakeholders
-   - Identify the shortest path to organizational failure
-   - Recommend the module that closes the most critical gap
+1. **Two half-day workshops** with key stakeholders (CIO/CISO, IT lead, one business owner)
+   - No tools installed; no data collected from systems
+   - Structured questionnaire across all six NIST CSF 2.0 domains
+   - Produces an honest picture of current state, not a desired-state checklist
 
-2. **Module selection based on kill chain**:
+2. **Deliverables** (5 business days after workshop):
+   - Current state report: strengths, gaps, and kill chain analysis
+   - Prioritised module roadmap aligned to findings
+   - Up to 5 quick wins executable immediately with existing tools
+
+3. **Module selection based on kill chain**:
    - Kill chain starts with compromised endpoint → Module 1
    - Kill chain starts with stolen credentials → Module 2
    - Kill chain starts with unrecoverable systems → Module 7
    - Kill chain starts with OT bridge → Module 8
+   - Kill chain starts with uncontrolled vendor/privileged access → Module 13
+   - No out-of-band crisis comms capability → Module 14 (deploy immediately, 1 day)
 
 ---
 
@@ -429,14 +507,15 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
 
 ```
 Month 1-2:   Module 1 (Endpoint Management)
-              ↓ Discovers identity and AI gaps
-Month 2-3:   Module 2 (Identity Security)
+              ↓ Discovers identity and security configuration gaps
+Month 2-4:   Module 2 (Identity Security) + Module 3 (M365 Security Hardening)
+              [run in parallel — identity and configuration are different workstreams]
               ↓ Discovers compliance and data gaps
-Month 4-5:   Module 4 (Data Governance)
+Month 5-6:   Module 4 (Data Governance)
               ↓ Discovers AI shadow usage
-Month 5-6:   Module 5 (AI Sovereignty Bridge)
+Month 6-7:   Module 5 (AI Sovereignty Bridge)
               ↓ Discovers architectural fragility
-Month 7-12:  Module 10 (Red Team) + selected hardening
+Month 8-12:  Module 10 (Red Team) + selected hardening
 ```
 
 ### Path B: The Hybrid Infrastructure Organization
@@ -476,11 +555,13 @@ Month 5-7:   Module 2 (Identity Security) + Module 3 (M365 Hardening)
 Month 8-12:  Module 10 (Red Team) + continuous improvement retainer
 ```
 
-### Path E: The "Mythos / AI Vulnerability Panic" Organization
+### Path E: The "AI-Adversary" Organization
+
+*For clients whose leadership has recognized that AI-powered scanners, exploit generators, and vulnerability-discovery tools have permanently shortened the attacker's window.*
 
 ```
-Week 1-2:    AI-assisted TVM Baseline Sprint
-              ↓ Discovers actual exploitable attack surface; beats adversary AI to first move
+Week 1-2:    AI-Assisted TVM Baseline Sprint
+              ↓ Maps actual exploitable attack surface before adversary tooling does
 Month 1-2:   Module 1 (Endpoint Management) + Module 2 (Identity Security)
               ↓ Closes the highest-risk doors while AI TVM operationalizes
 Month 2-3:   Module 3 (M365 Security Hardening) + AI TVM operationalization
@@ -568,5 +649,95 @@ For clients ready to commit to a multi-module journey, offer **discounted bundle
 
 ---
 
+## Platform Adaptation: Non-Microsoft Environments
+
+The strategic framework, assessment methodology, and tool stack (Modules 6–12) are fully platform-agnostic. Modules 1–5 use Microsoft 365 as the primary reference environment because it is the dominant client footprint—but every module has direct equivalents on other platforms.
+
+**The principle never changes. The tool that implements it does.**
+
+### Module 1: Endpoint Management Foundation
+
+| Environment | Equivalent Tooling |
+|-------------|-------------------|
+| Microsoft (default) | Intune + Entra ID |
+| Apple-heavy | Jamf Pro or Kandji + Entra ID (BYOD) |
+| Mixed SMB | JumpCloud MDM or NinjaRMM |
+| Linux-heavy | Ansible + osquery (see [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md)) |
+| Multi-platform enterprise | VMware Workspace ONE or Ivanti |
+
+### Module 2: Identity Security
+
+| Environment | Equivalent Platform |
+|-------------|-------------------|
+| Microsoft 365 | Entra ID — Conditional Access, PIM, SSPR |
+| Google Workspace | Cloud Identity + BeyondCorp Enterprise |
+| Independent IdP | Okta (MFA, lifecycle), JumpCloud, or self-hosted Authentik |
+| AWS-native | IAM Identity Center + SCPs + CloudTrail |
+| Legacy/hybrid | Okta or Ping Identity as federation layer over AD |
+
+**The non-negotiables remain identical across all platforms**: MFA on every account, no shared admin credentials, least-privilege access, full audit logging, and PAW architecture for administrators.
+
+### Module 3: Security Hardening
+
+| Environment | Equivalent Approach |
+|-------------|-------------------|
+| Microsoft 365 | Secure Score + EOP + ASR rules + LAPS |
+| Google Workspace | Admin Security Health Advisory + Workspace Security Advisor + Alert Center |
+| AWS | Security Hub + Config Rules + GuardDuty + CloudTrail validation |
+| Multi-cloud | Prowler (covers AWS, Azure, GCP — see [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md)) |
+
+### Module 4: Data Governance and Compliance
+
+| Environment | Equivalent Tooling |
+|-------------|-------------------|
+| Microsoft 365 | Microsoft Purview (sensitivity labels, DLP, retention) |
+| Google Workspace | Google Vault + DLP + Drive labels |
+| Cloud-native | AWS Macie (data discovery) + S3 Object Lock (retention) |
+| Platform-agnostic | CISO Assistant (open-source GRC) for evidence tracking regardless of platform |
+
+### Module 5: AI Sovereignty Bridge
+
+| Environment | Approach |
+|-------------|---------|
+| Azure (default) | Azure OpenAI Service + Private Endpoints + Foundry |
+| AWS | Amazon Bedrock + VPC endpoints + AWS PrivateLink |
+| Self-hosted / sovereign | Ollama or vLLM + quantized open models (Llama 3, Mistral, Phi) |
+| Hybrid regulated | On-premise inference + Azure or AWS for burst capacity with data boundary controls |
+
+**The sovereignty test is the same regardless of platform**: Does your proprietary data leave your environment? Can you audit what the model sees? Can you operate if the provider goes down?
+
+### Path F: The Non-Microsoft Organization
+
+```
+Month 1-2:   Module 6 (On-Premise AD Hardening) if AD is present
+             — OR —
+             Module 2 equivalent (Okta / JumpCloud / Google Identity hardening)
+              ↓ Establishes identity foundation
+Month 2-3:   Module 1 equivalent (Jamf / JumpCloud MDM / Ansible endpoint management)
+              ↓ Establishes device visibility and compliance baseline
+Month 3-4:   Module 3 equivalent (Prowler cloud scan / Google Workspace hardening)
+              ↓ Closes misconfiguration and hardening gaps
+Month 5-6:   Module 8 (OT Security) if critical infrastructure
+             — OR —
+             Module 9 (Organizational Resilience) if development-heavy
+Month 7-12:  Module 10 (Red Team) + Module 12 (Blue/Purple Team Foundation)
+```
+
+**The Sovereign Tool Stack remains unchanged**: BloodHound, osquery, Prowler, CISO Assistant, Wazuh, TheHive, and the rest of the arsenal operate independently of Microsoft licensing.
+
+---
+
+## Integration With Existing Frameworks
+
+| Document | Integration |
+|----------|-------------|
+| [Rapid Modernisation Plan](../playbooks/rapid-modernisation-plan.md) | Each module maps to one or more rapid modernisation phases |
+| [Business Case Template](../playbooks/business-case-template.md) | Modular pricing structure; per-module ROI |
+| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | Modular pitching scripts and objection handling |
+| [M365 Antifragile Project](../playbooks/m365-antifragile-project.md) | Modules 1-5 map directly to M365 project workstreams |
+| [Antifragile Risk Register](../assessment-templates/antifragile-risk-register.md) | Each module closes a defined risk category |
+
+---
+
 *For the full 180-day rapid modernisation plan, see [Rapid Modernisation Plan](../playbooks/rapid-modernisation-plan.md).*
 *For module-specific tactical guidance, see the linked playbooks in each module description.*

antifragile-consulting/core/move-fast-and-fix-things.md

@@ -6,6 +6,27 @@ This document anchors the antifragile consulting practice in a single, actionabl
 
 ---
 
+## The Brownhat Methodology
+
+This practice operates under the **Brownhat** brand when engaging clients. The name is deliberate:
+
+- **Brownfield** — industrial land that has been used, built on, and left with the legacy of past decisions. Every mature organisation's security environment is a brownfield: layers of partially implemented tools, forgotten configurations, and "temporary" solutions that became permanent.
+- **Blackhat / Whitehat** — the security domain's language for attackers and defenders. Brownhat sits between them: we understand how attackers think, but we are here to recultivate the environment, not exploit it.
+
+> *"Brownhat is not a methodology for greenfield deployments. It is for organisations that have been building, acquiring, and running for years — and need someone to recultivate what they have before adding anything new."*
+
+**What Brownhat signals to clients**:
+- We are not going to sell you a new platform to replace the one you already own.
+- We are going to understand your environment as it actually is, not as it was designed to be.
+- We are going to extract maximum value from existing investments before recommending anything new.
+- We are going to be honest about what you have, what it costs, and what it would take to fix it.
+
+The Brownhat Diagnostic — a structured [NIST CSF 2.0 baseline assessment](../assessment-templates/nist-csf-baseline.md) — is the named entry engagement for new clients. It is how we earn the right to recommend anything.
+
+---
+
+---
+
 ## The Philosophy
 
 ### Speed Is a Security Control

antifragile-consulting/core/retained-capability.md

@@ -248,6 +248,35 @@ As an antifragile consultant, you do not replace the MSSP. You make the MSSP eff
 
 ---
 
+## AD Security: The Continuous Monitoring Tier
+
+A one-time Active Directory security audit (Module 6) produces a point-in-time snapshot. AD environments drift — new accounts are created, service account passwords stop rotating, privileged groups accumulate members. Retained clients should have a **continuous monitoring tier** for AD security posture.
+
+### The AD Continuous Monitoring Service
+
+| Attribute | Detail |
+|-----------|--------|
+| **Tool** | PingCastle (quarterly scoring) — suited for tracking progress over time in complex AD environments |
+| **Cadence** | Quarterly automated scan; score compared to previous quarter; trend report |
+| **What it catches** | New privileged account additions, stale configurations that creep back, KRBTGT age drift, new Kerberoastable SPNs, legacy protocol re-enablement |
+| **Deliverable** | Quarterly AD security score with delta from prior period; new findings prioritised by risk; confirmation of previously remediated items |
+| **Format** | Included in retained capability contract or as a standalone quarterly retainer |
+
+**The conversation**:
+
+> *"Your AD is clean now. We know — we just fixed it. But AD doesn't stay clean by itself. Admins create service accounts, Group Policy gets modified, privileged groups get members. In six months, without monitoring, it will drift back. We run PingCastle every quarter, trend the score, and tell you what changed before it becomes a problem again. This is the difference between a one-time fix and a lasting security posture."*
+
+### Recommended Retained Capability Stack (Post-Module 6)
+
+| Capability | Tool | Cadence |
+|-----------|------|---------|
+| AD security scoring | PingCastle | Quarterly |
+| AD attack path review | BloodHound (re-run) | Bi-annual or post-significant-change |
+| EntraID hybrid health | Forest Druid | Quarterly |
+| Privileged group membership | PowerShell/Entra audit | Monthly alert |
+
+---
+
 ## Integration With Existing Frameworks
 
 | Document | Integration |
@@ -256,6 +285,7 @@ As an antifragile consultant, you do not replace the MSSP. You make the MSSP eff
 | [Modular Engagements](modular-engagements.md) | Retained capability audit can be delivered as a standalone 30-day module; detection engineering cell build is a 60-90 day module |
 | [Antifragile Risk Register](../assessment-templates/antifragile-risk-register.md) | "Outsourced SOC with no retained detection engineering" is a T1 risk with extreme optionality impact |
 | [Business Case Template](../playbooks/business-case-template.md) | Retained capability ROI calculation |
+| [AD and Endpoint Hardening](../playbooks/ad-endpoint-hardening.md) | Module 6 produces the clean baseline; this document defines the retained service that keeps it clean |
 
 ---
 

antifragile-consulting/core/spontaneous-order-principles.md

@@ -138,13 +138,13 @@ The antifragile organization does not merely hope to survive the collapse of rig
 
 These five principles are not abstract philosophy. They are the reasoning behind every pillar of the antifragile manifest:
 
-| Principle | Manifest Pillar |
-|-----------|-----------------|
-| Order Without Control | [Stress-to-Signal Conversion](antifragile-manifest.md#pillar-3-stress-to-signal-conversion) |
-| Minimum Effective Control | [Asymmetric Payoff Design](antifragile-manifest.md#pillar-5-asymmetric-payoff-design) |
-| Flow Around Obstacles | [Structural Decoupling](antifragile-manifest.md#pillar-1-structural-decoupling) |
-| The Power to Opt Out | [Optionality Preservation](antifragile-manifest.md#pillar-2-optionality-preservation) |
-| Collapse Creates Advantage | [Sovereign Intelligence](antifragile-manifest.md#pillar-4-sovereign-intelligence) |
+| Principle | Manifest Pillar | The Connection |
+|-----------|-----------------|----------------|
+| Order Without Control | [Stress-to-Signal Conversion](antifragile-manifest.md#pillar-3-stress-to-signal-conversion) | Decentralized systems produce richer, more honest signals than controlled ones — an emergent failure is better information than a failure that was centrally prevented and therefore never studied |
+| Minimum Effective Control | [Asymmetric Payoff Design](antifragile-manifest.md#pillar-5-asymmetric-payoff-design) | Control costs should never exceed the risk they prevent; the asymmetric approach concentrates protection exactly where the payoff is disproportionate and removes it everywhere it only consumes speed |
+| Flow Around Obstacles | [Structural Decoupling](antifragile-manifest.md#pillar-1-structural-decoupling) | The decoupled organization has alternative paths already built; when one route is blocked by a vendor, regulation, or failure, it routes around — the tightly coupled one stops |
+| The Power to Opt Out | [Optionality Preservation](antifragile-manifest.md#pillar-2-optionality-preservation) | The ability to walk away from any relationship is the mechanism that keeps every option open; without it, every "option" is theoretical |
+| Collapse Creates Advantage | [Sovereign Intelligence](antifragile-manifest.md#pillar-4-sovereign-intelligence) | When rigid competitors collapse — because they depended on opaque vendors, rented their intelligence, or had no exit architecture — the organization with sovereign intelligence is positioned to absorb their customers, talent, and market share; you cannot benefit from a competitor's collapse if your own infrastructure depended on the same vendor that failed them |
 
 Together, they describe an organization that does not fight entropy. It surfs it.