How to Get a Threat and Risk Assessment: A Step-by-Step Guide

If a Canadian government RFP, an enterprise vendor review, or your own board has asked for a threat and risk assessment (TRA), you've probably discovered that "just get one done" is not a simple instruction. A TRA is a formal document that identifies your organization's assets, catalogues the threats against them, and rates each threat by likelihood and impact so decision makers can see where to spend money first. Done properly, it's one of the more useful security artifacts you'll produce, not just a compliance checkbox. Here's what the process actually looks like from a cold start to a signed-off report.

Step 1: Confirm why you need it and what "done" looks like

Before anyone opens a spreadsheet, get clear on the driver. A TRA required for a Government of Canada procurement (often referencing ITSG-33) looks different from one requested by an enterprise customer's vendor security team, which looks different again from one you're commissioning proactively because you're about to launch a new product. The driver determines the scope, the methodology, and often the exact template the reviewer expects. If a specific standard or client questionnaire is in play, get a copy of it before you start scoping. Guessing at requirements is the single biggest cause of a TRA getting bounced back.

Step 2: Define scope and asset boundaries

A TRA that tries to cover "the whole company" usually ends up too shallow to be useful and takes far longer than it needs to. Scope it to a defined boundary: a system, an application, a data flow, a business unit, or a specific engagement (like the one being procured). List the assets in scope: the data, the infrastructure, the third-party services, and the people and processes that touch them. This asset inventory is the backbone the rest of the assessment hangs off, so it's worth doing carefully rather than quickly.

Step 3: Identify threats and vulnerabilities

With assets defined, work through what could go wrong for each one. This means identifying threat sources (external attackers, malicious insiders, accidental error, supply chain compromise, environmental events) and the vulnerabilities that would let those threats materialize. Most teams pull from a recognized threat catalogue rather than inventing one from scratch, and cross-reference known weaknesses in the systems involved. This is also where having someone who actually thinks like an attacker pays off. A threat list built purely from a checklist tends to miss the scenarios that matter most for your specific environment.

Step 4: Rate likelihood and impact

This is the core of a TRA and the part reviewers scrutinize most closely. Each identified threat gets scored on how likely it is to occur and how severe the consequences would be if it did, usually on a simple scale (low, medium, high, or a numeric equivalent). The scoring needs to be defensible, not just gut-feel. Reviewers, especially government procurement teams, will ask why a risk was rated medium instead of high, so document your rationale alongside each score. The output is typically a risk matrix that plots likelihood against impact and makes it immediately obvious which risks need attention first.

Step 5: Recommend safeguards and residual risk

A TRA that only lists problems isn't finished. For each significant risk, recommend a safeguard, whether that's a technical control, a policy change, or a process fix, and then re-rate the risk assuming the safeguard is in place. That gives you residual risk: what's left over after mitigation. This is the number decision makers actually care about, because it tells them whether the remaining exposure is acceptable or whether more work is needed before go-live or contract signature.

Step 6: Document, review, and get sign-off

Pull everything into a formal report: scope, methodology, asset inventory, threat catalogue, risk ratings, recommended safeguards, and residual risk. Government and enterprise reviewers expect a specific structure, so match it to whatever template or standard triggered the requirement in step 1. Route the draft through internal review, then get formal sign-off from whoever owns the risk decision. Keep the report and its supporting evidence on file. It's common for the same TRA to get requested again by the next customer or the next procurement cycle, and having a clean, well-documented baseline saves you from starting over.

Realistic timelines

For a tightly scoped system or application, a focused TRA typically takes two to four weeks from kickoff to a signed-off report, assuming reasonable access to the people and documentation you need. Broader assessments covering multiple systems or a full business unit can run six weeks or more. The biggest delays aren't in the analysis, they're in gathering accurate asset information and getting the right people in the room to validate threat scenarios and sign off on ratings. Building in time for at least one review cycle with the requesting party is worth planning for from the outset.

Where a partner helps

