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 →
Checklist · 2026

The SOC 2 readiness checklist

Every control area an auditor actually checks, in plain English, with what to do about each one. Read the whole thing here for free. When you want the editable version to track progress with your team, grab it below.

SOC 2 feels huge until you realise it is really a finite list of things you either do or you do not. An auditor is checking whether you manage access, control changes, protect data, watch your systems, and can respond when something goes wrong. Get those in order and the report mostly writes itself.

This is the checklist we use to get startups audit-ready. It is organised by the areas an auditor groups their questions into. Work top to bottom, be honest about what is missing, and you will have a real gap list by the end of an afternoon.

Want the editable version?

Get this checklist as an editable tracker you can share with your team and tick off as you go. We will send it over and include a couple of the templates we use.

01 Governance and policies

Auditors want written policies that match how you actually work, plus evidence someone owns security.

  • An information security policy exists, is approved, and is reviewed at least annually
  • Acceptable use, access control, change management, and incident response policies are documented
  • A named person or role owns security, even if it is a founder or a fractional CISO
  • Employees acknowledge the policies when they join and yearly after
  • A risk assessment has been done and is revisited on a schedule

02 Access control and identity

The single most common source of findings. Prove that the right people, and only the right people, can reach your systems and data.

  • Multi-factor authentication is enforced on all systems, with no exceptions
  • Single sign-on is used for internal tools where possible
  • There are no shared or generic logins, and any that existed have been rotated
  • Access is granted by role and follows least privilege
  • Access is reviewed on a regular cadence, and removed promptly when someone leaves
  • Production access is restricted and logged

03 Change management

Show that code and infrastructure changes are reviewed and traceable, not pushed straight to production on a whim.

  • Code changes go through pull requests with a required reviewer
  • The main branch is protected and cannot be force-pushed
  • Deployments are automated and leave a record of what shipped and when
  • Infrastructure changes are tracked, ideally as code

04 Infrastructure and network security

The basics of not leaving the doors open. Auditors and buyers both look here.

  • Cloud accounts follow least privilege, with no over-permissioned root or admin use
  • Storage buckets and databases are not publicly exposed by accident
  • Networks are segmented and only necessary ports are open
  • Systems are patched on a defined schedule
  • Endpoints have protection such as EDR, and disks are encrypted

05 Data protection

Prove customer data is encrypted, backed up, and recoverable.

  • Data is encrypted in transit and at rest
  • Encryption keys and secrets are managed properly, not hard-coded
  • Backups run automatically and have been tested by actually restoring
  • Data retention and deletion practices are documented

06 Logging and monitoring

You cannot detect or investigate what you do not log. Auditors want evidence you would notice something going wrong.

  • Centralized logging is in place with sensible retention
  • Access to production and sensitive data is logged
  • Alerts exist for meaningful security and availability events
  • Someone is responsible for looking at them

07 Vendor and third-party risk

Your subprocessors are part of your attack surface, and buyers will ask about them.

  • A list of vendors and subprocessors that touch customer data exists
  • Critical vendors are reviewed, ideally by collecting their SOC 2 or equivalent
  • Data processing agreements are in place where needed

08 Human resources and personnel

The people controls that surround access and data handling.

  • Background checks are run on new hires where appropriate
  • Security awareness training happens at onboarding and annually
  • Onboarding and offboarding checklists cover access, equipment, and accounts

09 Incident response

A plan you have actually tested, not a document nobody has read.

  • An incident response plan exists with roles, severities, and escalation paths
  • The plan has been tested with at least a tabletop exercise
  • Breach notification obligations, including under Canadian privacy law, are understood

10 Availability and continuity

For the availability criteria, show your service can survive a bad day.

  • Uptime and performance are monitored
  • A business continuity or disaster recovery approach is documented
  • Recovery has been tested, not just written down

That is the shape of SOC 2. If you can honestly tick most of these, you are closer than you think. If large sections are blank, that is normal at the start, and it is exactly the work we do. For the bigger picture, see SOC 2 for Canadian SaaS, or how the whole program runs on our compliance page. If you want a fractional CISO to own the program end to end, we do that too.

We can turn this list into a plan

Send us your gaps and your deadline, and we will scope the fastest honest path to audit-ready. Fixed price, no invented numbers.

Book a free readiness call

You are reading a checklist. This is the working version

Every item here exists as a control in traztech Workspace, with what the standard actually asks for, what to do about it, and somewhere to attach the proof. It scores as you answer, so you can see where you stand instead of counting ticks in a document.

No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.

traztech Workspace Other GRC platforms
Licence cost $0. Free forever, no card, no paid tier $7,500 to $50,000 a year, on an annual contract
Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring Included Included
What it costs inside an engagement with us $0. You need a workspace either way Unchanged. The subscription sits on top of the fee
What it does to your audit quote $11,000 off a five-figure quote on one engagement, for a documented readiness position Nothing. The audit firm prices your readiness, not your tooling

Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.

Track record

Who is actually doing the work

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.

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
75 days
Readiness window we have hit every time we have run it
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.

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.

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.

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.

Recent engagements

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.