What Is ISO/IEC 27001:2022, And Do You Need It?

Updated: June 18, 2026

Marcus runs a Series B fintech startup out of Mission Bay. Last year, he was three weeks from closing a contract with a large European payments processor when their security team sent over a forty-three-page-long vendor questionnaire. Marcus had been through this before with US enterprise buyers, and his SOC 2 Type II had always been enough. He skimmed to the security certifications section and stopped.

"Are you ISO/IEC 27001 certified? Please provide your current certificate, including the version of the standard under which it was issued."

He called me that afternoon. We had worked together before on his SOC 2 program, and he had the reasonable assumption that the two certifications were roughly interchangeable. They are not. SOC 2 is a US-market standard. ISO 27001 is the internationally recognized one, and the European buyer in front of him considered it a baseline, not a differentiator. No certificate, no contract.

We spent the next two hours on the phone going through what ISO 27001 actually is, how the standard changed in 2022, and what a realistic path to certification looked like for a company his size. This post is essentially that conversation written down.

The Security Controls Patchwork Problem

I want to start where I started with Marcus, which is not with the standard itself but with the problem it was designed to solve.

Most companies accumulate security controls the same way they accumulate technical debt: reactively. A vendor audit flags a gap, so a tool gets added. A near-miss incident prompts a new policy. An engineer leaves, and someone realizes the offboarding process was never formalized. Over time, you end up with a patchwork: strong in some areas, blind in others, and held together by institutional memory that walks out the door whenever someone leaves.

Marcus recognized this immediately. His team had done real security work. But it had accrued in layers, and no one had ever mapped the whole thing or asked whether the pieces added up to coherent protection.

ISO/IEC 27001 is an international standard published jointly by the International Organization for Standardization and the International Electrotechnical Commission. What it gives you is a framework for building and maintaining an Information Security Management System (ISMS): a documented, auditable, continuously improving system that replaces the patchwork with something you can actually defend.

The standard tells you how to assess your risks systematically, which controls to consider applying, and how to demonstrate that your actual security posture matches what you claim on vendor questionnaires. That last part is what enterprise buyers are paying for when they ask for the certificate.

ISO 27001:2013 vs. 2022: The Version Problem Marcus Did Not Know He Had

Before I could tell Marcus what certification would require, I had to explain something he had not expected. Even if he had held an ISO 27001 certificate, it might already be worthless.

The standard was last updated in October 2022. The previous version, published in 2013, was retired as of October 31, 2025. Any certificate still referencing ISO/IEC 27001:2013 expired on that date automatically, regardless of when it was issued or when it was due for renewal. If your organization is holding a 2013 certificate and has not completed the transition to the 2022 version, you are not certified.

The 2022 update is not a complete overhaul: the core management structure, the eleven clauses that define how you run an ISMS, remains largely intact with minor clarifications. The major changes are in Annex A, the catalogue of security controls the standard draws from.

In the 2013 version, Annex A contained 114 controls organized across 14 domains. In the 2022 version, those have been consolidated into 93 controls grouped under four clearer themes: Organizational, People, Physical, and Technological. The reduction looks like controls were removed, but what actually happened is that 57 controls were merged into 24 to eliminate redundancy, and 11 brand-new controls were added to address security realities that barely existed in 2013.

I walked Marcus through the new controls most relevant for a company like his. Threat Intelligence (A.5.7) now requires organizations to actively gather and analyze information about current threats rather than just reacting to them. Information Security for Use of Cloud Services (A.5.23) formalizes how you vet and monitor cloud vendors and infrastructure dependencies. Data Leakage Prevention (A.8.12) and Data Masking (A.8.11) address how sensitive financial data is handled and protected. For a fintech company touching payment data, these were not abstract requirements.

"So we would have had gaps even if we had certified in 2020," Marcus said. That was right. The 2022 standard reflects the security environment companies actually operate in now, not the one from a decade ago.

Why Enterprise Buyers Are Requiring ISO 27001

Marcus's situation is not unusual. I have watched ISO 27001 shift from a differentiator to a baseline expectation over the past several years, particularly for companies selling into European markets, financial services, healthcare, or government contracts. The numbers reflect that shift.

According to the ISO Survey, the number of valid ISO 27001 certificates worldwide nearly doubled between 2023 and 2024, reaching 96,709 certified organizations globally. When that many organizations in your industry hold the certificate, the companies that do not have one start to look like the outliers.

Part of what is driving that growth is the underlying math of security failures. The IBM Cost of a Data Breach Report 2025 found the global average cost of a data breach reached $4.4 million, a 10% increase from the prior year and the largest annual jump since the pandemic. For companies in financial services specifically, the average breach cost is $5.56 million. Enterprise buyers who require ISO 27001 from their vendors are not being bureaucratic. They are managing their own exposure.

I explained this to Marcus in terms he found useful. The questionnaire his buyer sent was not really about the certificate. It was about whether his company had built the kind of documented, auditable security program that would hold up under scrutiny if something went wrong. ISO 27001 certification is the third-party verification that it does.

