What Is Threat and Risk Assessment? A Plain-Language Guide (2026)

If you have ever been asked to "provide a TRA" by a government procurement office or an enterprise vendor security team, you already know the term is common. What is less common is a clear explanation of what the document actually is, why someone wants it, and what producing one actually involves. This guide covers that in plain language.

What a threat and risk assessment is

A threat and risk assessment (TRA) is a formal document that identifies the threats facing a system, application, or organization, then rates each one by how likely it is to happen and how bad the consequences would be if it did. The output is usually a risk register: a list of threats, their likelihood and impact ratings, the resulting risk level, and the controls in place or recommended to bring that risk down to an acceptable level.

It is not a penetration test, and it is not the same as a vulnerability scan. A pen test tries to exploit weaknesses in a live system. A TRA is broader and more structural: it looks at the whole picture, including business processes, data flows, physical access, third-party dependencies, and people, not just technical vulnerabilities. Many TRAs draw on scan results and pen test findings as inputs, but the assessment itself is a risk analysis exercise, not a hands-on hacking exercise.

Who actually needs one

Three groups ask for TRAs most often in Canada.

• Government procurement. Federal, provincial, and municipal RFPs for systems handling sensitive or personal information frequently require a TRA before go-live, following frameworks like the Government of Canada's Harmonized TRA methodology or provincial equivalents.
• Enterprise vendor risk teams. If you sell software to a bank, insurer, or large enterprise, their vendor security review may ask for a current TRA covering the system that will touch their data, separate from any SOC 2 report you hold.
• Regulated organizations doing internal due diligence. Healthcare, finance, and critical infrastructure organizations often commission TRAs on their own initiative before launching a new system, migrating infrastructure, or acquiring a company.

If none of these apply to you today, a TRA may still be worth doing proactively. Deals stall when a buyer asks for a risk assessment you do not have and cannot produce quickly.

What the process involves

A properly scoped TRA generally moves through the same stages regardless of methodology:

• Scoping and asset identification. Define the system boundary: which applications, data stores, networks, and third parties are in scope. This step matters more than people expect. A TRA scoped too broadly takes months and produces a report nobody reads; scoped too narrowly, it misses the risk the buyer actually cares about.
• Threat identification. Catalogue realistic threats: external attackers, insider misuse, third-party compromise, data loss, service disruption, and so on, drawing on threat intelligence and the nature of the system.
• Vulnerability and control review. Assess what controls already exist and where gaps remain, often incorporating architecture review, configuration review, and prior scan or test results.
• Likelihood and impact rating. Each threat gets scored against a defined scale, typically low/medium/high or a numeric equivalent, resulting in an overall risk rating.
• Recommendations and reporting. The final document lists prioritized remediation recommendations tied to each significant risk, along with residual risk after proposed controls are applied.

For a deeper look at how traztech scopes and delivers this work, see our threat and risk assessment service page.

Realistic timeline

Timelines vary with scope, but for a single application or system of moderate complexity, expect roughly two to four weeks from kickoff to final report: about a week for scoping and information gathering, one to two weeks for the assessment itself, and a few days for review and finalization. Larger scopes covering multiple systems, or organizations with limited internal documentation, run longer. If a vendor promises a TRA in a couple of days, ask what corners are being cut on scoping, because that is usually where quality is lost.

Common misconceptions

A few misunderstandings come up repeatedly with buyers who are asked for a TRA for the first time.

• "A TRA is the same as SOC 2." They overlap in some evidence but serve different purposes. SOC 2 is an attestation against a defined trust services criteria framework, produced by an accredited auditor. A TRA is a risk analysis document and does not require an auditor's opinion. Some buyers ask for both. If your business needs both compliance certification work and risk assessment, our compliance solutions page covers how these pieces fit together.
• "One TRA covers everything forever." Risk changes as systems change. Most procurement and vendor review processes expect a TRA to be refreshed on a set cadence, commonly annually, or after a material change to the system in scope.
• "A TRA is only for large enterprises." Small and mid-size companies get asked for TRAs constantly once they sell into government or regulated enterprise buyers. Company size does not exempt you from the requirement; the scope of the assessment can be sized to match your system.
• "It is purely a technical exercise." A significant part of a TRA is understanding business context: what the data is worth, what happens if the system goes down, who has access and why. Skipping this and jumping straight to a technical checklist produces a document that will not survive scrutiny from an experienced reviewer.

Getting started

If you have a TRA requirement on your desk with a deadline attached, the fastest path is to get the scope right before anything else. A short scoping call typically clarifies whether you need a full TRA, a lighter-weight risk review, or something else entirely.

