You need a formal threat and risk assessment (TRA) if you're selling into Canadian government, bidding on a regulated contract, or facing an enterprise vendor security review that names one explicitly. If none of those apply, a lighter risk assessment folded into your SOC 2 or ISO 27001 work usually covers the same ground for less money.
That's the honest answer. A lot of vendors will sell a TRA to anyone who asks, because it's a well-defined, billable document. But the TRA is a specific artifact with a specific audience, and buying one you don't need is a common way for growing Canadian tech companies to burn budget on paperwork instead of security.
What a Threat and Risk Assessment Actually Is
A TRA is a formal, structured document that identifies threats to a system, rates the likelihood and impact of each, and maps them to mitigations. It follows a defined methodology (in Canada, most often the flavour derived from the Government of Canada's Harmonized TRA methodology, ITSG-33). It's not a vulnerability scan, it's not a penetration test, and it's not the risk register you keep for SOC 2. It's a point-in-time, document-first exercise built to satisfy a specific reviewer, usually a procurement officer, an auditor, or a security team doing vendor due diligence.
The output is a document. That's the whole point. Nobody reads a TRA to find a bug, they read it to confirm a rigorous process happened and the risks are understood and accepted at the right level.
Who Genuinely Needs a Formal TRA
The clearest, least ambiguous case is Canadian government procurement. If you're bidding on a federal, provincial, or municipal contract that touches sensitive data or critical systems, a TRA (or a document that maps directly onto ITSG-33 controls) is frequently a mandatory deliverable, not a nice-to-have. No TRA, no contract. This is the single biggest reason we build them for clients at traztech: it's table stakes for the deal, and there's no substitute that satisfies the requirement.
The second real case is enterprise vendor security reviews where the buyer's security team explicitly asks for a TRA by name, or asks questions that only a TRA answers cleanly (threat modelling per asset, documented risk acceptance by an accountable owner, formal likelihood/impact scoring). This shows up more with large banks, insurers, and telcos than with mid-market SaaS buyers, and it's common in fintech deals where the counterparty has its own regulatory obligations to satisfy. If you're selling into that world, see our fintech industry guidance for how these reviews typically layer on top of SOC 2.
The third case is genuinely high-consequence systems: critical infrastructure, health data platforms handling PHI at scale, or anything where a breach has safety implications rather than just financial ones. Here a TRA isn't a sales requirement, it's a legitimate risk management tool because the stakes justify the rigour.
Who Is Over-Buying a TRA
If your driver is "we want to look more secure" or "our competitor has one," you're over-buying. A TRA is expensive relative to the security value it adds for a typical B2B SaaS company that isn't touching government contracts. You're paying for a document format, not new security insight, if nobody on the buyer side is going to specifically ask for that format.
Early-stage and growth-stage SaaS companies most often over-buy TRAs when what they actually need is one of these instead:
- A SOC 2 Type II report, which most enterprise buyers accept as the default proof of a functioning security program
- A risk register maintained as part of an ISO 27001 or SOC 2 program, updated continuously rather than produced as a one-off document
- A penetration test report, if the ask is really about technical assurance rather than documented risk methodology
- A lightweight internal risk assessment used to prioritize your own roadmap, which doesn't need ITSG-33 formality to be useful
If a prospect's security questionnaire asks generic questions about "risk management" rather than requesting a TRA by name, a well-run compliance program answers that without a standalone TRA engagement. Companies pursuing AI-specific buyer scrutiny sometimes hit the same over-buying pattern with our ISO 42001 readiness work, where the instinct is to reach for the most formal document available rather than the one the reviewer will actually check against.
The Government Procurement Case in Detail
This is worth its own section because it's where a formal TRA earns its keep every time. Government RFPs, especially those touching PIPEDA-regulated personal information or classified up to Protected B, will often specify the TRA methodology directly, sometimes down to which sections and risk-rating scale to use. Reviewers are checking the document against a template, not evaluating your security maturity holistically. Skipping the formal structure, even if your actual security posture is strong, can disqualify a bid on a technicality.
This is also where Canadian companies have a structural advantage working with a Canadian firm rather than a US-based vendor unfamiliar with ITSG-33 or the procurement conventions used by PSPC and provincial equivalents. We do this work directly with clients in Toronto, Ottawa, Waterloo, Vancouver, Calgary, and Montreal, and the pattern is consistent: teams that try to retrofit a generic risk assessment into a government RFP template lose time and sometimes lose the bid. See our threat and risk assessment service for how we scope and deliver these against ITSG-33 and comparable methodologies.
How to Tell Which Bucket You're In
Ask three questions before commissioning a TRA:
- Has a specific buyer or RFP named a TRA as a required deliverable, or referenced ITSG-33 or an equivalent methodology?
- Is the reviewer a procurement office or a security team that will check the document format, not just the conclusions?
- Would a SOC 2 report or existing risk register already satisfy what's actually being asked?
A yes to the first two questions means you need the formal document. A yes only to the third means you probably don't, at least not yet.
What This Looks Like Under Quebec Law 25 and PIPEDA
Privacy law adds a wrinkle worth naming. PIPEDA and Quebec's Law 25 both push organizations toward documented risk assessment for personal information handling, and Law 25 specifically requires privacy impact assessments for certain processing activities. These overlap with a TRA in spirit but aren't the same document, and a privacy impact assessment doesn't substitute for a security-focused TRA a government buyer requests, or vice versa. Don't assume one covers the other without checking the actual requirement text.
Making the Call Without Guessing
The fastest way to avoid over-buying or under-buying is to have someone read the actual RFP clause, security questionnaire, or contractual requirement before scoping anything. A five-minute read of the source document usually settles it. If you're not sure which category your situation falls into, or you want a second opinion before a procurement deadline forces the decision, contact traztech and we'll tell you plainly whether you need a formal TRA or whether your existing compliance work already covers it.