Measure a supply chain drill with four numbers: time to scope the exposure, time to contain it, the share of systems and secrets with a named owner, and how many findings repeat from the last drill. Record them every time so you can compare runs, not judge one.
Why numbers help
A drill without measurements gives you opinions. "It went okay" cannot be compared with next quarter. Simple times and counts, recorded the same way each run, show whether the team is improving and where effort should go. Keep them modest: this is a learning tool, not a performance review.
The four core measures
| Measure | What it captures | How to record it |
|---|---|---|
| Time to scope | Minutes from the first inject until the team lists affected repositories, services and secrets | Scribe notes the start and the decision |
| Time to contain | Minutes until the team states what it would revoke, block or roll back, and who approves | Same method |
| Owner coverage | Share of affected items that had a named owner without searching | Count in the debrief |
| Repeat findings | Gaps that were also in the last after-action report | Compare reports |
Add one or two optional measures if useful: how many questions ended as "we do not know," and how many people were needed who were not in the room.
Define the clock before you start
Disagreements about when the timer begins ruin comparisons. Agree on this:
- Start: the moment the first inject is read.
- Scope done: the team gives a written list, not a verbal estimate.
- Contain done: the team names the specific actions, owners and approvals, even though nothing is changed in a tabletop.
In a functional drill where people actually run commands, record the real time of each command.
Read the numbers sensibly
- A fast time with a poor list is worse than a slow time with a complete one. Check quality first.
- A single slow step usually points to one cause, such as no inventory or one overloaded admin.
- Do not compare teams against each other. Different systems make times incomparable. Compare a team with itself.
- Look for trends over three runs, not one.
What to do with the results
Pick the slowest step and ask why. Common answers:
- No central dependency inventory, so scoping is manual.
- Secrets scattered across systems with no list.
- Approval depends on one person.
- Customer questions have no named responder.
Turn each into a corrective action in your after-action report, and rerun the same inject next time to see if the number moved. For a concrete scoping exercise, try the SBOM incident drill.
Avoid vanity metrics
Number of drills run, number of attendees and "satisfaction scores" feel good but do not show readiness. The useful questions are whether you found the affected systems, whether you knew who owned them, and whether you fixed last time's gaps.
Try it yourself
Click through it at your own pace, or open it full screen. Time yourself finding one component in the inventory, then compare with how long the same search takes in your own repositories.
Safeguard provides SBOM and dependency scanning plus a free scan, which can shorten the scoping step.
Quick check
What is a good time to scope?
There is no universal target. Set a goal that fits your size, such as 30 minutes for one component, then track your own improvement.
Do tabletop times mean anything if nothing is executed?
They show how long it takes to decide and who is needed, which is where many real delays come from. Functional drills add the execution time.
Last reviewed: 19 October 2026.
