A fixed-price gap analysis, remediation through to your audit, and upkeep after it. All in a workspace you keep.
All compliance →Led by a published security researcher with five CVEs. One standard report, letters for your buyers, and retests of your fixes.
All security →To the people you sell to, raise from or answer to.
All industries →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →A TRA is a formal document that identifies the threats to your systems and data, rates the risk of each, and lays out how you are mitigating them.
Request a TRAIn Canada it is a common requirement in government procurement, in regulated sectors, and in enterprise vendor reviews. If a contract or a buyer has asked you for one, we produce a TRA that stands up to scrutiny, backed by real testing of your environment rather than a template with your logo on it.
If you are on this page, something asked for one. Usually a form, a clause, or a reviewer. These are the four ways it normally shows up.
A TRA is a formal cybersecurity document covering your digital assets, infrastructure, and sensitive data. Ours is built on what we found in your environment, so every risk rating traces back to something real. Here is what you get.
What is covered and what is not: the systems, the data, the users, the third parties. Reviewers read this section first, because a vague scope makes the rest of the document meaningless.
The realistic threats to your assets, infrastructure, and sensitive data, informed by real testing rather than guesswork. Named, specific, and relevant to how you actually operate.
Each risk scored by likelihood and impact, so leadership and buyers can see what matters and why. This is the part a procurement reviewer will scan for evidence you thought about it seriously.
What we actually found when we tested. This is what separates a TRA that holds up from a generic template: the assessment is backed by evidence from your environment.
What you already have in place, how well it covers each risk, and where the gaps are. Honest, because the reviewer will notice if it is not.
An ordered list of what to fix and in what sequence, so the TRA is something you act on rather than a file you email once and forget.
These three get used interchangeably in procurement emails and they are not the same thing. Asking for the wrong one wastes a month.
They work best together. A pen test finds the weaknesses; a TRA answers the risk question a procurement reviewer is asking. We do both, so the assessment is backed by what testing actually found, led by a published security researcher with 5 CVEs. See our security services for the testing side.
Scoped up front. You know the deliverable and the timeline before you commit.
We start with the thing that triggered this: the solicitation, the contract clause, the questionnaire, the underwriter's form. What the reviewer expects shapes the scope, so we read it before we quote it.
Hands-on testing scoped to what the assessment needs: web app, network, servers, or cloud. Delivered with our offensive-security partner. This is the part most TRA vendors skip.
We build the threat model and the risk register, rate each risk by likelihood and impact, and document your existing mitigations and where they fall short.
You get the document, the prioritized remediation plan, and a walkthrough so you can speak to it. If the reviewer comes back with questions, we help you answer them.
The risk work overlaps. If a TRA is not the only thing being asked of you, build it once and use it in more than one place.
We write your TRA and get you audit-ready; the SOC 2 or ISO 27001 audit itself is signed by an independent firm. See Compliance for the full picture.
Forward the clause, the questionnaire, or the email. We will tell you what scope actually satisfies it, and what it takes to get there.
Request a TRAA TRA is a formal cybersecurity document used to identify, evaluate, and mitigate the security risks to an organization's digital assets, infrastructure, and sensitive data. It names the realistic threats to your systems, rates each risk by likelihood and impact, and documents what you are doing about them. In Canada it is common vocabulary in government procurement, in regulated sectors, and in enterprise vendor reviews.
Usually a Government of Canada solicitation or a prime contractor, an enterprise procurement or vendor-risk team, a bank or federally regulated financial institution flowing its third-party requirements down to you, or an insurer assessing a cyber policy. People rarely read about TRAs out of curiosity. If you are looking for one, something in a contract or a review has asked for it.
A penetration test is a human-led attack that proves what someone could actually do to your systems. A TRA is the assessment that puts those facts in business terms: what the threats are, how likely each one is, how bad it would be, and what mitigations are in place. A pen test answers what is broken. A TRA answers whether you have assessed your risk and can show your work. They complement each other, which is why we test first and then write the assessment.
No. A vulnerability scan is automated and continuous. It flags known issues across your cloud, containers, and dependencies at a point in time. A TRA is a structured document covering threats, risk ratings, and mitigations across your environment. A scan can feed a TRA, but scanner output on its own will not satisfy a reviewer asking for a Threat and Risk Assessment.
A defensible document you can hand to a government buyer, regulator, or enterprise reviewer: the scope and assets covered, the threats identified, a risk register rated by likelihood and impact, the findings from hands-on testing of your environment, your documented mitigations, and a prioritized remediation plan you can act on. We walk you through it, and we help you answer follow-up questions from whoever asked.
The risk work overlaps heavily. ISO 27001 is a risk-based standard, so the threat and risk analysis feeds your risk assessment and Statement of Applicability. SOC 2 readiness expects you to document how you assess risk, and the testing behind a TRA also serves as pen-test evidence. NIST CSF is assessed as current versus target profiles, and a TRA gives you the risk picture those profiles reflect.
Risk assessment is the one requirement that is mandatory almost everywhere, and the one most often produced the week before an audit rather than used to run the programme.
| Framework | Status | What the requirement says |
|---|---|---|
| ISO/IEC 27001:2022Clauses 6.1.2 and 8.2 | Required | You must define and apply an information security risk assessment process, and perform assessments at planned intervals or when significant changes occur. This is a mandatory clause and cannot be excluded through the Statement of Applicability. |
| SOC 2CC3.1 to CC3.4 | Required | The organisation must specify objectives, identify and analyse risks to achieving them, assess fraud risk, and identify changes that could affect internal control. |
| HIPAA Security Rule45 CFR 164.308(a)(1)(ii)(A) | Required | An accurate and thorough assessment of risks and vulnerabilities to electronic protected health information. Required, and the single most cited item in enforcement actions. |
| PCI DSS v4.0Requirement 12.3.1 | Required | A targeted risk analysis is required for each requirement that permits a flexible frequency, documenting the reasoning behind the frequency chosen. |
| Quebec Law 25Privacy impact assessment | Conditional | A privacy impact assessment is required for any project involving the acquisition, development or overhaul of an information system handling personal information. |
A risk assessment that is written once and never revisited will fail on the interval requirement rather than the content. Ours is built to be maintained, and it feeds the register, the Statement of Applicability and the management review inputs directly. Where the assessment has to be independent of the people who built the controls, that is internal audit work instead.
Free PDFs, no card
The IR plan template and the vendor security questionnaire as PDFs, plus the readiness checklists. Free, no card.
From Jacob Masse, principal of traztech: the files by email, then a few short notes over the next month. No spam, unsubscribe in one click.
Track record
We would rather show you the work than a wall of logos. Here is what is behind the advice.
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
The printer is the one that matters on a compliance page: an asset nobody counts as a computer, on a flat network, downed by a device that never had to log in. Auditors ask how controls fail. We have found out first-hand.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation with zero exceptions.
The platform stayed in production throughout, which is the part most readiness projects get wrong: controls are easy to design and hard to retrofit onto a system people already depend on.