Sort each finding by its cause: a tool gap, a process gap, a knowledge gap or an ownership gap. The category tells you the kind of fix. Buying a tool does not repair a missing decision owner, and training does not repair a missing inventory. Four buckets and one question per finding are enough.
Why categorize
After a tabletop the notes list contains things like "did not know who could block the package" and "no list of CI secrets." Treating all of them as tasks produces a long backlog with no pattern. Sorting by cause shows where the effort should go and prevents the common mistake of answering every finding with training or with software.
CISA's exercise packages include an After Action Report template, so there is a place to record findings. The sorting below is a layer you add on top.
The four buckets
| Bucket | Meaning | Typical sign | Typical fix |
|---|---|---|---|
| Tool | The capability does not exist or cannot be reached | "We cannot search all repos for a version" | Build, configure or buy the capability |
| Process | A step is missing, unclear or in the wrong order | "We argued about who declares an incident" | Write or change the runbook, set decision rules |
| Knowledge | The step exists, people do not know it | "I did not know we had a mirror" | Short briefing, cold read, drill |
| Ownership | Nobody is accountable | "Everyone thought someone else would rotate keys" | Name an owner and a backup |
One question per finding
Ask: "If the right person had been in the room and knew the plan, would this still have gone wrong?"
- If yes and the cause is missing capability, it is a tool gap.
- If yes and the cause is a missing or muddled step, it is a process gap.
- If no, because someone present could have done it, it is a knowledge gap.
- If nobody could be named, it is an ownership gap.
Some findings sit in two buckets. Pick the one that, if fixed, removes the problem. Note the second one as a follow-on.
Example findings
| Finding | Bucket | Fix |
|---|---|---|
| No place to search SBOMs or lockfiles together | Tool | Central inventory, with a named owner |
| No rule for when to freeze deploys | Process | Decision guide with end conditions |
| Engineers unaware the mirror can block versions | Knowledge | Walkthrough and a cold read of the runbook |
| Nobody owns CI credentials | Ownership | Assign owners, record in the credential list |
Prioritize with two lenses
For each finding, rate how much time it cost in the exercise and how often it would recur in a real incident. Start with high cost and high recurrence. Fix ownership gaps early because they are cheap and unblock others.
Cap the list. Take three to five findings per exercise, give each an owner and a date, and revisit them at the next session. The scoring rubric helps you decide which areas to retest.
Avoid blame in the wording
Write findings about the system, not the person. "The runbook does not say who can block a package" is useful. "Alex did not know the process" is not. Blameless wording keeps people honest in future exercises.
Quick check
What if a finding is both a tool and a process gap?
Pick the cause that removes the problem if fixed, and list the other as a follow-on task.
Do all findings need a fix?
No. Some are accepted risks. Record that decision, the owner and a date to revisit.
Safeguard can help with the inventory side of this work. SBOM and dependency scanning show where a package and version appear across your projects, and policies and gates can stop a flagged version at the pull request. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
