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 →
Compliance

Do You Actually Need ISO 27001?

You need ISO 27001 certification if you sell into enterprise, government, or European customers who require independently audited proof of an information security management system, or if you operate in a regulated sector where a recognized international standard is table stakes. If your buyers are mostly North American SaaS companies asking about your security posture, you may not need it at all, and a SOC 2 report will answer the question faster and cheaper.

What ISO 27001 Certification Actually Proves

ISO 27001 certifies that you run a documented information security management system, an ISMS, that covers risk assessment, controls selection, and continual improvement. An accredited certification body audits you against the standard (currently ISO/IEC 27001:2022) and issues a certificate valid for three years, with surveillance audits in between. It is a management-system certification, not a point-in-time control test. That distinction matters because it changes who actually benefits from it.

Unlike SOC 2, which produces a narrative report describing your controls and whether they operated effectively over a period, ISO 27001 produces a certificate and a Statement of Applicability. Some buyers, especially outside North America, trust the certificate model more because it is globally recognized and repeatable across borders. Others, particularly US-based SaaS buyers, are more used to reading a SOC 2 Type II report line by line. Knowing which one your buyers expect saves you from certifying against the wrong standard.

Who Genuinely Needs ISO 27001

Certification earns its cost back for a specific set of companies:

  • Companies selling into Europe or Asia. ISO 27001 is the default expectation in many procurement processes outside North America, and it often satisfies GDPR-adjacent vendor due diligence questions without additional work.
  • Government and public-sector vendors. Many RFPs and supplier registries require ISO 27001 as a hard gate before you can even bid.
  • Multinationals with a global customer base. If your sales team is fielding security questionnaires from procurement teams on three continents, one certification that is universally recognized beats juggling multiple regional frameworks.
  • Companies that already need a formal ISMS for operational reasons. If you are managing security across multiple business units, subsidiaries, or after an acquisition, the ISMS structure itself, not just the certificate, brings real governance value.
  • Canadian firms bidding on international contracts from Toronto, Vancouver, or Montreal head offices who need a credential that travels outside PIPEDA's domestic scope.

Who Is Over-Buying ISO 27001

We see a lot of over-buying, usually driven by fear rather than an actual customer requirement. Signs you are about to spend six figures and a year of internal effort on a certification nobody asked for:

  • Your sales team has never lost a deal or been blocked by a security questionnaire that specifically demanded ISO 27001 rather than "a recognized security framework."
  • Your customer base is entirely US and Canadian mid-market SaaS buyers who ask for a SOC 2 report by name.
  • You are a seed or Series A company hoping certification will accelerate sales cycles that are actually stalled by product-market fit, not security trust.
  • A consultant or vendor recommended ISO 27001 without asking who your buyers are or what they actually require.

In these cases, a SOC 2 Type II report, or even a well-documented internal security program, gets you the same trust signal for a fraction of the cost and calendar time.

Running ISO 27001? Our ISO 27001 readiness track builds the ISMS that survives Stage 1 and Stage 2, with the Statement of Applicability an auditor will accept. ISO 27001 readiness

ISO 27001 vs SOC 2: The Practical Difference for Canadian Companies

The two frameworks overlap heavily in substance, encryption, access control, incident response, vendor management, but differ in packaging and audience. SOC 2 is an AICPA attestation, dominant with US and Canadian B2B SaaS buyers. ISO 27001 is an ISO/IEC standard with global accreditation bodies, dominant with European, government, and multinational procurement. Some Canadian companies pursuing both frameworks discover the overlap is substantial enough that a well-built ISMS can support a SOC 2 audit with incremental work rather than starting over. If you already hold SOC 2 and are now getting ISO 27001 requests from an expanding customer base, that overlap is worth exploiting rather than rebuilding your control environment from scratch. There is also a Canadian privacy layer that neither framework covers on its own. PIPEDA and Quebec's Law 25 impose obligations around consent, breach notification, and data subject rights that sit outside ISO 27001's scope. A readiness engagement that maps your ISMS controls against both the ISO standard and Canadian privacy law closes gaps that a generic international consultant, unfamiliar with Canadian statutes, often misses entirely.

What ISO 27001 Readiness Actually Involves

