How to Run a DSAT-Compliant TNA, Step by Step
A practical walkthrough of running a Training Needs Analysis that will stand up to DSAT audit and assurance — not just produce a report nobody can defend.
Start with the capability requirement, not the training request
A DSAT-compliant TNA starts by establishing the capability requirement in Defence terms — what does the role or unit actually need to be able to do, and against what standard — before any conversation about training format or content.
Requests that arrive already framed as a training request ("we need a course on X") should be treated as a hypothesis to test, not a scope to deliver against.
Building the evidence base DSAT auditors expect
Assurance auditors look for evidence, not assertion: performance data, error or incident rates, structured observation, and a clear baseline of current performance against the capability requirement. Interviews are useful context, but on their own they don't satisfy an auditor asking how the gap was established.
The evidence base should be gathered and recorded in a form that survives being read months later by someone who wasn't in the room — that's the practical test of whether it's audit-ready.
Testing whether the gap is a training gap at all
With a capability requirement and an evidence base in place, the analysis explicitly tests alternative explanations — unclear roles, absent governance, a structure working against the outcome — before concluding training is the right intervention. Recording that this test happened, and what ruled out the alternatives, is what makes the eventual recommendation defensible.
Structuring the analysis for defensibility
A defensible structure links every recommendation back to a specific piece of evidence and a specific element of the capability requirement — not a general narrative about what would probably help. If a reviewer can't trace a recommendation back to the evidence that produced it, the structure has failed, regardless of how good the recommendation actually is.
Handing off to design without losing the audit trail
The handoff from Analysis to Design is where audit trails most often get lost — the TNA report gets summarised into a brief, and the evidence base behind each finding quietly disappears. Keeping the full analysis attached and referenced, not just a summary, is what lets Design and Evaluation later be tested against what Analysis actually found.
Common questions on this topic.
JSP 822 sets out requirements rather than a fixed template — the priority is that the evidence base, the capability requirement and the reasoning connecting them are all traceable, however the report is formatted.
Enough that a reviewer unfamiliar with the engagement could follow the reasoning from capability requirement to evidence to recommendation without having to take any step on trust.
Losing the audit trail at handoff to Design — the recommendation survives, but the evidence that justified it doesn't get carried forward in a traceable way.
Want this thinking applied to your organisation?
Insight is useful. Applied insight changes outcomes. Let's talk about yours.