Extracting Missing Capabilities

The Export Backlog button on the results screen downloads a Markdown checklist of every capability the assessment identified as not yet in place. This page explains what the export contains, how it handles prerequisite ordering, and how to import it into common backlog tools.


What the backlog export is

The summary export (.txt) gives domain-level percentages. The backlog export goes deeper: it lists specific, actionable capabilities — one per line — ready to be turned into individual tickets.

Clicking Export Backlog downloads SRF-Backlog-YYYY-MM-DD.md. Each line in the file corresponds to a single capability that is not yet in place, grouped by domain and then by sub-domain and axis. The file is a GitHub-flavoured Markdown checklist — every item is an unchecked - [ ] task that renders as an interactive checkbox in any Markdown viewer, issue tracker, or wiki that supports GFM.


What the output looks like

Below is an example section of the exported file, showing entries across two domains. The format is consistent throughout:

Each line contains four pieces of information:

  • The sub-domain name (bold) — where in the framework this capability sits
  • The axis (Detection, Mitigations, or Response) — which dimension of reliability it addresses
  • The capability label — the specific control that is not yet in place

Prerequisite ordering

The export respects the framework's prerequisite model. A capability only appears in the gap list if its prerequisites are already satisfied. This means the file naturally prioritises foundational capabilities: items that appear near the top of a domain section are the ones you need to address first.

For example, if you have not yet established basic resource monitoring, "automated anomaly detection alerts" will not appear as a gap item — because the monitoring prerequisite gap appears first. As you implement foundational capabilities and re-run the assessment, higher-level gaps will appear in subsequent exports. The backlog file therefore becomes more complete over time as foundations are laid.

This behaviour has a practical consequence when importing into a backlog tool: the order of items within each domain section is meaningful. Treat items earlier in a section as higher-priority than those later in the same section, all else being equal.


Importing into Jira

  1. Download SRF-Backlog-YYYY-MM-DD.md.
  2. Open a new Epic — for example, "SRF Reliability Improvements — Q2 2026".
  3. Copy individual - [ ] ... lines and create one Jira story per capability gap. The capability label becomes the story title.
  4. Use the domain heading (e.g. "Infrastructure") as the Epic label or component so stories are groupable by domain.
  5. Use the axis tag (Detection, Mitigations, or Response) as a story label — this makes it possible to filter and plan sprints around a specific axis. Mitigations stories typically deliver the highest reliability improvement per unit of effort.
  6. Set story points based on your team's estimate of implementation effort. Architecture work (Mitigations) tends to be larger than monitoring or runbook work (Detection, Response).

For large programmes with many gaps across multiple domains, create one Epic per domain rather than a single umbrella Epic. This keeps work scoped, reviewable, and attributable to a team or squad.


Importing into Linear

  1. Download the .md file.
  2. In Linear, create a new Project — for example, "SRF Remediation".
  3. Use Linear's Import from file feature (Settings → Import) and select the .md file. Linear parses GitHub-style task lists and creates one issue per - [ ] line.
  4. Review the imported issues and assign them to the relevant team or cycle.
  5. Use labels to capture the axis (Detection, Mitigations, Response) and the domain — these can be applied in bulk after import using Linear's multi-select.

Importing into GitHub Issues

  1. Download the .md file.
  2. Open a new GitHub Issue titled "SRF Reliability Gaps — [date]".
  3. Paste the entire file content into the issue body. GitHub renders - [ ] syntax as interactive checkboxes — you can check items off directly in the issue as capabilities are implemented.
  4. Use the issue as a programme-level tracking checklist. The overall completion percentage is visible in the issue list without opening the issue.
  5. For larger programmes, create one issue per domain and paste only the relevant domain section into each. This keeps individual issues manageable and makes it straightforward to assign domain issues to the team responsible for that area.

Prioritising the gap list

Not all gaps are equal. When triaging the backlog file, apply the following priority signals:

Axis priority

Address Mitigations gaps before Detection and Response gaps wherever the implementation effort is comparable. The industry-wide average for Mitigations is 1.1 out of 4.0 — substantially lower than Detection (1.8) or Response (1.6). Every Mitigations capability you implement converts a potential incident into a non-event: the system absorbs the failure rather than requiring detection and response to contain it.

Detection and Response improvements are valuable — but they reduce the cost of incidents. Mitigations improvements reduce the frequency of incidents.

Domain priority

Infrastructure (responsible for 28% of incidents in the dataset) and Database (17%) carry the most weight in the overall grade and have the highest real-world impact. If your gap list is long, prioritise Infrastructure and Database Mitigations first. Closing gaps in these two domains will move your overall grade more than equivalent effort in lower-weight domains.

Top Improvement Areas

The seven sub-domains listed in the Top Improvement Areas section of the results screen are ranked by score — these are your most acute gaps. Look for those sub-domain names in your backlog file and address their capabilities before moving to sub-domains that are already partially complete.

Prerequisite chains

Items that appear near the top of a domain section in the export are foundational. Implementing them unlocks additional capabilities in the assessment — when you re-run the assessment after implementing prerequisites, new gap items will appear that were previously hidden by the prerequisite logic. Plan at least one reassessment per quarter if you are actively working through a remediation programme.