Certification itself is performed by an accredited third-party body, traztech does not issue certificates. What we run is the readiness work that gets you to a clean audit: scoping the ISMS, running the risk assessment, building the Statement of Applicability, closing control gaps, and rehearsing the Stage 1 and Stage 2 audits with your team. For most companies this takes three to six months depending on how mature your existing security program is and how many locations or business units fall inside scope. The most common failure mode we see isn't a missing control, it's scope creep. Companies define the ISMS boundary too broadly, pulling in systems and teams that have nothing to do with the customer data or service being certified, which multiplies audit evidence collection for no buyer benefit. Getting the scope right on day one is the single highest-leverage decision in the whole project. See our ISO 27001 implementation service for how we structure that scoping and readiness work.

How to Decide, in Practice

Ask three questions before committing budget. First, has a named customer or prospect explicitly required ISO 27001, in writing, as a condition of the deal. Second, do you sell outside North America or into government procurement where it is a standard gate. Third, would the twelve months and cost be better spent closing SOC 2 gaps that your actual pipeline is asking for. If the honest answer to all three points away from ISO 27001, wait until the demand is real. Certifications you don't need don't protect revenue, they just sit on a shelf while draining engineering time that should be going into product security work. traztech serves technology companies across Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal, and we'd rather tell you honestly that you don't need a certification than sell you one you'll never use. If you want a straight read on whether ISO 27001, SOC 2, or a lighter compliance path fits your actual buyer requirements, get in touch and we'll walk through it with you.

What the Certification Audit Actually Consists Of

Companies budget for "an ISO 27001 audit" as though it were one event. It is two, followed by several years of smaller ones. Stage 1 is a documentation and readiness review where the auditor checks that your management system exists on paper: scope statement, information security policy, risk assessment methodology and results, Statement of Applicability, internal audit programme, and evidence that management review has happened at least once. Auditors frequently issue findings at Stage 1 that are not control failures at all, they are management-system failures, such as a risk methodology that produces scores nobody can reproduce, or an internal audit that was performed by the same person who built the controls.

Stage 2, usually four to eight weeks later, is the operating audit. The auditor samples: pick three joiners from the last six months and show the access request and approval, pick two suppliers onboarded this year and show the security assessment, show the last three change approvals for production, show the incident log and walk through one entry end to end. What separates a smooth Stage 2 from a painful one is almost never control design. It is whether the records exist with dates that make sense, and whether the person who owns each control can describe it without reading the policy aloud.

After certification, surveillance audits run in years one and two on a reduced scope, and a full recertification audit happens in year three. Budget for those from the start. A company that treats certification as a project rather than an ongoing programme tends to arrive at its first surveillance audit with an internal audit that never ran and a management review that never happened, which produces findings against clauses 4 to 10 rather than against any technical control.

The Statement of Applicability Is Where the Project Is Won or Lost

The Statement of Applicability lists all 93 Annex A controls, states whether each applies to your ISMS, gives the justification, and points at how it is implemented. It is the document auditors use to navigate everything else, and it is the document most often produced badly.

Two failure patterns dominate. The first is the Statement of Applicability that marks every control applicable to avoid arguments, which commits you to evidencing controls you do not need. If you run no on-premises data centre, physical controls specific to one apply differently than they would for a manufacturer with a server room, and saying so with a clear justification is legitimate. The second pattern is exclusion without reasoning: marking a control not applicable because implementing it looked expensive. Auditors read exclusions closely, and an exclusion that contradicts your own architecture diagram is an immediate finding.

Write the justification in your own operational language. "Not applicable: the organization operates no development activity" is defensible if true. "Not applicable per risk assessment" is not a justification, it is a reference to a document the auditor will now open and test. Keep the Statement of Applicability under version control and update it when the environment changes, because a stale one is the fastest way to demonstrate that your management system is not actually managing anything.

Choosing a Certification Body, and What to Ask Them

Not every organization offering ISO 27001 certificates is accredited, and a certificate from an unaccredited body will be rejected by exactly the sophisticated buyers you bought it for. Check that the body holds accreditation from a recognized national accreditation body and that your certificate will carry that accreditation mark. Then ask four practical questions before signing: how many audit days are quoted and on what basis, who the lead auditor will be and what sectors they have audited, how remote versus onsite time is split, and what their process is for closing a minor nonconformity.

Quotes vary widely for the same scope, and the variation is usually driven by the audit day count the body calculates from your headcount, site count, and scope complexity. This is where a tightly written scope pays for itself twice: once in reduced readiness effort, and once in a smaller audit quote. On one engagement the audit firm reduced its own quote by $11,000 once the readiness position was documented, which we wrote up in our auditor vetting case study. Ask the body to show how the day count was derived, and give them an accurate scope description rather than a conservative overstatement of your environment.

