What Is ISO 27001? A Plain-Language Guide (2026)

If you've been asked by a customer, an investor, or a procurement team whether your company is "ISO 27001 certified," you're not alone in not knowing exactly what that means. It's one of the most requested credentials in B2B sales, and one of the least understood outside of security teams. Here's what it actually is, who needs it, and what getting there really looks like.

What ISO 27001 actually is

ISO 27001 is an international standard for an information security management system, usually shortened to ISMS. It's published jointly by the International Organization for Standardization and the International Electrotechnical Commission, which is why you'll sometimes see it written as ISO/IEC 27001.

The key thing to understand is that ISO 27001 doesn't certify a product or a piece of software. It certifies a system, specifically, the way your organization identifies security risks, decides how to handle them, and proves it's actually following through. That system covers policies, people, processes, and technical controls, all documented and reviewed on an ongoing basis.

Certification is issued by an accredited third-party certification body after an audit. It isn't self-declared and it isn't something you can print off a template and call done. An auditor examines your ISMS against the standard's requirements and the 93 controls listed in Annex A, then decides whether to issue the certificate.

Who actually needs it

ISO 27001 shows up most often in a few recurring situations:

• Selling into Europe or the UK. ISO 27001 is the dominant security standard outside North America, similar to how SOC 2 dominates in the US.
• Enterprise procurement requirements. Large buyers, particularly in financial services, telecom, and government-adjacent sectors, often list ISO 27001 as a hard requirement in vendor security questionnaires.
• Multinational operations. Companies operating across several jurisdictions like having one recognized standard rather than juggling different regional frameworks.
• Investors and boards asking for proof of a mature security program, not just a policy binder nobody has opened in a year.

If your buyers are mostly US-based SaaS companies, you'll more often be asked for SOC 2. Many Canadian companies selling on both sides of the Atlantic end up pursuing both, and there's real overlap in the underlying controls, so the second certification is rarely starting from zero.

What the process actually involves

At a high level, getting certified involves five stages, and none of them are optional shortcuts:

• Risk assessment. You identify the information assets that matter (customer data, source code, infrastructure) and the risks to them.
• Statement of Applicability. You decide which of the 93 Annex A controls apply to your business and document why others don't.
• Implementation. You put the chosen controls into practice: access management, encryption, incident response, vendor risk management, employee training, and more.
• Internal audit and management review. Before the real audit, you test your own system and fix what's broken.
• Certification audit. This happens in two stages, typically weeks apart: a documentation review, then an on-site or remote assessment of whether the controls are actually operating as described.

Certification isn't a one-time event either. It's valid for three years, with surveillance audits typically each year to confirm the ISMS is still functioning, not just filed away.

Realistic timeline

Most companies starting from a reasonably mature security baseline should plan for three to six months to prepare for the initial audit. Companies starting from scratch, with no formal policies or documented processes, are usually looking at six to twelve months. The variables that move the needle most are the size of the organization, how much of the infrastructure is cloud-based versus custom, and how much internal bandwidth is available to do the work rather than hire it out.

Vendors selling "ISO 27001 in 30 days" are selling a document package, not a functioning ISMS that will survive an audit. Be skeptical of any timeline that sounds too fast for the amount of organizational change involved.

For a structured breakdown of the phases and what each one costs in time and effort, our ISO 27001 implementation service walks through the full readiness process we run with Canadian companies, including how to scope the ISMS before you start burning calendar time on the wrong controls.

Common misconceptions

"It's just a checklist." Annex A gives you a list of controls, but the standard requires you to justify, implement, and operate them in a way specific to your actual risks. An auditor testing evidence will notice a checklist masquerading as a management system.

"It's the same as SOC 2." They cover a lot of the same ground but aren't interchangeable. SOC 2 is an attestation report built around Trust Services Criteria and is more common in the US. ISO 27001 is a certification against an international standard and is more commonly requested outside North America. Some companies need one, some need both.

"Once you're certified, you're done." Certification requires ongoing operation of the ISMS, annual surveillance audits, and recertification every three years. Treating it as a one-time project is the most common reason companies fail their first surveillance audit.

"It covers privacy compliance too." ISO 27001 is a security management standard, not a privacy law. Canadian companies still need to separately address PIPEDA obligations, and Quebec-based companies or those handling Quebec residents' data have additional requirements under Law 25. There's real overlap between good security controls and privacy compliance, but ISO 27001 certification alone doesn't satisfy either law on its own.

