Skip to content

The TRA turns the injury statements in the SoS into an evidence-backed picture of what could go wrong, how likely it is, and what will be done about it — the artifact that lets the DSO make a defensible authorization decision.

1 · Scope and boundaries

The scope statement here must match the SSP authorization boundary. Any drift will be caught by the assessor.

Anchor first. System name, SoS revision, assessment window, categorization inherited from the SoS, and the cloud / shared-service dependencies. The rest of the TRA traces back to this section.

2 · Assets under assessment

Every asset a threat actor could target — applications, data stores, admin consoles, monitoring. Each asset gets an id so the risk register in §6 can reference it.

3 · Threat agents considered

Start from the ITSG-33 threat-agent taxonomy and adjust for departmental context. Delete agents that are not credible; add sector-specific ones (foreign state, insider with elevated access) where the SoS implies an elevated profile.

4 · Threat scenarios

Written in the form agent + action + asset → outcome. Cross-referenced to assets from §2, tagged with a STRIDE class, and grounded in a specific precondition.

5 · Vulnerabilities

Weaknesses in the current implementation that make one or more scenarios feasible. Each vulnerability names the control (e.g. AC-3, SC-8) that is under-implemented.

6 · Risk register and matrix

Likelihood × impact on a 3×3 scale, with inherent and residual ratings and a treatment decision per risk. Larger scales or quantitative models are optional; the discipline is the same.

7 · Treatment plan and residual risk

For each risk, the treatment (mitigate, transfer, avoid, accept), the specific controls to be implemented, the owner, and the target date. Residual risk is the risk that remains after treatment.

8 · Residual-risk statement for the DSO

Overall residual-risk rating, recommendation to the DSO, risks recommended for formal acceptance, and the triggers that would force a reassessment before the ATO expires.

Approvals

The signatures below confirm that the responsible parties have reviewed this document, that its contents accurately reflect the system, and that the recorded decisions are authorized.

RolePurpose of signature
TRA leadPrepared the assessment and confirms the analysis is complete and evidence-backed.
System owner / delegateConfirms the scope, assets, and treatment plan reflect the system as operated.
IT Security leadConfirms the control gaps and treatment mapping are consistent with departmental control profiles.
Departmental Security Officer (DSO)Accepts the residual-risk statement in §8 or returns the assessment for further work.
Prefer the full starter? The paginated PDF above matches the Skymeba Print Edition style used across the library — cover, running header, sign-off page, and italic placeholder text ready to be filled in.
The Practitioner's Library

Pick up the next artifact.

The four artifacts share a single design system, a single voice, and a single reading rhythm — so an assessor sees one document family.