Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, CPCSC, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →Web app, network, server, and cloud penetration testing, vulnerability scanning, vibe-coding QA, and AI/LLM security, run by a published security researcher, with our offensive-security partner brought in when the engagement calls for it. Looking for SOC 2, ISO 27001, or HIPAA? See Compliance.
Our founder is a published security researcher with 5 CVEs. We test your applications, network, servers, and cloud the way an attacker would, then hand you findings ranked by what they can actually do, with fixes, not raw scanner output. Testing is delivered with our partner Lorikeet Security.
You built it fast with AI. That is the point, and it is cheaper than hiring a dev team to build it in the first place. But AI is not there yet: it ships logic flaws, security holes, and overlooked edge cases with total confidence. Before you put it in front of customers or investors, have someone who breaks software for a living make sure it is actually good.
We QA, security-review, fuzz, and penetration test your vibe-coded product, then hand you a clear list of what is broken, what is exploitable, and how to fix it, still a fraction of the cost of a full engineering team.
What AI actually gets wrong, what each pass covers, and why this still costs less than having built it conventionally: read the full guide →
Get your vibe-coded app reviewedA Threat and Risk Assessment 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. In 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 a TRA, we produce one that stands up to scrutiny.
We combine hands-on testing with a structured assessment, so the document is backed by what we actually found in your environment, not a generic template. It aligns with the approach Canadian reviewers expect, and it gives you a clear, prioritized remediation plan you can act on.
Who asks for a TRA and why, how it differs from a pen test and a scan, and what is actually in the document: read the full guide →
Request a TRASecurity that scales with your business.
We run a baseline security assessment covering your cloud, code, access controls, and vendor relationships. You get a scorecard and a prioritized remediation plan.
We close the gaps. MFA enforcement, secrets management, logging, encryption at rest and in transit, network segmentation. Real controls, not checkbox compliance.
Ongoing vulnerability scanning, quarterly pen tests, and policy updates. We keep your security posture current as your infrastructure evolves.
A Waterloo data centre operator, where testing fed a SOC 2 Type II and ISO 27001 run together across a production campus, an AI compute platform and a self-hosted collaboration stack. An Ontario medtech company putting an AI clinical assistant in front of practitioners, where the findings shaped the evidence programme behind their SOC 2.
Tell us what you are shipping and your timeline, and we will scope the right test against our pricing.
Book a scoping callWe run web application penetration tests, network penetration tests, server hardening and configuration reviews, and cloud penetration tests against AWS, GCP, and Azure. Every test is hands-on and delivered with our offensive-security partner. You get a prioritized findings report mapped to severity and remediation, not raw scanner output. Testing is also available scoped as evidence for SOC 2, ISO 27001, and enterprise security reviews.
A QA, security review, fuzzing and penetration test of software you built with AI coding tools. AI is fast but still ships logic flaws and security gaps. We review the generated code, fuzz it and pen test it, for far less than hiring a development team to rebuild it.
A vulnerability scan is automated and continuous. It flags known issues across your cloud, containers, and dependencies. A penetration test is a human-led attack that chains findings, tests business logic, and proves what an attacker could actually do. We triage scan findings by real exploitability, not CVSS score alone, and use pen testing where proof and depth matter.
Testing is delivered with our offensive-security partner and led by a published security researcher with 5 published CVEs, including CVE-2024-45163 (CVSS 9.1), the kill-switch for the Mirai botnet. That offensive-security depth means findings reflect real attacker behavior, not a checkbox.
Yes. We scope and report penetration tests to serve as evidence for SOC 2, ISO 27001, and buyer security questionnaires. If you also need the full framework program, our compliance team handles readiness and audit prep end to end.
Yes. A TRA is a formal document that identifies the threats to your systems and data, rates each risk by likelihood and impact, and documents your mitigations. It is a common requirement in Canadian government procurement, regulated sectors, and enterprise vendor reviews. We produce one backed by real testing of your environment, aligned with what Canadian reviewers expect, with a prioritized remediation plan.
Track record
We are deliberately not a large firm, and 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 across 76 controls with zero exceptions, on a team of 15.
The platform held 99.9% uptime 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.
For a Waterloo data centre operator we ran SOC 2 Type II and ISO 27001:2022 together rather than one after the other, across a production campus, an AI compute platform and a self-hosted collaboration stack. Scoped so further Ontario and Quebec sites enter as they reach production. Findings delivered and remediated.
For an Ontario medtech company putting an AI clinical assistant in front of practitioners, we ran the gap analysis and built the evidence programme behind their SOC 2.
Most companies buy their first penetration test because an auditor, an enterprise customer or an insurer asked for one. Here is what each framework actually says, including where it stops short of requiring a test outright.
| Framework | Status | What the requirement says |
|---|---|---|
| PCI DSS v4.0Requirements 11.4.1 to 11.4.5 | Required | Internal and external penetration testing at least annually and after any significant infrastructure or application change. The tester must be a qualified internal resource or a qualified external third party with organisational independence from the environment being tested. |
| ISO/IEC 27001:2022A.8.8 and A.8.29 | Expected | Technical vulnerabilities must be managed, and security testing must be carried out during development and acceptance. Certification bodies routinely treat a penetration test as the evidence for these. |
| SOC 2CC4.1 and CC7.1 | Expected | The Trust Services Criteria never name penetration testing. They require evaluations of internal control and the detection of vulnerabilities, and a test is the most common way to evidence both. Auditors and enterprise buyers ask for it as a matter of course. |
| CMMC and CPCSC Level 2NIST SP 800-171 3.12.1 | Expected | Security controls must be periodically assessed for effectiveness. A penetration test is a normal part of that assessment, though the practice itself is written more broadly. |
| HIPAA Security Rule45 CFR 164.308(a)(8) | Expected | A periodic technical and nontechnical evaluation is a required implementation specification. Penetration testing is the usual technical half of it. |
| Cyber insuranceUnderwriting questionnaires | Conditional | Not a framework, but increasingly the reason a test gets bought. Carriers ask when the last test was performed and whether findings were remediated. |
Two things worth asking any testing firm. Is a retest included, and for how long? Auditors sample remediation evidence, so a test without a retest leaves you with findings and no proof you closed them. Will findings map to the controls you are audited against? We track findings to closure in the workspace rather than handing over a PDF, and prices are on the pricing page.
Before you go
Short, practical notes on Security. Unsubscribe in one click, and replies reach me directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.