ISO 27001 certification,
explained plainly

ISO/IEC 27001 is the international standard for information security management. It does not certify a product, a server, or a single feature — it certifies that your organization runs a working information security management system (ISMS): a defined way of identifying risks to your information, deciding what to do about them, and proving you actually do it, over and over.

That distinction matters more than it sounds. A certificate on the wall is not the point of ISO 27001; the management system behind it is. An auditor is not asking "is your software secure?" — they are asking "can you show me the system you use to keep it secure, and the evidence that the system runs?" Everything else in the standard follows from that.

The current version is the 2022 revision (ISO/IEC 27001:2022). If you read older guides referring to 114 controls, those describe the 2013 edition — the 2022 revision reorganized the control set into 93 controls across four themes, which we cover below.

ISO 27001 is rarely pursued for its own sake. Most teams go for it because a customer, a tender or a partner asked — it has become the default way to prove information security to someone who cannot audit you themselves. For software vendors, scaleups and managed-service providers selling to larger or regulated organizations, it is increasingly the price of entry to the deal.

It is also chosen because it travels. A single ISO 27001 certificate is recognized internationally and is widely accepted in place of answering endless bespoke security questionnaires, which is why teams selling across borders tend to reach for it before more region-specific frameworks.

If you are weighing whether you need it, the practical test is simple: are you losing or slowing deals because you cannot demonstrate a managed approach to security? If so, ISO 27001 is usually the most widely accepted answer — and the work of getting there is mostly the work of running security well, written down.

Scope is the first real decision in an ISO 27001 project, and the one that quietly determines how hard the next twelve months will be. Your scope statement defines which parts of your organization the ISMS covers: which teams, systems, locations and information. Scope it too broadly and you have signed up to secure and evidence everything at once. Scope it too narrowly and the certificate will not mean much to the customer asking for it.

Most teams scope the ISMS around the product or service their customers actually care about, plus the systems and people that support it. Write the scope statement plainly enough that an auditor, and a prospect reading your certificate, can tell exactly what it covers.

Annex A is the catalogue of security controls referenced by ISO 27001. The 2022 revision lists 93 controls, grouped into four themes: organizational (37 controls), people (8 controls), physical (14 controls) and technological (34 controls). The technological theme, covering access control, cryptography, logging and secure development, is the one closest to the systems engineers work in every day.

You are not required to implement all 93. You are required to consider each one, decide whether it applies to your scope, implement the ones that do, and justify any you exclude — which is exactly what the Statement of Applicability records.

The Statement of Applicability is the document that maps every Annex A control to a clear decision: applicable and implemented, or excluded, with a reason. It is, in practice, the first document an auditor opens, because it tells them the entire shape of your ISMS at a glance — what you decided to do, and the reasoning behind what you left out.

A good SoA is not a formality you generate at the end. It is the running record of your security decisions, and keeping it current is most of what "maintaining" an ISMS actually involves.

Beyond the controls themselves, ISO 27001 expects a defined set of documented information — the records an auditor asks to see. The Statement of Applicability is the best known, but it sits alongside several others that together describe and govern your ISMS.

The core set most teams maintain includes the ISMS scope, the information security policy, the risk assessment and risk treatment methodology, the risk treatment plan, the Statement of Applicability, and the records that prove the system runs: internal audit results, management review minutes and corrective actions. The standard cares less about their format than about whether they are current, consistent and actually used.

In practice this is where ISMS maintenance lives or dies. Documents drift out of date between audits, the policy says one thing and the evidence shows another, and the gap surfaces at the worst possible moment. Keeping them in one place, versioned and linked to the controls they support, is most of what staying certified involves.

Certification is carried out by an accredited certification body, in two stages. Stage 1 is a documentation review: the auditor checks that your ISMS exists on paper — scope, policies, risk assessment, Statement of Applicability, and is ready to be audited. It usually surfaces gaps you fix before going further.

Stage 2 is the main event. The auditor tests whether the system actually operates as documented, sampling evidence across the controls in your scope and interviewing the people who run them. Before Stage 2, the standard expects you to have run at least one internal audit and one management review yourself — you are not certified against a system you have never checked.

From a serious start, most small and mid-size teams reach the Stage 2 audit in three to twelve months, driven mostly by how much security practice already exists and how much of it is written down. The audit is a checkpoint on a system you keep running, not a one-off project that ends when the certificate arrives.

ISO 27001 certification runs on a three-year cycle. After your initial certification audit, you do not simply hold the certificate untouched — a surveillance audit in years one and two checks that the ISMS is still operating, and a full recertification audit in year three renews the certificate for another cycle.

This is the part teams underestimate. Certification is not an event you survive once; it is a system you keep running. The work that earns the first certificate, keeping the risk assessment current, the Statement of Applicability accurate, the evidence flowing, is the same work that carries you cleanly through every surveillance audit after it. Teams that treat the first audit as a one-off sprint feel the cost again at every renewal; teams that build the ISMS into how they already work do not.

There is no single price for ISO 27001, because most of the cost is your own effort, not a line item. The certification body charges for the Stage 1 and Stage 2 audits and the annual surveillance audits, scaled to the size and complexity of your scope. That fee is usually the smaller part.

The larger cost is the work of building and running the ISMS: defining scope, assessing risk, writing policies, implementing controls, gathering evidence and keeping all of it current through every audit. Teams that assemble this from spreadsheets and shared drives pay for it again at every surveillance cycle, in the time it takes to reconstruct evidence that was never kept in one place.

Narrowing scope to what your customers actually care about, and maintaining the system continuously rather than rebuilding it before each audit, are the two levers that move total cost the most — far more than the certification body’s fee.