Do You Actually Need Threat and Risk Assessment?

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.

What Actually Drives the Price

TRA quotes vary more than almost any other security deliverable, and the variation is rarely about quality. The drivers are the number of distinct systems inside the boundary, whether anyone has ever drawn your data flows, how many third parties touch the data, and the sensitivity level the buyer has specified. A single-product SaaS platform on one cloud account with an existing architecture diagram is a fundamentally different job from a company with an acquired product line, a legacy on-premise component, and eleven subprocessors nobody has catalogued.

The hidden driver is review rounds. If the buyer is a procurement office working from its own template, the document goes back and forth until it matches the template, and each round costs calendar time you did not plan for. Ask up front whether the requesting party will share the template or the evaluation criteria. A firm that says the format does not matter has not done many of these.

What the Deliverable Should Contain

You can grade a TRA before a reviewer does. A defensible one has a scope statement naming the systems and the exclusions, an asset inventory with a classification applied to each item, data flow documentation showing where information crosses a trust boundary, a threat catalogue tied to named assets rather than floating in the abstract, a control assessment measured against a stated control profile, likelihood and impact scales defined before they are used rather than after, a risk register carrying inherent and residual ratings, and a treatment plan with an owner and a date against every line.

Why TRAs Get Sent Back

The rating scale is invented mid-document. If a "high" impact means one thing in section four and something else in section six, the whole register becomes unusable and a reviewer will say so.

Controls are asserted, not evidenced. Writing that access is reviewed quarterly is a claim. Naming the system, the reviewer, and the last completed review turns it into a finding a reviewer can accept.

Hosting and subprocessors are absent. Canadian evaluators look for where data physically sits and who else can reach it. A TRA that never names the cloud region or the offshore support vendor reads as incomplete regardless of how strong the rest is.

Who Signs, and Why It Cannot Be Us

An external firm can author a TRA, run the interviews, build the register, and defend the methodology. It cannot accept the residual risk. Acceptance belongs to someone inside the organization with the authority to live with the consequence, usually a CTO, a COO, or the executive who owns the affected line of business. Reviewers check for that signature because an unaccepted risk register is a document nobody is answerable for. If a provider offers to sign off on your behalf, that is a reason to walk.

When You Should Write It Yourself

If the request is internal, if the audience is your own board or a new head of security, or if the scope is a single application you understand well, write the first draft in-house. The interviews are the expensive part of the engagement and you can do them for free by walking around your own company. Take a published methodology, apply it honestly, and accept that version one will be rough. A rough internal TRA that is actually maintained beats a polished external one that is filed and forgotten.

The case for paying someone starts when the document is going in front of a reviewer who can reject it, when the methodology has to match a named standard you have never worked with, or when nobody internally has the time to chase twelve people for answers before a bid deadline. Short of that, spend the money on fixing something instead. Our fixed-scope pricing lists what each piece costs, our compliance work covers the frameworks a TRA usually feeds into, and if you are not sure which side of the line you are on, tell us what the buyer asked for and we will say plainly whether this is work you need to buy.