"Small companies don't need it." Company size matters less than who your customers are. A ten-person company selling to a European enterprise buyer may need ISO 27001 well before a two-hundred-person company selling only within Canada does.

Where to start

The most useful first step isn't buying software or hiring an auditor, it's a gap assessment against the current state of your security program. That tells you which controls already exist, which need to be built, and roughly how much work is involved before you set a target audit date. If security and compliance work in your organization is still scattered across a few different owners, it's also worth looking at how a broader compliance program ties ISO 27001 into whatever else you're already tracking, rather than treating it as an isolated project.

If you're weighing ISO 27001 against SOC 2, or trying to figure out how PIPEDA and Law 25 fit into an ISMS you're building for a Canadian company, that's exactly the kind of question worth a direct conversation before you commit budget or a target date. Get in touch and we'll help you figure out the right starting point.

What the standard actually contains

People talk about ISO 27001 as though it were the 93 Annex A controls. Those controls are the part everyone quotes, but they are not the certifiable requirements. The requirements live in clauses 4 through 10 of the main body, and an auditor cannot pass you on controls alone. It is worth knowing what each clause asks for, because these are the sections companies skip and then get findings on.

Clause 4, context of the organization. You write down what your organization does, who your interested parties are (customers, regulators, investors, employees), what they expect of you regarding information security, and where the boundary of your management system sits. The scope statement produced here ends up printed on your certificate. Since the 2024 amendment, you are also expected to consider whether climate change is a relevant issue in this analysis and to record the conclusion either way.

Clause 5, leadership. Top management has to demonstrate commitment, which in audit terms means signed approvals, an information security policy issued at the right level, and evidence that leadership allocated resources and assigned roles. An auditor will often interview a founder or executive directly here, and "our security lead handles that" is a poor answer.

Clause 6, planning. This is the risk assessment and risk treatment engine. You need a documented methodology, defined criteria for accepting risk, identified risks with owners, chosen treatment options, and measurable information security objectives with plans to achieve them. "Reduce risk" is not an objective. "Patch internet-facing critical vulnerabilities within seven days, measured monthly" is.

Clause 7, support. Competence, awareness, communication, and control of documented information. In practice: training records, evidence that people know what your policies require of them, and version control on your documents.

Clause 8, operation. Evidence that the plans from clause 6 were actually carried out, that risk assessments happen at planned intervals, and that changes were controlled.

Clause 9, performance evaluation. Monitoring and measurement, internal audit, and management review. This is the most commonly failed clause in first certifications and in surveillance audits alike.

Clause 10, improvement. Nonconformities get recorded, root causes get analyzed, corrective actions get taken, and the record shows it. An organization with an empty nonconformity log after a year is not an organization with no problems, and auditors read it that way.

Annex A in the 2022 structure

The 2022 revision reorganized the controls from fourteen domains into four themes: 37 organizational controls, 8 people controls, 14 physical controls, and 34 technological controls. If you are reading older material that describes fourteen domains and 114 controls, it predates the current version, and every valid certificate today is against the 2022 text.

Eleven controls were introduced in that revision, and they are the ones most likely to be new work for a cloud-native company. Threat intelligence asks you to consume and act on information about relevant threats rather than waiting for something to happen to you. Information security for use of cloud services asks for a defined process for selecting, using, and exiting cloud providers, which for a SaaS company is most of your estate. ICT readiness for business continuity asks you to test recovery, not just document it. Physical security monitoring applies even to companies whose only physical asset is an office and a set of laptops. Configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding round out the set.

The physical controls surprise remote-first companies most. Fourteen physical controls do not disappear because you have no data centre; they get answered through your cloud provider's own certification for the infrastructure layer, and through your own arrangements for offices, home working, and equipment handling. Auditors will ask how you retrieve a laptop from an employee in another province who has stopped answering email, and the honest answer needs a process behind it.

The Statement of Applicability, and why auditors read it first

The Statement of Applicability is the document that connects your risk work to the controls. For each of the 93 controls it records whether the control applies, the justification for that decision, whether it is currently implemented, and where the implementation is described. It is the single most scrutinized artifact in a Stage 1 audit because it reveals, in a page or two, whether anyone actually thought about the standard or whether a template was downloaded and lightly edited.