Nonconformities, and What Happens When You Get One

Findings are graded. A minor nonconformity means a control or clause requirement has a lapse that does not undermine the system: an access review that ran a month late, a supplier assessment missing for one vendor. You submit a corrective action plan, usually within a few weeks, showing root cause, correction, and how you will prevent recurrence, and certification proceeds. A major nonconformity means a requirement is absent or systemically failing: no internal audit at all, a risk treatment plan that was never executed, evidence that a documented control has not operated for the audit period. A major typically blocks certification until it is closed and verified, sometimes with a return visit.

The corrective action write-up matters more than teams expect. Auditors are reading for genuine root cause analysis, and "we forgot" followed by "we will remember" gets rejected. A credible response identifies why the process allowed the lapse, changes the process, and shows the change operating at least once. Companies that treat corrective actions as paperwork tend to see the same finding return at surveillance, which escalates it.

Worth naming plainly: audits far more often stall than fail outright. An auditor who cannot get an evidence request answered simply pauses, and the calendar slips while your sales team keeps promising a certificate date. Keeping the auditor moving is a logistics discipline, one named coordinator, a single evidence location, same-day acknowledgement of requests, and it is worth more to your timeline than any additional control work.

Cost Drivers Nobody Quotes You For

The certification body's fee is the visible cost and often the smaller one. The larger costs are internal. Headcount inside scope drives audit days. Number of physical sites drives travel and sampling. Number of production environments drives evidence volume. Whether you have a functioning ticketing system determines whether evidence collection is a query or an archaeology project.

Then there are the clause 4 to 10 obligations that carry no technology at all: competence records showing that people in security roles are qualified, awareness training with completion records, documented management review with attendance and decisions, and an internal audit performed by someone independent of the work being audited. Small companies often have to buy the internal audit externally, because independence is genuinely hard to achieve with fifteen employees. Budget for it rather than discovering the independence requirement at Stage 1.

One more: the ISMS needs an owner with time. Not a committee, an owner. Certification projects that fail almost always share the property that responsibility was distributed evenly across people who all had another full-time job. If you have nobody who can hold it, a fractional CISO arrangement is a cheaper way to buy the ownership than hiring for it, and a more honest one than pretending a founder will run it in evenings.

When You Should Not Certify, Even If You Could Afford To

Some of the strongest reasons to walk away have nothing to do with cost. If your product architecture is about to change materially, a platform migration, a move from single-tenant to multi-tenant, a re-founding of the data model, certify afterwards. Certification pins a description of your environment for three years and every material change requires you to update the scope, the risk assessment, and the Statement of Applicability. Certifying a system you are about to replace buys you a certificate for a thing that will not exist.

If you are mid-acquisition or expect to be acquired, ask the acquirer what they want before you spend. Some buyers value the certificate, others will fold you into their own management system and treat your certificate as an artefact to be retired. That conversation takes an hour and can save a year.

If your only driver is a single European prospect who mentioned ISO 27001 in passing, go back and ask whether they accept an alternative. Many procurement teams will accept a SOC 2 Type II report plus a completed security questionnaire and a recent penetration test, particularly for a smaller vendor with a narrow data footprint. Get the answer in writing from the person who owns the requirement, not from your champion, who is often guessing on their security team's behalf.

And if you already hold SOC 2 and the ISO requests are occasional, the right move is often to wait until the volume justifies the programme rather than certifying pre-emptively. Two or three requests a year that you can handle with a well-written security package cost far less than an ISMS, an internal audit function, and a three-year audit cycle. When the requests become routine, the economics flip, and the overlap with your existing control environment means the incremental work is smaller than starting cold. Our ISO 27001 implementation page sets out how we scope that incremental path, and our pricing page shows how the readiness work is packaged so you can compare it against the certification body's quote before committing to either.

Running ISO 27001? Our ISO 27001 readiness track builds the ISMS that survives Stage 1 and Stage 2, with the Statement of Applicability an auditor will accept.

ISO 27001 readinessOr talk about a retainer

Before you go

Want the rest of this by email?

If this was useful, I send a few short notes on ISO 27001. Unsubscribe in one click, and replies reach me directly.

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

Want a second opinion on where you stand?

We run SOC 2, ISO 27001 and the rest of the compliance stack for startups and SMEs, and the security testing that sits behind it. The first call is free, and we will tell you if you are not ready to start yet.

Book a free call

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.