antifragile/antifragile-consulting/assessment-templates/module-completion-report.md

Module Completion Report

Copy this template for each completed module. Remove all guidance notes (lines in italics or blockquotes) before sharing with the client. Fill every section — a section left blank signals incomplete delivery.

---

Client:           [Organisation name]
Module:           Module [N] — [Module name]
Engagement start: [Date]
Completion date:  [Date]
Consultant lead:  [Name]
Client lead:      [Name, role]
Report version:   1.0

---

Executive Summary

One page. Written for the executive sponsor, not the IT lead. No technical jargon. Lead with the business outcome, not the technical activity.

What was done: [One sentence describing the module in plain language. E.g., "We audited, cleaned, and hardened your Active Directory environment, eliminating the most direct attack paths to organisational failure."]

Risk closed: [One sentence on the primary risk addressed. E.g., "A compromised standard user account can no longer reach Domain Admin in fewer than 12 steps; previously it could in 3."]

Before/after: [Key metric comparison. E.g., "BloodHound attack paths to Domain Admin: 4,217 → 23. PingCastle score: 52 → 81. Kerberoastable service accounts: 14 → 2."]

Outstanding items: [Any P0 or P1 risks identified during the module that are not yet closed. Be specific. If none, state "None."]

Recommended next step: [One sentence on the logical next module and why now. E.g., "Module 2 (Identity Security) should follow within 60 days to extend the clean AD foundation into Entra ID and enforce MFA for all users."]

---

Scope

Agreed scope (from kickoff)

Copy the completion criteria from the scope agreement signed at kickoff.

Deliverable	Completion criterion	Status
[Deliverable 1]	[Verifiable condition]	✅ Complete / ⚠️ Partial / ❌ Not completed
[Deliverable 2]	[Verifiable condition]	✅ Complete / ⚠️ Partial / ❌ Not completed
[Deliverable 3]	[Verifiable condition]	✅ Complete / ⚠️ Partial / ❌ Not completed

For any Partial or Not Completed item, explain briefly in the section below.

Scope changes

Document any scope changes accepted during delivery. For each: what changed, why, and whether a change order was issued.

Change	Reason	Change order issued?
[Change description or "None"]

Out-of-scope items discovered

Items found during the engagement that are outside this module's scope but should be tracked. These feed into the risk register update.

Finding	Risk tier	Recommended module
[Finding or "None"]

---

Change Log

Every change made during the engagement, in the order made. Date, what changed, why, and the client approval reference (name of person who approved and date). This log is the permanent audit record.

Date	System / Component	Change made	Rationale	Approved by
[DD Mon YYYY]	[System]	[Specific change]	[Why this was needed]	[Name, date]

If the change log is very long (>20 items), summarise by category here and attach the full log as a separate file in the client repository.

---

Deliverables

Everything produced during this engagement that the client now owns. All files should already be in the client's repository. This section is a reference map.

Deliverable	Location	Format	Notes
Configuration baseline (pre-engagement state)	[repo path]	Markdown / JSON / CSV	Snapshot taken [date]
Configuration baseline (post-engagement state)	[repo path]	Markdown / JSON / CSV	Snapshot taken [date]
[Script / rule / query name]	[repo path]	PowerShell / Python / KQL / Sigma	[Brief description]
[Script / rule / query name]	[repo path]
Operating runbook	[repo path]	Markdown	See Section 6

Nothing produced during this engagement should require the client to contact CQRE to access or operate. If any deliverable requires our involvement to use, note it here and explain why — this is an incomplete handover.

---

Metrics Baseline

Before-and-after measurements that prove the work was effective. Choose metrics appropriate to the module. Avoid vanity metrics — only record what can be re-measured in the same way next quarter.

Metric	Before	After	Target	How measured
[Metric name]	[Value]	[Value]	[Value]	[Tool / method]
[Metric name]	[Value]	[Value]	[Value]	[Tool / method]
[Metric name]	[Value]	[Value]	[Value]	[Tool / method]

Module-specific metric suggestions:

• Module 1 (Endpoint): Intune enrolment %, E8-CAT maturity level, EDR coverage %
• Module 2 (Identity): MFA enforcement %, legacy auth sign-ins (target: 0), Global Admin count, Secure Score identity subcategory
• Module 3 (M365 Hardening): Secure Score overall, ASTRAL drift events (baseline), CA policy count (documented)
• Module 6 (AD Hardening): PingCastle score, BloodHound paths to DA, KRBTGT age (days), Kerberoastable SPNs, privileged account count
• Module 12 (Blue/Purple): TTP detection rate (%), MTTR (minutes), custom rules deployed, % of MSSP alerts with custom context
• Module 13 (Privileged Access): Accounts under PAM management %, session recording coverage %, JIT request volume (baseline)
• Module 14 (Communications): Enrolled participants in out-of-band channel, independence from corporate infrastructure confirmed (Y/N)

---

Risk Register Update

Risks closed this engagement

Each closed risk must have evidence — not just "we fixed it." Link to the specific change log entry, configuration export, or tool output that proves closure.

Risk ID	Risk name	Evidence of closure	Closed date
[AF-YYYY-NNN]	[Name]	[Evidence location]	[Date]

Risks remaining open

Risks identified before or during this engagement that are not yet closed. Include the priority, the recommended next step, and the suggested owner.

Risk ID	Risk name	Priority	Why still open	Recommended action	Owner
[AF-YYYY-NNN]	[Name]	P[0/1/2]	[Reason]	[Action]	[Name]

New risks identified during this engagement

Risks discovered during delivery that were not in the pre-engagement register. Add them to the full risk register and assign initial priority.

Risk ID	Risk name	Tier	Priority	Recommended module
[AF-YYYY-NNN]	[Name]	T[0-3]	P[0-2]	Module [N]

---

Operating Guide

How the client's team operates and maintains what was built. If a full runbook exists in the repository (it should), reference it here and summarise the key maintenance actions.

Runbook location: [repo path to runbook]

Maintenance calendar

Action	Who	Cadence	What triggers escalation
[Action, e.g. "Review ASTRAL drift alerts"]	[Role]	[Daily / Weekly / Monthly / Quarterly]	[Condition]
[Action]

Alert handling

For any monitoring or detection deployed in this module, describe what the client's team does when an alert fires.

Alert type	Initial response	Escalation threshold	Escalation path
[Alert, e.g. "LAPS password access outside business hours"]	[Response]	[When to escalate]	[Who to contact]

Who to contact

Remove the CQRE contact information if this report is being used in a context where it should not appear.

Situation	Contact	Channel
Operational question about deployed tools	[Client IT lead name]	[Contact method]
Alert requiring security decision	[Client security lead name]	Delta Chat out-of-band channel
Suspected incident	[CQRE contact name]	Delta Chat out-of-band channel

---

Next Steps

Recommended next module

Module [N]: [Name]

Rationale: [2–4 sentences explaining why this is the logical next step based on what was found in this engagement. Be specific — reference actual findings from the change log or risk register, not generic language.]

Suggested timeline: [When to start, based on the client's capacity and the urgency of the remaining open risks.]

Prerequisites already met by this engagement: [What this module produced that the next module depends on. E.g., "The clean AD baseline from this engagement is the required prerequisite for Module 2's PIM deployment."]

---

Sign-Off

Both parties should confirm the module is complete before the final invoice is issued. This section should be signed (physically or via email confirmation). Attach the email confirmation to this document if signing electronically.

Completion confirmed by (client):

Name:         ________________________________
Role:         ________________________________
Date:         ________________________________
Signature:    ________________________________

Completion confirmed by (CQRE):

Consultant:   ________________________________
Date:         ________________________________

Outstanding items accepted by client (if any completion criteria are partial):

If any items are marked Partial or Not Completed in the Scope table, the client must explicitly accept that the module is considered complete despite these items. Note what was agreed for each outstanding item.

Item:         ________________________________
Accepted by:  ________________________________
Resolution:   ________________________________
Date:         ________________________________

---

Integration With Existing Frameworks

Document	Integration
Engagement Model	The Module Completion Package defined in Section 5; sign-off process in Stage 5
Antifragile Risk Register	Risk register update section feeds directly into the client's running register
NIST CSF 2.0 Baseline Assessment	Metrics baseline maps to the domain scores from the Brownhat Diagnostic
Modular Engagements	Next-module recommendation references the module menu

---

Use Antifragile Risk Register for the full risk register format and taxonomy. For worked examples of completed risk register entries, see Risk Register Example.