The failure patterns are consistent. Every control marked applicable, including ones that plainly are not, which multiplies your evidence burden for no benefit. Justifications copied verbatim across dozens of rows, which tells the auditor no analysis happened. Controls marked implemented when the implementation is a policy sentence rather than an operating practice. Exclusions with no traceable link back to a risk decision. And a Statement of Applicability that was accurate in March and never touched again, which fails at surveillance because the environment moved.

A well-built Statement of Applicability is the cheapest insurance in the project. It shortens Stage 1, sets the boundaries of Stage 2 sampling, and gives you a defensible answer when an auditor questions why something is out of scope.

What the two audit stages feel like in practice

Stage 1 is a documentation and readiness review, usually one to two days, often remote. The auditor reads your scope, your Statement of Applicability, your risk assessment and treatment plan, your policy set, and your internal audit and management review records. They are checking that the management system exists and is coherent enough to be tested. They will produce observations and, frequently, a list of things to fix before Stage 2. Failing to pass Stage 1 is rare; being told your internal audit was inadequate and Stage 2 must be delayed is not.

Stage 2 is the operational audit, longer, and it is mostly interviews. The auditor picks control owners and asks them to walk through what they do, then asks for the evidence. They sample: five leavers from your last twelve months, three change tickets, one incident, two supplier reviews. The controls themselves are rarely the difficulty. The difficulty is that a control owner describes a process that differs from the written procedure, or the sample of five leavers contains one whose access was removed eleven days late with no record of why.

The most useful preparation is not more documentation. It is walking each control owner through their own control the week before, in the same question format the auditor will use, and fixing whatever that rehearsal exposes. If you want the calendar view of how this fits together, we set it out in how long ISO 27001 takes.

How to read someone else's certificate

This cuts both ways, because your customers will do it to you and you should be doing it to your suppliers. Four checks take about five minutes.

Check the accreditation mark, not just the certification body's logo. An accredited certificate carries the mark of a national accreditation body operating under the IAF multilateral arrangement. Certificates without one exist and are worth considerably less in procurement.

Read the scope statement carefully. A certificate whose scope covers "the corporate IT function at the head office" tells you nothing about the platform you are buying. Scope is where most vendor certificates quietly fail to answer the question that was asked.

Check the dates and the certificate number. Certificates run three years and are surrendered or suspended more often than people assume. Most certification bodies publish a searchable register, and a certificate number that does not resolve in the issuer's register is worth a direct question.

Ask for the Statement of Applicability, or at least for the list of excluded controls. Suppliers are not obliged to hand it over and many will not, but the exclusions are where you learn what the certificate does not cover.

What you can and cannot claim once you are certified

Certification applies to your management system within a defined scope, not to your product. You cannot describe a feature as ISO 27001 certified, and rules on the use of accreditation marks in marketing are stricter than most companies realize. Your certification body will give you a mark usage guide; read it, because misuse is a compliance issue with the body that issued your certificate.

The practical phrasing that holds up is naming the standard, the scope, and the issuing body together. That is also the phrasing that answers a procurement question fastest, because the reviewer is trying to establish exactly those three facts.

When ISO 27001 is the wrong answer for you

Plenty of companies come to us wanting certification and leave the call with a cheaper plan, which is a better outcome for both sides than a project that gets abandoned in month five.

Your buyers are American. If every account in your pipeline is a US SaaS or fintech company, they will ask for SOC 2 and a certificate will not shorten a single security review. Do that first and revisit ISO when a European or UK deal is actually on the table. The decision test is whether a named deal is blocked, not whether a competitor displays a badge.

Nobody can own the management system. ISO 27001 is not a project with an end date, it is a cadence: risk reviews, internal audits, management reviews, corrective actions, every year. If there is no one at your company with protected time for that, the certificate will lapse at the first surveillance audit and you will have paid for a document set. Fix the ownership question before the framework question.

You are pre-product or pre-revenue. Certifying a system you are about to rebuild means recertifying a scope that no longer describes you. Wait until the architecture has settled.

You want it for credibility rather than for a requirement. Certification is a poor marketing instrument relative to its cost. A published security page, a recent penetration test summary, and answers to a standard questionnaire do more for early trust at a fraction of the price. You can build the control register, policy set, and evidence trail behind that in the free traztech Workspace without paying anyone, and if it turns out you do need the certificate, none of that work is wasted.