Security

Real offensive depth

Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.

All security →
Compliance

Audit-ready, fixed scope

SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.

All frameworks →
Resources

Learn the space

Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.

Read the blog →
Security & Compliance Glossary

Incident Response

Incident response is the organized process for detecting, containing, eradicating, and recovering from a security breach or attack, then learning from it. A documented incident response plan defines roles, communication paths, and steps so a team can act fast under pressure. The goal is to limit damage and restore operations quickly.

In practice

A common framework has six phases: preparation, identification, containment, eradication, recovery, and lessons learned. Preparation matters most; the decisions you make calmly in advance are the ones that hold up at 2 AM.

Insurers, customers, and regulators all want to know who answers the phone during an incident. A retainer with a named team and a contracted SLA gives you that answer without building an internal SOC.

// how traztech helps

traztech delivers incident response retainers with a contracted SLA for startups and growth-stage companies, led by a published security researcher.

Book a call

For a broader look at getting audit-ready, see our SOC 2 readiness work, or talk to a fractional CISO about building a program around it.

Where it comes up

The gap that hurts is almost never the document. It is that nobody has decided who declares an incident, who talks to customers, and which regulator or contract has a clock running.

For compliance, the artefacts are a written plan, evidence it was tested, and for any incident that occurred, the record and the post-incident review. A plan that has never been exercised is the most common finding in this area.

Incident Response: common questions

Does SOC 2 require an incident response plan?

Yes, and it also expects evidence that the plan was tested. A documented tabletop exercise is the usual way to satisfy that.

How often should we test the plan?

At least annually. A half-day tabletop is enough for most organisations and produces exactly the evidence an auditor asks for.

Track record

Who is actually doing the work

5
Published CVEs, including a CVSS 9.1
76
Controls taken from nothing to a passed SOC 2 Type II
Zero
Exceptions on that Type II report
20+
Penetration testing engagements delivered

Published vulnerability research

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.

A SOC 2 Type II built from nothing

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.

Before you go

Want the practical version by email?

Definitions only get you so far. I send a few short notes on how this plays out in practice. Unsubscribe in one click, and replies reach me directly.

From Jacob Masse, principal of traztech. No spam, unsubscribe in one click.