There is also a regulatory alignment argument that matters more than most founders realize. ISO 27001 does not replace GDPR, HIPAA, or CCPA compliance, but implementing it creates significant overlap with those frameworks. Many of the controls required for certification address data protection requirements that regulators under those frameworks also care about. If you are subject to multiple compliance regimes, that overlap reduces the total work considerably.

And then there is the audit burden. Marcus told me his team had spent the equivalent of three weeks in the prior year responding to one-off security questionnaires and audits from prospective customers. ISO 27001 certification from an accredited body is accepted by most enterprise buyers as a substitute for those one-off reviews, because it already is an independent third-party assessment. The certificate pays back in time saved.

The Question Marcus Actually Needed to Answer

About halfway through our conversation, Marcus asked the question that was actually on his mind: "Should we have done this before SOC 2?"

It depends on who you are selling to. SOC 2 Type II tends to satisfy most US enterprise security teams and is the more natural first step for companies whose customer base is primarily domestic. If you are pre-Series A, selling to SMBs, and have not yet been asked for ISO 27001, pursuing it before SOC 2 is probably not the right use of resources.

But Marcus was Series B, actively selling into European markets, and had just watched a contract stall because of the gap. For him, the question was not whether to pursue certification but how quickly he could get there.

There is a timing reality worth naming directly. If a deal is contingent on ISO 27001 certification and you are starting from scratch, nine months is an optimistic timeline. Enterprise sales cycles often move faster than compliance programs. The companies that handle this well build the ISMS discipline before they need the certificate, not after a buyer asks for it.

The underlying practice of conducting a formal risk assessment and maintaining documented security policies has value regardless of whether you pursue certification. Organizations that build the system early spend significantly less time scrambling when certification becomes a deal requirement.

What Getting ISO 27001 Certification Actually Looks Like: A Step-by-Step Guide

By the end of our call, Marcus wanted to understand the practical sequence. Here is how I laid it out.

The first step is defining scope. The scope of your ISMS determines which systems, locations, and business processes the standard covers. Defining it carefully matters because scope shapes cost, timeline, and audit complexity. A startup can scope its ISMS narrowly around its core product and customer data infrastructure and still achieve certification that satisfies most enterprise requirements. Starting narrow and expanding later is almost always the right call.

From there, you conduct a formal risk assessment against your defined scope. You identify your information assets, assess the threats and vulnerabilities relevant to each, determine likelihood and impact, and document how you intend to treat each risk. The quality of your risk assessment determines the quality of everything downstream, and this is the step where most organizations benefit most from outside expertise.

Based on that assessment, you select the Annex A controls that apply to your organization, implement them, and document the implementation. Your Statement of Applicability records every control in Annex A, whether you have implemented it, and your justification for any you have excluded. That document becomes the spine of your audit.

ISO 27001 also requires documented training for staff with information security responsibilities. This is not checkbox training. Auditors ask employees direct questions about security policies and their own responsibilities during Stage 2. The people dimension of an ISMS is where most organizations underinvest, and it shows under audit.

Certification itself happens in two stages. Stage 1 is a documentation review: the auditor assesses whether your ISMS is designed correctly and your documentation is in order. Stage 2 is the certification audit, where the auditor verifies that your ISMS is actually operating as documented, not just described on paper. Before Stage 2, you need to demonstrate that the system has been running through internal audits, a management review, and corrective actions closed out. Most organizations underestimate how long this internal cycle takes. Build it in from the start.

What I Told Marcus to Watch Out For

Marcus asked whether companies ever go through the whole process and still do not get certified. They do, and the failures cluster around the same patterns.

Scoping too broadly is the most common. Companies include every system, tool, and office location in scope, then struggle to demonstrate consistent control implementation across all of it. Start with the core scope and expand later.

Treating documentation as the product is the second. An ISMS with polished policies and poor control implementation will fail Stage 2. Auditors do not read policies and take them at face value. They probe whether controls actually operate. Writing a policy and enforcing it are two different things.

Underestimating the people dimension is the third. Access reviews, security training completion rates, and incident response exercises all generate evidence that auditors expect to see. These require ownership from HR and department heads, not just the IT team. If security lives only in engineering, the ISMS will show its seams.

Where Marcus Landed

We did not get him certified in time for that contract. The deal went to a competitor who already had the certificate. Marcus knew going in that was the likely outcome, and he made the decision to start the program anyway, because the European market was not going anywhere and the next buyer who asked would get a different answer.

We have written up the full story of our own certification process: ISO 27001 in 6 Months: How We Achieved Enterprise-Grade Security Compliance. It covers the sequencing, the decisions, and what made that timeline achievable.

ISO/IEC 27001:2022 is the current standard. The 2013 version is no longer valid. If you are evaluating ISO 27001 for the first time, you are starting on the right version. If you hold a 2013 certificate and have not yet transitioned, that certificate expired in October 2025.

If you want to talk through where your company stands and what a realistic path looks like, reach out to us. The earlier we have that conversation, the more options you have.

---

About The Author

Evan Jones
Founder and CEO of Jones IT

With over two decades of IT experience in San Francisco, Evan guides Jones IT's long-term strategy, finances, and culture, with a vision of building the city's highest-rated IT services firm. Outside of work, you'll find him on the golf course or running Bay Area Warriors, his non-profit connecting Bay Area kids to college through basketball.