53 / 63Threat Risk Assessment (TRA)

Threat risk assessment (TRA), and the register somebody actually actions

Canadian threat risk assessment mapped to the federal control catalogue that took effect in March 2026.

  • CCIE Security-led assessors
  • Harmonized TRA and ITSP.10.033
  • Protected B work, Canadian residency
THE WORK

Threat risk assessment, three pillars, one operator.

One Canadian team scopes the assets, rates the risk, and names who acts. A TRA nobody actions is just a document.

  1. 1

    Assets and credible threats

    Every asset in scope, the injury that follows if it's compromised, and the threat actors with the motive and the means to try. We work from evidence about your sector rather than a generic actor list.

  2. 2

    Controls that are current

    Findings map to ITSP.10.033, the Canadian Centre for Cyber Security catalogue that superseded ITSG-33 Annex 3A on 2026-03-31. If your last report was an ITSG-33 TRA, its control references are out of date.

  3. 3

    A register with owners

    Every risk rated, owned, dated, and either treated or accepted in writing. The risk register is the deliverable, and it carries the asset, the control gap behind the rating, and the person who agreed to act.

THE PROOF

Built to last. Evidence over promises.

Just 59% of Canadian businesses do anything at all to identify cyber risk, and that share hasn't moved since 2019 (source: Statistics Canada, Canadian Survey of Cyber Security and Cybercrime, 2024-10-21).

IN PRODUCTION

Risk a Canadian decision-maker will actually sign.

Most registers we inherit run ninety pages with four hundred findings, no owners and no dates. That isn't an assessment, it's an inventory of everything anyone could think of. We'd rather hand you a dozen risks with a name and a date against each, because those are the ones that get closed.

SMEnode · Engineering principle
  • CCIE Data Center
  • CCIE Security
  • CCDE Design
  • Canadian data residency
THE DEEP DIVE

Threat risk assessment in Canada, made real.

Most assessments fail after delivery, not during it. The report is fine. Nobody can act on it.

What a cyber risk assessment should actually contain.

A good threat risk assessment is short and specific. It names the assets that matter, states what injury follows if each one is compromised, and identifies the threat actors with both the motive and the means to try. It rates the risk that remains after your existing controls, not the risk in the abstract. Then it stops. A four hundred finding report is a way of avoiding the decision about which twelve things matter.

Why we still run the Harmonized TRA structure.

We run the Harmonized TRA structure because Canadian reviewers already know how to read it, and we shorten it where it has gone stale. The risk sits in two places. Scoping too wide, which produces a document nobody finishes. And rating risk against controls that were described in a document rather than observed working, which is how a register ends up confidently wrong.

The control catalogue changed on 2026-03-31.

The Canadian ground moved this year and a lot of assessment work hasn't caught up. On 2026-03-31, ITSP.10.033 took effect and superseded ITSG-33 Annex 3A, the control catalogue Canadian assessment reports have cited since 2012 (source: Canadian Centre for Cyber Security, 2026). The new one tracks NIST SP 800-53 Rev. 5 and adds privacy controls, which matters because PIPEDA obligations and a Protected B rating now land in the same catalogue. An ITSG-33 TRA written last year still points at a catalogue that no longer applies.

Zero-Trust vault
THE METHOD

How our cyber risk assessment and security risk analysis work runs.

Four steps, and step 01 decides whether the rest is useful. Scoping is where assessments go wrong, because the honest scope is narrower than the one anybody asks for. We push to name the systems whose compromise would actually change your week, rather than inventorying everything and rating it all medium. A TRA covering nine systems that people read beats one covering ninety that they don't.

  1. Step 01

    Scope and value the assets

    We name the systems and data in scope, agree the injury that follows if each is compromised, and set the classification, Protected B included where it applies. Everything after this inherits the scope, so we settle it in writing.

  2. Step 02

    Name credible threats

    Threat actors with motive and means against your sector, plus the accidental and environmental ones. We drop the actors who make a report look thorough but would never come for you.

  3. Step 03

    Rate against observed controls

    We check the controls you claim, map them to ITSP.10.033, and rate residual risk on what we saw working rather than what a policy says. Two of these usually surprise somebody.

  4. Step 04

    Write a register people use

    Each risk gets a rating, a named owner, a date, and a decision: treat it or accept it in writing with a signature. We brief the people who have to sign the system off, and we come back to check what moved.

QUESTIONS

Threat risk assessment questions, answered straight.

Answers first, including the one where we tell you a TRA isn't what you need. An architect takes the call.

Cyber, and only cyber. The phrase gets used for three different jobs: IT and cyber risk, physical site security, and violence risk assessment in schools and workplaces. Those last two need different people with different credentials, and we'd be the wrong call. Ours covers information systems, networks, data, and the controls around them. If you need a site or behavioural assessment, say so early and we'll tell you plainly.

Yes, as the structure, and we say where it shows its age. TRA-1 dates from 2007 and its asset, threat, and weakness tables are still the clearest way to make a Canadian assessment reviewable by somebody who has to sign it. What we replace is the control catalogue: findings map to ITSP.10.033, which took effect 2026-03-31, rather than to ITSG-33 Annex 3A.

Different question, different output. A scan tells you which systems have known weaknesses right now, and it runs on a schedule. A threat risk assessment asks what happens to the business if a specific asset is compromised, who would try, and whether your controls hold. One produces a queue of technical fixes. The other produces a rated register a decision-maker signs. Most organisations need both, and they're separate engagements.

A register and a briefing, not a binder. It lists each risk with its rating, the asset it threatens, the control gap behind it, a named owner, and a target date. You get the control mapping, so an auditor can trace any rating back to a catalogue reference. We present it to the people who have to act, because a register emailed is a register nobody opens.

Two roles, mostly. Somebody who can say what a system is worth to the business, and somebody who can commit to acting on a rated risk. We do the technical checking ourselves. Expect a scoping session, a few short control walkthroughs, and one briefing at the end. Without an owner who holds the authority, the register stalls.

When nobody has authority to act on the findings, because then you're buying a document. When you already know your top three risks and haven't funded them, since a report won't create the budget. And when a system is weeks from replacement, where assessing what's leaving costs more than it tells you. We've talked clients out of all three, and it's cheaper than the alternative.

LET'S CONNECT

A senior engineer replies within an hour, 24/7.