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](../core/engagement-model.md) | The Module Completion Package defined in Section 5; sign-off process in Stage 5 |
| [Antifragile Risk Register](antifragile-risk-register.md) | Risk register update section feeds directly into the client's running register |
| [NIST CSF 2.0 Baseline Assessment](nist-csf-baseline.md) | Metrics baseline maps to the domain scores from the Brownhat Diagnostic |
| [Modular Engagements](../core/modular-engagements.md) | Next-module recommendation references the module menu |

---

*Use [Antifragile Risk Register](antifragile-risk-register.md) for the full risk register format and taxonomy.*
*For worked examples of completed risk register entries, see [Risk Register Example](risk-register-example.md).*