15 KiB
Findings Backlog
"A finding without a home is a finding that will never be fixed. The risk register is the right home. The backlog is the one that actually exists."
The Problem This Solves
Every assessment, module, and engagement produces findings. Some get fixed immediately. Most do not. In organisations with mature risk management, findings go into a risk register, get assigned owners, get reviewed quarterly, and get closed over time.
In practice, most organisations do not have a working risk register. They have a template someone downloaded, a spreadsheet that was last updated during the ISO 27001 attempt three years ago, or a GRC tool that nobody logs into. Findings that go into these systems disappear.
The findings backlog is the pragmatic alternative. It is not a replacement for a formal risk register — it is the lightweight, maintainable system that fills the gap between "finding documented in a report" and "finding tracked to closure." For organisations that eventually build a working risk register, the backlog feeds into it. For organisations that never do, the backlog is their risk register in all but name.
Deployment Options
Three options, in order of preference. Choose based on what the client will actually open.
Option 1 — Azure DevOps Work Items (recommended for ASTRAL clients)
If ASTRAL is deployed, the client already has an ADO project. Work Items are built in — no additional tooling, no additional cost, same context as the ASTRAL drift PRs and restore pipeline. This is the default.
Setup: Create a Work Item type called "Security Finding" (or use the built-in Bug or Task type with a tag). Create a board with columns: New → Triaged → In Progress → Blocked → Closed. Add custom fields: Priority (P0/P1/P2), Source (Brownhat / BloodHound / Elysium / ASTRAL / PULSAR / Module N), and Target Date.
Why it works: Consultants who are already reviewing ASTRAL drift PRs see the backlog in the same tool. The client's IT lead who owns remediation works in the same project. No context switching.
Teams tab: Pin the ADO board directly into the relevant Teams channel as a tab — built into the Azure DevOps app for Teams, no additional setup. The IT lead who lives in Teams can view and update Work Items without opening ADO in a browser. This is the recommended surface for non-technical owners: it is always visible, requires no context switch, and keeps the canonical data in ADO.
Power Automate (optional): If you need to push notifications into Teams or create tasks in Planner when a P0 item is opened or a target date is missed, Power Automate can bridge ADO to the M365 ecosystem. This adds complexity and a dependency on Power Automate flows — use it only if the Teams tab alone is not driving the right behaviour. There is no native ADO → Planner sync without Power Automate.
ASTRAL integration: When ASTRAL raises a drift PR for an unauthorised configuration change that cannot be immediately restored, link the ADO Work Item to the ASTRAL PR. The PR description, the before/after diff, and the reviewer decision are all in the same project — the Work Item is the remediation task, the ASTRAL PR is the evidence.
Option 2 — CISO Assistant (upgrade path for clients building toward GRC)
CISO Assistant is an open-source GRC platform already in the Sovereign Tool Stack. It provides risk register functionality, compliance framework mapping (NIS2, ISO 27001, DORA), evidence tracking, and audit-ready reporting — all self-hosted.
When to use it instead of ADO Work Items: When the client has an intent to build a formal risk management programme and needs a tool that can grow into it. CISO Assistant bridges the gap between a pragmatic backlog and a formal risk register: the same findings that start as backlog items can be promoted to documented risks with treatment plans, residual risk assessments, and compliance evidence links.
How the backlog feeds CISO Assistant: During each module, findings are entered into the backlog in ADO or a flat file. At quarterly review, P1 and significant P2 items that are not yet closed are promoted to CISO Assistant as risk entries with the evidence collected during the engagement. The backlog is operational; CISO Assistant is the strategic record.
Deployment: Docker Compose, ~30 minutes. Self-hosted on the client's infrastructure or on a VPS. See the sovereign tool stack for deployment guidance.
Option 3 — Git flat file (fallback for clients without ADO or preference for simplicity)
A Markdown file committed to the same repository as ASTRAL (or a dedicated security repository). Zero additional tooling. Fully auditable via Git history. Works offline.
When to use it: Clients who have the technical capability to maintain a Markdown file in Git and prefer minimal tooling. Also useful as a transitional format before ADO Work Items are fully configured.
Limitation: No native assignment notifications, no Planner sync, no board view. Progress is visible only to people who look at the repository. For clients where the IT lead needs to be nudged, a flat file will be ignored. Use ADO Work Items or CISO Assistant instead.
The flat file template is provided below.
Design Principles
It must live where the client actually opens things. If the backlog is in a tool the client never looks at, it does not exist. The three options above are ordered by likelihood of adoption. ADO Work Items wins because ASTRAL is already there — the path of least resistance is the path most likely to be walked.
Every finding has an owner. A finding without a named owner is not tracked — it is archived. The owner does not need to be the person who fixes it. They need to be the person who is accountable for whether it gets fixed.
Priority drives the housekeeping stream. The backlog is the input queue for Rule 4 (housekeeping as a permanent stream). The monthly housekeeping cycle picks from the backlog, resolves what it can, and updates statuses. Without the backlog, the housekeeping stream has no queue to work from.
It accumulates from all sources. Every diagnostic, every module, every ASTRAL drift alert, every PULSAR-flagged event, every BloodHound finding, every Elysium result feeds the backlog. Not just the big assessments. The backlog is the single source of truth for everything that has been found and not yet fixed.
The Format
A minimal backlog entry has six fields. Do not add more until the client is actually maintaining this one.
| Field | What it contains |
|---|---|
| ID | Sequential identifier (B-001, B-002…). Never reuse an ID. |
| Finding | One sentence: what is wrong. Not "review accounts" — "47 user accounts belong to staff who have left; credentials remain valid." |
| Source | Which assessment or tool produced this: Brownhat Diagnostic, BloodHound, Elysium, ASTRAL drift, PULSAR alert, Module 6, etc. |
| Priority | P0 / P1 / P2 — using the kill chain test (see below) |
| Owner | Named person, not a team. "AD Team" is not an owner. "Marek Novák" is. |
| Status | Open / In Progress / Blocked / Closed |
Optional fields that add value once the basic discipline is established:
| Field | What it contains |
|---|---|
| Target date | The date by which this should be resolved. Not when the project ends — when this specific item should be done. |
| Effort | S / M / L — rough estimate; S = fixable in a day or less, M = a few days, L = needs planning |
| Notes | Blockers, context, related items, change window requirements |
| Closed date | When it was actually closed. Important for demonstrating progress to auditors. |
Priority Assignment
Use the kill chain test from the Consultant Field Guide:
P0 — Kill chain node. If exploited, the organisation fails to operate. Fix before anything else. Examples: admin accounts without MFA, unpatched internet-facing system with known active exploit, backup that has never been restored, KRBTGT password over 365 days old.
P1 — Material damage. If exploited, significant harm results but the organisation survives. Fix within the current engagement. Examples: service accounts with non-expiring passwords, open RDP from internet, legacy authentication not blocked, stale privileged accounts.
P2 — Should be fixed. Real finding, real risk, but not existential. Goes into the housekeeping queue for the next available cycle. Examples: weak password policy on non-privileged accounts, missing DNS security filtering, unreviewed firewall rules from two years ago, undocumented vendor access with low privilege.
On priority inflation: The most common backlog failure is everything being marked P0. If everything is urgent, nothing is. Be ruthless. An environment with more than 5–10 P0 items either has a genuinely catastrophic security posture (in which case the immediate conversation is with the executive sponsor) or the priority assignments are wrong.
Backlog Template (Flat File Version)
For clients whose teams work in a repository (preferred — the backlog lives alongside ASTRAL):
# Findings Backlog
Last reviewed: [DATE] | Owner: [NAME] | Next review: [DATE]
## P0 — Kill Chain (fix immediately)
| ID | Finding | Source | Owner | Status | Target |
|----|---------|--------|-------|--------|--------|
| B-001 | | | | | |
## P1 — Material Risk (fix this engagement)
| ID | Finding | Source | Owner | Status | Target |
|----|---------|--------|-------|--------|--------|
| B-010 | | | | | |
## P2 — Housekeeping Queue (monthly cycle)
| ID | Finding | Source | Owner | Status | Target |
|----|---------|--------|-------|--------|--------|
| B-100 | | | | | |
## Closed
| ID | Finding | Closed date | Closed by |
|----|---------|-------------|-----------|
| | | | |
Use ID ranges to signal priority at a glance: B-001–B-009 for P0, B-010–B-099 for P1, B-100+ for P2.
Populating the Backlog
On Day 30 (from the Brownhat Diagnostic)
The Brownhat Diagnostic produces the first population of the backlog. Every finding from the diagnostic gets an entry. Quick wins that are closed immediately during the engagement go straight to Closed with the closing date. Everything else — including findings the client acknowledges but cannot act on immediately — goes into the backlog with the appropriate priority.
The consultant populates the initial backlog as part of the diagnostic deliverable. It is not a separate engagement. It is what happens to findings instead of filing them in a PDF.
From subsequent modules
Every module completion package includes an update to the backlog:
- Findings that were closed by the module move to Closed
- New findings discovered during the module are added
- The risk register update in the module completion package cross-references the backlog IDs
From continuous tools (ASTRAL, PULSAR, Elysium)
- ASTRAL — when a drift PR is raised for an unauthorised configuration change, a backlog entry is created if the change is not immediately remediated. The ASTRAL PR link goes in the Notes field.
- PULSAR — when an alert is investigated and reveals a structural gap (not just an event), a backlog entry is created. The PULSAR event ID goes in the Notes field.
- Elysium (quarterly run) — each new compromised or weak credential that cannot be immediately reset gets a backlog entry.
- BloodHound (quarterly run) — new or persistent attack paths get backlog entries with the path description.
The Housekeeping Cycle
The monthly housekeeping cycle (Rule 4 of Move Fast and Fix Things) works from the backlog. The cycle has a simple structure:
- Review open P0 items. If any P0 is still open and not blocked by an external dependency, it is the first priority. If it has been open more than 30 days without progress, it escalates to the executive sponsor.
- Work P1 items. Each cycle resolves at least one P1 item. If no P1 items are being resolved, the housekeeping stream is not functioning — find the blocker.
- Advance P2 items. Move through the P2 queue at the capacity available. Not every cycle will close P2 items. Every cycle should move at least one P2 item to In Progress.
- Review and reprioritise. As the environment changes, priorities shift. A P2 item that has been open for six months may be a P0 in disguise if nothing above it has been fixed.
- Update statuses. Every item touched in the cycle gets a status update, even if the update is "Blocked — waiting for change window."
The output of each cycle is a one-page summary: items closed this cycle, items In Progress, blockers, and the current P0/P1 count. This summary goes to the named client lead. If retained capability is in scope, it goes to the CQRE consultant as well.
Relationship to the Risk Register
If the client has a working risk register, the backlog and the risk register coexist:
- The backlog is operational — it is where findings live while they are being worked
- The risk register is strategic — it captures the risk that the finding represents, the treatment decision, and the residual risk after treatment
- When a P0 or P1 item is closed, the consultant works with the client to create or update the corresponding risk register entry with the closure evidence
If the client does not have a working risk register, the backlog is effectively doing the risk register's job at a reduced level of formality. Do not pretend otherwise. If the client ever needs to demonstrate risk management to a regulator or auditor, the backlog — with its closure dates, ownership, and priority history — is defensible evidence. A GRC tool with empty fields is not.
For clients who want to build a proper risk register: the backlog entries, once they have closure evidence attached, become the input for the risk register's treatment and closure records. The backlog is not wasted effort — it is the work that feeds the register.
Backlog Health Indicators
These are warning signs that the backlog is not functioning:
| Indicator | What it means |
|---|---|
| P0 items open for more than 30 days with no progress | Executive escalation required; a P0 that nobody is moving is a political problem, not a technical one |
| More than 20 items in the backlog with no owner | The backlog was populated but not handed over properly; go back and assign owners |
| No items closed in the last monthly cycle | The housekeeping stream is not running; find the responsible person and re-establish the cadence |
| All items are P2 | Priority inflation has happened in reverse; the consultant needs to revisit severity assignments |
| The backlog has not been updated since the last engagement | The backlog is a report, not a system; the client has reverted to treating findings as documentation rather than as work |
Related: Module Completion Report — each module updates the backlog as part of its completion package. Related: Antifragile Risk Register — the formal risk register template; the backlog feeds into it. Related: Move Fast and Fix Things — Rule 4 — the backlog is the queue that Rule 4 works from. Related: Engagement Model — backlog setup is part of every module kickoff.