You can run a TRA entirely in-house if you have the security expertise and the time. Where most teams get stuck is steps 3 and 4: building a threat list that reflects real attacker behaviour rather than a generic checklist, and defending the likelihood and impact ratings under a reviewer's questions. That's where bringing in a partner with hands-on offensive security background, rather than someone who has only ever filled out the template, changes the outcome. Our threat and risk assessment service is built around exactly that gap: a formal, defensible TRA scoped to your procurement or vendor review requirement, delivered on a timeline that matches your deadline. If the TRA is one piece of a larger compliance push, it's also worth looking at how it fits into your broader compliance program rather than treating it as a one-off deliverable.

Get started

If you have a TRA requirement on the table, whether it's a government procurement deadline or an enterprise customer's vendor security review, the sooner you scope it the more room you have to do it properly instead of rushing the last week. Contact us and we'll walk through your specific requirement, confirm scope, and give you a realistic timeline and quote.

What ITSG-33 actually asks for, and what people think it asks for

When a federal solicitation says "the supplier shall provide a threat and risk assessment in accordance with ITSG-33", buyers rarely mean you must reproduce the whole publication. ITSG-33 is the Canadian Centre for Cyber Security's guidance on IT security risk management, and the part that matters for a supplier TRA is the departmental and information system security risk management activities: categorize the information and the system, select a control profile, assess the residual risk, and put the result in front of someone empowered to accept it. The older Harmonized TRA methodology published with the RCMP is still the structural reference most reviewers have in their heads, which is why they expect asset statements, threat statements with likelihood and gravity, and a risk register that ties the two together.

The practical implication is that your TRA has to speak in the reviewer's units. If the department has categorized the system as Protected B, medium integrity, medium availability, then your assessment needs to demonstrate you understood that categorization and worked against the corresponding control profile, not a generic list of good practices. We have seen assessments rejected purely because they used a five-point CVSS-flavoured scale when the reviewer's template used low, medium, high, very high, and nobody could map one to the other without redoing the arithmetic. Ask for the template. If there is no template, ask which categorization the system carries and write to it.

Asset valuation is where most in-house assessments come apart

Teams tend to enjoy the threat catalogue and rush the asset work, which is backwards. In a TRA, the value of an asset is expressed as the injury that would result from its compromise, and injury is assessed against confidentiality, integrity, and availability separately. A customer database might carry high confidentiality injury and low availability injury. A pricing engine might be the reverse. If you collapse that into a single "criticality: high" label, every downstream risk rating inherits the same blur, and the reviewer can no longer tell why one risk landed above another.

Write injury statements in the language of consequence, not the language of systems. "Unauthorized disclosure of the claimant record set would expose approximately 40,000 individuals to identity fraud and would trigger notification under PIPEDA and Quebec Law 25" is an injury statement. "Database is important" is not. This is also the step where you discover that nobody agrees on where the data actually lives. Expect to find production copies in a business intelligence tool, a support ticketing system, and at least one analyst's laptop. Those discoveries belong in the asset inventory, not in a footnote, because they change the boundary of everything that follows.

The questions reviewers send back

A TRA that gets bounced is almost never bounced on style. The recurring objections are narrow and predictable, and you can pre-empt every one of them.

"Why is this rated medium?" Because someone wrote a number without a rationale. Every likelihood and gravity score needs a sentence next to it explaining the reasoning and, where possible, the evidence: threat intelligence, incident history in your own environment, the presence or absence of a compensating control. Reviewers do not usually disagree with the number, they disagree with the absence of an argument.

"Where is the supply chain?" Assessments written by engineering teams routinely stop at the perimeter of code they wrote. If your system depends on a payment processor, an identity provider, a managed database, and three observability vendors, each of those is a threat vector with its own likelihood profile. Name them, state what data they hold, and state what happens to your system when they are unavailable or compromised.

"Who accepted this risk?" A TRA with recommendations and no accountable owner is a technical document, not a risk decision. The reviewer wants to see that a named executive read the residual risk and signed. If your organization has no obvious signer, that is a governance gap the assessment has just usefully exposed.

"Does this reflect the system as built?" If the architecture diagram in the TRA does not match the diagram in your SOC 2 description or your vendor questionnaire responses, the reviewer will notice, and the credibility of the whole document drops. Reconcile them before submission.

What the work looks like in practice

It helps to picture a concrete case. Imagine a mid-size SaaS company asked for a TRA as part of a provincial health authority procurement. Scope gets set to one thing: the tenant that will hold the authority's data, plus the shared services it depends on. The asset inventory lands somewhere in the dozens of items, of which a handful carry high confidentiality injury. The threat statement runs longer than that, and after the first pass most of the entries sit below medium.

