antifragile/antifragile-consulting/core/engagement-model.md

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.

---

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 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 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. 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. 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.

---

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.

---

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	The Brownhat Diagnostic methodology, questionnaires, and report structure
Modular Engagements	Module descriptions, durations, investment levels, and completion deliverables
Move Fast and Fix Things	The Brownhat methodology and engagement posture that underlie Section 7
Sovereign Communications	Delta Chat out-of-band channel setup referenced in Section 6
Retained Capability	The retained relationship model described in Section 2
Business Case Template	ROI and risk quantification framework for the pricing conversations in Section 5 and 7
C-Suite Conversation Guide	Executive communication scripts that complement the engagement framing in this document
Sovereign Tool Stack	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. For the module menu, see Modular Engagements. For financial justification, see Business Case Template.

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.