feat: Add findings backlog as pragmatic alternative to risk register

New: assessment-templates/findings-backlog.md
  Design principles: lives where client works, every finding has an owner,
  feeds the housekeeping stream, accumulates from all sources.
  Format: 6-field minimal entry (ID, finding, source, priority, owner,
  status) with optional target date/effort/notes/closed date.
  P0/P1/P2 priority using kill chain test.
  Flat file template for Git-based clients.
  Population guide: Day 30 (from Brownhat), subsequent modules, continuous
  tools (ASTRAL drift, PULSAR alerts, Elysium, BloodHound).
  Monthly housekeeping cycle structure.
  Relationship to formal risk register explained.
  Backlog health indicators (warning signs it is not functioning).

Wired into existing framework:
  move-fast-and-fix-things.md: Rule 4 now names the backlog as the queue
  rapid-modernisation-plan.md: Day 30 item 7 and Phase 1 action updated
  engagement-model.md: Section 4 deliverables table updated at all stages
  assessment-templates/README.md: Production-ready templates section added
  index.md: Findings Backlog added to Assessment and Tools table

Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
This commit is contained in:
Claude Sonnet 4.6
2026-06-05 10:09:08 +00:00
parent 6162bb474f
commit 5c4e91179d
5 changed files with 21 additions and 9 deletions
@@ -211,11 +211,11 @@ Each module documents its prerequisites in detail in [Modular Engagements](modul
| 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 |
| Brownhat Diagnostic | Current-state assessment report (6-domain, kill chain, quick wins) + prioritised module roadmap + **findings backlog opened** (all diagnostic findings entered with P0/P1/P2 priority and named owner) |
| Module kickoff | Written scope agreement; access checklist confirmation; communication channel setup; backlog reviewed and updated with module-specific prerequisites |
| Weekly (during delivery) | Change log update; check-in summary (decisions made, items pending, risks); backlog items resolved this week noted |
| Module completion | Configuration baseline document; scripts/rules in client repository; operating runbooks; **backlog updated** (items closed with evidence, new findings added); risk register update where one exists; metrics baseline; next-step recommendation |
| Retained relationship | Monthly advisory summary or capability review report; **backlog health review** (P0 count, items closed this cycle, blockers) |
**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.
@@ -107,7 +107,7 @@ Housekeeping is not janitorial work. It is attack surface reduction at a structu
- Firewall rules added for temporary access that became permanent
- Old GPOs, old admin rights, old certificates
**The engagement implication**: Every module scoping conversation must include a housekeeping component. It is not optional and not deferrable. The client names a resource, a cadence (minimum monthly), and a queue. The queue is populated from module findings and from continuous discovery. Progress is tracked and reviewed at every steering committee. If there is no resourcing for housekeeping, the engagement model must reflect that — because every fix we make will be partially undone within 18 months by new accumulation if the stream does not exist.
**The engagement implication**: Every module scoping conversation must include a housekeeping component. It is not optional and not deferrable. The client names a resource, a cadence (minimum monthly), and a queue. The queue is the [Findings Backlog](../assessment-templates/findings-backlog.md) — the single place where every finding from every diagnostic and module lands, prioritised, owned, and tracked to closure. The backlog is populated from module findings and from continuous discovery tools (ASTRAL drift, PULSAR alerts, quarterly BloodHound and Elysium runs). Progress is tracked and reviewed at every steering committee. If there is no resourcing for housekeeping, the engagement model must reflect that — because every fix we make will be partially undone within 18 months by new accumulation if the stream does not exist.
---