If you are facing a procurement deadline or a vendor security review that requires a threat and risk assessment, get in touch with traztech to talk through your scope and timeline.

The Statement of Sensitivity Comes First

Before a Canadian public sector reviewer looks at your threat table, they look at how you classified the information. In the federal world this is usually a statement of sensitivity: a short document that names each information asset in scope and assigns an injury level for confidentiality, integrity, and availability separately, with a written rationale for each rating.

Teams doing their first TRA almost always collapse those three into one number. That single number then propagates through the entire assessment and makes the results unusable. A scheduling system holding no personal information may carry a low confidentiality injury and a high availability injury, and the controls that follow from those two ratings are completely different. If you rate the system as "medium" overall, you end up recommending encryption you do not need and skipping the redundancy you do.

The rationale matters as much as the rating. "High because the data is sensitive" gets sent back. "High because unauthorized disclosure would expose the home addresses of protected persons, which meets the serious injury threshold in our classification guide" does not. Reviewers are checking whether a defensible method was applied, not whether they agree with your conclusion.

Likelihood Scales That Survive Review

The weakest part of most in-house assessments is the likelihood column. Someone assigns "medium" to twenty threats and the whole risk register turns into a flat field with no prioritization signal in it.

Two things fix this. First, define the scale in the document, with anchors a reader can test: what frequency does "likely" mean, once a year or once a quarter, and over what period. Second, split threat likelihood from control effectiveness instead of merging them. Rate how often the threat would be attempted against a system like yours, then rate separately how well your controls would stop it. The residual rating falls out of the two, and when a reviewer challenges it you can point at which half they are disagreeing with.

The same discipline makes the assessment reusable. A year later most threat likelihoods have not changed, but your controls have. If the two are tangled in one score, the annual refresh becomes a full rebuild.

What Reviewers Send Back

Assessments come back for a short list of predictable reasons, and knowing them ahead of time saves a review cycle.

The boundary is not drawn. There is no diagram showing what is inside scope, what is outside, and where data crosses the line. A named system with an architecture diagram and a data flow, including the third parties, closes most of this.

Third parties are absent. If your system runs on a cloud provider, uses a managed database, and pushes notifications through a third-party service, all three sit in your risk picture. Reviewers check whether you assessed those dependencies or quietly inherited assurance from a provider's certification.

Residual risk has no owner. Every risk you are not fully mitigating needs a named individual who has accepted it and a date. Not a team, not a role written in the abstract. A person.

Recommendations are not costed or ordered. A list of twenty-two recommendations with no indication of effort or order is a list nobody will action. Group them into what must happen before go-live, what happens in the first ninety days, and what is a longer-term improvement.

The evidence is asserted rather than shown. "Access reviews are performed quarterly" is a claim. The reviewer wants to know how you verified it: you saw the last two review records, or you were told by the system owner, and the document should say which.

What Drives the Cost

Price on a TRA tracks a few specific things rather than headcount or revenue. The number of distinct systems and data stores in scope is the largest driver, because each one needs its own boundary, its own classification, and its own control review. After that comes documentation maturity: if your architecture diagrams are current and your access model is written down, the assessment is largely interviews and validation. If everything lives in people's heads, we are building your documentation as a side effect of the assessment, and that takes weeks rather than days.

The third driver is the methodology imposed on you. A buyer asking for "a risk assessment" is cheaper to satisfy than one requiring a specific federal methodology with prescribed templates and injury tables, because the format constrains how much existing material can be reused. Ask your buyer, in writing, which methodology and deliverable format they expect before anyone quotes the work.

When You Should Not Buy a TRA From Us

If nobody has asked you for one, do not commission one. A TRA produced in the absence of a real requirement will not match the methodology the eventual buyer specifies, and you will pay twice.

If the actual question is whether your application can be broken into, you want a penetration test, not a risk assessment. A TRA will document that the risk of exploitation exists. It will not tell you whether your authentication is bypassable.

If you have a competent security lead and the buyer supplied a template, run it internally. The methodology is learnable, and paying an outside firm to fill in a form you were handed is poor value. Bring us in to review the finished document instead, which costs a fraction of full delivery.

Outside help earns its keep when the deadline is short, the methodology is unfamiliar, or the document has to hold up in front of a reviewer who does this professionally. If that is your situation, send us the requirement and we will tell you what the scope really is. Where it recurs annually, the refresh sits more sensibly inside a retainer than as a repeated project.