The findings that change the outcome in a case like that are usually design decisions rather than missing patches. Support engineers able to impersonate any tenant user through an internal tool, with no secondary approval and no per-use logging, turns a convenience feature into a high-likelihood insider risk against the assets with the highest confidentiality injury. Backup snapshots encrypted with a key held in the same cloud account as the data means a single account compromise defeats both controls at once. Neither of those is visible to a scanner, because neither is a vulnerability in the software. Both are usually closable inside a fortnight: an approval workflow and per-use audit logging on the impersonation tool, and a separate key management account with a restricted trust policy for backups.

The value of the exercise shows up in the residual risk table, where a small number of targeted changes move the high-rated risks down far enough that the buyer can accept what remains with documented compensating controls. Plan the calendar accordingly. Analysis is a matter of days; the schedule is set by how long it takes to get architecture answers out of the people who hold them and to get the sign-off meeting into a busy executive's diary. If you are budgeting a TRA, budget calendar time, not just effort.

What drives the cost

Three variables set the number on a TRA quote. The first is the count of distinct systems in scope, because each one needs its own asset and threat treatment even when they share infrastructure. The second is documentation maturity: if you have a current architecture diagram, a data flow, and a vendor list, an assessor spends their time assessing; if you do not, they spend the first week building the artefacts you were supposed to hand them, and you pay consulting rates for inventory work an internal analyst could have done. The third is whether hands-on validation is included. A paper TRA takes the stated control set at face value. A validated one confirms a sample of controls actually operate, which is more defensible and costs more. Where a client wants exploitability confirmed as part of the picture, we usually scope a focused test alongside it rather than inflating the assessment, since penetration testing starts from $1,000 and produces evidence a paper assessment simply cannot.

The cheapest lever available to you is the second one. Turning up to kickoff with an accurate asset list, a named owner per system, and a current vendor inventory reliably takes days off the timeline.

When you should not buy a TRA from us

Plenty of requests for a TRA are not really requests for a TRA, and it is worth checking before you spend money.

If an enterprise customer's security team sent a 200-question spreadsheet and one line of it says "provide your most recent threat and risk assessment", the honest answer is often that a well-written risk assessment you already produced for another framework satisfies them. An ISO 27001 risk assessment covering the same scope, with an accepted Statement of Applicability behind it, has cleared that question for our clients more than once. Send what you have and ask whether it meets the requirement before commissioning new work.

If you have no security programme at all, a TRA is the wrong first purchase. It will tell you what you already suspect, in a formal document nobody has the capacity to act on. The money is better spent standing up access reviews, logging, and a patch process, then assessing an environment that has something worth assessing. A fractional CISO arrangement from $3,000 per month gets you the decisions and the ownership, and the assessment lands afterwards on firmer ground. See fractional CISO for how that engagement is structured.

If the request is genuinely internal and your team includes someone with security architecture experience, run it yourselves. The methodology is public, the templates are available, and the only part that reliably needs outside help is the adversarial thinking in the threat statement and the defence of the ratings under questioning. Do the first four steps in-house and buy a review of the draft, which costs a fraction of a full engagement.

Keeping the assessment alive after sign-off

The most wasteful thing a company can do with a TRA is file it. Risk ratings decay: a threat rated low because of a control that has since been decommissioned is now wrong, and you will not notice unless something forces you to look. Set a review trigger rather than only a calendar date. Material architecture changes, a new subprocessor holding regulated data, an incident, and a change in the data categorization should each pull the assessment back open. Between triggers, an annual refresh is enough for most organizations.

The reuse value is real. Once you have a defensible asset inventory, injury statements, and a risk register with owners, the next procurement's TRA is an update rather than a rebuild, and the same material feeds an ISO 27001 risk assessment, a vendor questionnaire, and board reporting. Keeping it in one system rather than a folder of documents is what makes that possible, which is why we hand clients a live register in the traztech Workspace instead of a static file. If continuous ownership is what you actually need, our retainers cover the review triggers and the register upkeep; if you only need the document, fixed-scope pricing is the cleaner route.