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

Trusted by

  • Broadcom
  • SSENSE
  • Mondou
  • Western University
  • Votatec
  • Ren's Pets
  • City of Mississauga
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. 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. 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. 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.

By industry

Does Threat Risk Assessment work the same way in every industry?

No. The Threat Risk Assessment work is the same craft in every sector, but the conditions around it are not. In energy and mining that means SCADA networks and remote sites that can't go offline; in government, Protected A, B and C data handling. We keep the service and change the part that bends.

  • The assessment a regulator will eventually ask to see.

    SCADA and ICS. Availability outranks confidentiality here, and you often can't take a system offline to investigate what happened on it.

    • Bill C-8 and the CCSPA
    • Remote-site connectivity
    • ISO 22301
    Energy and mining IT
  • The TRA that ITSG-33 expects, against the catalogue that's current.

    Protected A, B and C. Each level changes where the data can physically live, who can reach it, and what you have to prove about both. Most files turn on Protected B, and most disagreements turn on what counts as reaching it.

    • ITSG-33, and ITSP.10.033
    • CPCSC
    • PIPEDA and the Privacy Act
    Government IT services
Request a consult

What do you need from Threat Risk Assessment?

Tell us who you are and what you're working on. A senior engineer reads your message before replying, so the first answer is a real read on scope, risk and timing, within an hour, 24/7. Nothing here is a commitment, and we'll tell you plainly if we're not the right fit.

I agree to receive emails from SMEnode.

We use your details to reply to this message. You can unsubscribe from our emails at any time. Privacy

Your request

Service
Threat Risk Assessment

What happens next

  1. A senior engineer replies within an hour, 24/7, never an SDR.
  2. We book a 30-minute call to listen, sketch options, and flag risks.
  3. You get a scoped statement of work within 3 business days.

Call the 24/7 line

+1 514-465-1584
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.

Want a Senior IT Consultant's Read on Your Setup?

Tell us what you run today and what keeps breaking. A senior SMEnode engineer replies within an hour with a first read on scope, risk and timing. No sales handoff.

Request a consult
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.

Engagement phases

Phases 01 to 04

  1. 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. 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. 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. 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 SMEnode engineer replies within an hour, 24/7.