ISO 27001 explained: what it certifies, who needs it, and what it really costs

What ISO 27001 is, and what the certificate actually says

ISO/IEC 27001 is the international standard for an information security management system, usually shortened to an ISMS. The current edition is ISO/IEC 27001:2022, published on 25 October 2022, with a small amendment in 2024 that I come to below.¹² It is published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), which is why the full name carries both initials.

The idea at its heart is simple to state and harder to live. ISO 27001 does not hand you a list of security gadgets to install. It asks you to run security as a managed system: to understand your risks, decide what to do about each of them, write that down, assign who owns it, measure whether it works, and improve it over time. The certificate, when a business earns one, says that an independent third party examined that system and found it meets the standard. It does not say the business can never be breached. It says the business manages information security deliberately, on the record, and under review.

That distinction runs through everything here. A certificate is a statement about an organisation, issued by someone independent. It is not something a developer can hand you, and it is not a technology you buy. I build the controls and prepare the management system so that an audit can succeed. The certificate itself comes from somewhere else entirely, and that is the first thing to understand clearly.

Who issues the certificate, and why it can never be me

Here is the point most marketing gets wrong. ISO writes the standard. ISO does not certify anyone against it. In ISO's own words, it "does not perform certifications or accredit certification bodies" and "develops international standards but does not directly manage certification processes".³ So nobody can be "certified by ISO", and any supplier who says they are is already playing loose with the facts.

A certificate comes from an accredited certification body: an independent company that audits your management system and, if it passes, issues the certificate. That body is itself checked, by a national accreditation body, to confirm it is competent and impartial. In the United Kingdom the national accreditation body is the United Kingdom Accreditation Service (UKAS), appointed to that role in law by the Accreditation Regulations 2009.⁴ Across the European Union the same single body per country model is set by Regulation (EC) No 765/2008: Germany's body is the Deutsche Akkreditierungsstelle (DAkkS), and Austria's is Akkreditierung Austria, run within the federal economics ministry.⁵

So the chain is: ISO writes the standard, an accreditation body approves certification bodies, a certification body audits you and issues the certificate, and your company holds it. I sit outside that chain on purpose. I am the builder and the preparer. I design and write the software so the controls exist, operate and leave evidence, and I help assemble the management system the standard asks for. I cannot issue the certificate, and I would never claim to. The whole value of the certificate is that the person who signs it is independent of the person who built the system. Keeping those two apart is not a limitation of what I offer. It is the reason the certificate means anything at all.

Security run as a system: the clauses, not just the controls

People who have heard of ISO 27001 usually think of its long list of security controls. Those matter, and I cover them below, but they are the back half of the standard. The front half, clauses 4 to 10, is the part that makes it a management system rather than a checklist, and it is the part auditors fail businesses on most often.

The seven clauses, in plain terms:

Clause 4, context. Work out what your organisation does, who has a stake in its security (customers, regulators, staff), and draw the boundary of what the ISMS covers.
Clause 5, leadership. Management must own the system, set a security policy, and assign clear responsibilities. This is not a box the IT team ticks alone.
Clause 6, planning. Assess your risks, decide how to treat each one, and set measurable security objectives.
Clause 7, support. Provide the people, skills, awareness, communication and documented information the system needs.
Clause 8, operation. Actually run the risk treatment you planned, and keep records that you did.
Clause 9, performance evaluation. Measure how the system is doing, run internal audits, and hold a management review.
Clause 10, improvement. When something goes wrong or falls short, correct it and stop it recurring.

The 2024 amendment made one small but telling addition to clause 4: an organisation must now consider whether climate change is a relevant issue for its security, and whether interested parties have climate related requirements.² It is a minor procedural change, but it shows the direction of travel: the standard treats security as something embedded in the wider risks a business faces, not a sealed technical corner.

The reason this front half matters to you is cost and honesty. A business can own every firewall going and still fail the audit because nobody reviews the risks, management has never signed anything, and no internal audit has ever run. The management system is the work, and it is ongoing work, not a one off project.

The risk assessment and the Statement of Applicability

Two documents sit at the centre of an ISO 27001 system, and they are worth understanding before anyone talks to you about controls.

The first is the risk assessment. You identify what could go wrong for the information you hold (a breach of customer data, a ransomware outage, a rogue administrator, a failed supplier), judge how likely and how damaging each is, and decide what to do: reduce the risk, accept it, avoid the activity, or share it through insurance or a contract. This is where the standard earns its keep, because it forces the question "what are we actually protecting, and against what" before anyone spends money.

The second is the Statement of Applicability, usually called the SoA. The standard comes with a catalogue of reference controls in its Annex A, and the SoA is where you record, control by control, whether you apply it, and if not, why not. It is the bridge between your risks and the controls you have chosen, and it is one of the first things an auditor reads. A control you leave out is fine, as long as your SoA gives an honest reason the risk assessment supports. A control you claim but cannot evidence is where audits go wrong.

Annex A: 93 controls in four themes

Annex A is the catalogue of reference controls, and its detailed guidance lives in a companion standard, ISO/IEC 27002:2022.⁶ The 2022 revision reorganised it. Where the 2013 version listed 114 controls across 14 domains, the current version groups 93 controls into just four themes.¹⁶ Fewer controls does not mean less work: the revision merged overlapping items and added eleven genuinely new ones, covering areas such as threat intelligence, cloud service security, data masking and secure coding.⁶

The four themes, with the count in each and a few examples:

Theme	Controls	What it covers, with examples
Organisational	37	Policies, roles and process: information security policies, supplier relationships, access control rules, incident management, and the handling of threat intelligence.
People	8	The human side: screening before employment, security awareness and training, confidentiality agreements, and what happens to access when someone leaves.
Physical	14	The physical world: secure areas, entry controls, protection of equipment and cabling, clear desk and clear screen, and secure disposal of old kit.
Technological	34	The engineering: authentication and access, cryptography, logging and monitoring, backup, secure development, web filtering and protection against malware.

The themes total 93 exactly. For a software business most of the day to day attention lands on the technological theme, because that is where the build lives, but the audit weighs all four. A perfect technological posture with no leaver process (People) or no supplier reviews (Organisational) still fails.

The cloud and privacy siblings: ISO 27017 and 27018

Two further standards extend ISO 27001 for anyone running in the cloud, which today is almost everyone.

ISO/IEC 27017:2015 is a code of practice for information security controls specific to cloud services.⁷ It takes the relevant Annex A controls and adds cloud specific guidance, and crucially it splits responsibility between the cloud provider and the cloud customer. That shared responsibility split is the single most misunderstood thing about cloud security: which controls are the platform's job and which are yours. ISO 27017 makes you write it down.

ISO/IEC 27018:2015, reviewed in 2019, is a code of practice for protecting personally identifiable information in public clouds acting as processors.⁸ It is the privacy focused sibling, aimed at providers that handle other people's personal data on their behalf, and it sits naturally alongside data protection law.

Neither is a separate certification most buyers demand on its own. They are usually added to an ISO 27001 scope to show a customer that the cloud and privacy dimensions have been handled properly. If your customers are nervous about where their data lives and who can touch it, these are the two that answer the question.

How certification works: Stage 1, Stage 2, and the three year cycle

The way a certification body audits a management system is itself standardised, in ISO/IEC 17021 part 1, so the process is broadly the same whichever body you choose.⁹

A first certification runs in two stages. Stage 1 is the documentation review: the auditor checks that the management system exists on paper, that the scope, policies, risk assessment and SoA are in place, and that you are ready for the real audit. It often surfaces gaps you fix before going further. Stage 2 is the certification audit proper: the auditor tests that the system is actually implemented and working, sampling evidence across your controls, interviewing people, and looking for the records that prove the system runs rather than just exists.

Pass Stage 2 and you receive a certificate valid for three years. That three year span is not a holiday. Each year the certification body runs a surveillance audit, a lighter check that the system is still operating and improving, and at the end of the three years a recertification audit, broader than a surveillance visit, renews the certificate for another cycle.⁹ The cost pattern follows: a larger first year, then smaller annual surveillance costs, then a recertification cost closer to the original every third year.

The message for a business is that ISO 27001 is a standing commitment, not a plaque. You are signing up to keep the system alive and to let an auditor back in every year.

ISO 27001 or SOC 2: the European certificate and the American report

These two get compared constantly, because they answer the same buyer question ("can I trust you with my data") from two different traditions. The honest short version is that geography usually decides.

ISO 27001 is the international, and especially the European, expectation. It is a certification: a certificate, issued by an accredited body, on a defined three year cycle. SOC 2 is the North American expectation. It is not a certificate at all but an attestation report, written by a licensed accountant, describing whether your controls were designed well and, in a Type II report, operated effectively over a period.¹⁰

	ISO/IEC 27001	SOC 2
What it is	A management system certification	An attestation report
What you get	A certificate	A long report for a specific reader
Who issues it	An accredited certification body	A licensed accountant (a CPA firm)
Cycle	Three years, with annual surveillance	Per report, over a chosen window
Where it is expected	Europe and internationally	North America

If your customers are European or global, ISO 27001 is usually the thing they name. If they are American, they usually ask for SOC 2. Some businesses selling on both sides of the Atlantic end up maintaining both, which is more work but less duplication than it sounds, because the underlying engineering and much of the evidence overlap. I set out how the whole family fits together in my overview of the quality tiers for business critical software.

Who needs it, and who is spending money on a certificate nobody asked for

ISO 27001 earns its considerable cost in a specific situation. You sell, or want to sell, to enterprise or public sector buyers, and their procurement process asks for it before they will put your software anywhere near their data. In that world the certificate is often the thing that gets you into the room at all. It also shortens the endless security questionnaires that enterprise buyers send, because much of what they ask is answered by the certificate and its scope. And once NIS2 and similar rules push large organisations to vet their suppliers harder, an ISO 27001 certificate is a clean way for a supplier to answer that scrutiny in one document.¹¹ I wrote about that supplier pressure from the other side, in vendor risk due diligence.

Just as important is knowing when you do not need it. A shop selling its own goods to consumers does not need ISO 27001. A small business with no enterprise buyers and nobody asking for it does not need it either. If no one in your sales pipeline has ever mentioned it, pursuing it is spending a serious sum to answer a question nobody is posing. I would rather tell you that plainly than sell you a certificate you cannot use. The right time to start is when a real buyer, or a real plan to reach that buyer, makes it worth the standing commitment.

It is also worth being clear about what the certificate does not do. It is not a guarantee against breaches. It is not proof that you comply with the law. Data protection law, for example, applies in its own right whatever certificates you hold, including the duty to report certain personal data breaches within 72 hours.¹² A certificate is strong evidence that you take security seriously and manage it deliberately. It is not a shield against every incident and not a substitute for legal duties.

What it costs, and how long it takes

Costs and timelines swing widely with your size, your scope and how mature your controls already are, so treat the figures below as planning ranges rather than quotes. They come from current practitioners in the field, and the sources are footnoted.

There are really two separate bills, and conflating them is where people get surprised. The first is the certification body's audit fee, which you pay to the independent body directly. For a small to medium business this can run up to roughly £25,000 across the audit work, and for a larger organisation fees of £50,000 are not uncommon. For a very small scope the recurring audit figure can be in the low thousands of pounds a year across the three year cycle.¹³¹⁴ The annual surveillance audits cost less than the initial certification, and the recertification every three years costs much the same as the first.¹³

The second bill is the preparation, and it is usually the larger of the two, though it rarely appears in the headline number. This is the readiness work: the risk assessment, the policies, the Statement of Applicability, the actual engineering to close gaps, the internal audit and the management review the standard requires before Stage 2. Some of it is tooling, much of it is time, and a good deal of it is the build itself. This is the honest point to hold on to: building software to the standard adds real cost to the build, before any certificate changes hands. The certificate is the smaller, later expense. The discipline underneath it is where the money and the months go.

On timeline, a focused small business with reasonably mature controls can reach certification in roughly three months, while six to twelve months is a more realistic range for most, and a business starting from very little can take longer still because the certification body needs to see the system actually operating, not just written down.¹³¹⁴ Add a few weeks of lead time to book the audit itself.

A worked example: a Leeds SaaS company chasing an enterprise deal

Dalesync is an invented company in Leeds with 28 staff and a turnover of about £3.5 million. It sells a scheduling platform used in the browser, at dalesync.example, and it has reached the procurement stage of its largest deal yet, with a national healthcare provider whose security team will not proceed without an ISO 27001 certificate. Dalesync has never pursued one.

The founder's first instinct is to ask whether some quicker paperwork will do. It will not: the buyer named the certificate, and nothing short of it clears the procurement gate. So Dalesync commits, and I run a gap analysis against the management system clauses and the Annex A themes.

The picture is the usual one. On the technological theme the fundamentals are decent: encrypted connections, nightly backups, access roles in the application. But multi factor authentication is on the engineers' cloud console and not on the support team's admin panel. Backups run but nobody has restored one in a year. On the organisational and people themes the gaps are wider: there is no risk assessment on paper, no Statement of Applicability, no supplier reviews, no leaver process that reliably removes access, and management has never signed a security policy or sat a review. Critically, no internal audit has ever run, which alone would stop a Stage 2 audit.

The remediation takes about three months. We write the risk assessment and the SoA, bringing management into the decisions so clause 5 is genuinely met. Multi factor authentication goes on every admin path. A restore drill on staging takes 44 minutes, and that number, with the night's backup timing, goes into the continuity plan. Supplier reviews are documented for the payment provider and the email service. A leaver checklist is written and followed. An internal audit runs, finds three more small gaps, and those are closed. Management holds its first review.

Dalesync then commissions a UKAS accredited certification body and pays it directly. Stage 1, the documentation review, flags two minor wording issues in the policy set, which are fixed in a week. Stage 2, a few weeks later, tests the system in operation, samples evidence across the controls, and the auditor recommends certification. About seven months after the first gap analysis, the certificate is issued, inside the range above. Dalesync hands it to the healthcare provider's security team, the procurement block clears, and the next two enterprise questionnaires that arrive are far quicker to answer because the certificate and its scope answer most of the questions already.

What Dalesync bought was not a logo for the website. It was a security management system it now actually runs, independently checked, which happened to be exactly what a specific buyer required. The annual surveillance audit will keep it honest.

What it looks like in a Rails or Solidus build

An ISO 27001 certificate describes controls, but controls are engineering you can show, not paperwork you file. For a Ruby on Rails SaaS platform or a Solidus shop, most of the technological theme is ordinary good practice done properly and made auditable.

Access control and least privilege come first: multi factor authentication on the admin area, the production servers, the deployment pipeline and the cloud console, with role based access so people reach only what their job needs, and a clean process to remove access the day someone leaves. Cryptography means transport security on every connection and encrypted data at rest and in backups, and Rails has Active Record Encryption for sensitive attributes at the application level. Logging and monitoring have to be centralised, with alerts a real person receives, because an auditor asks who saw what and when.

Change management is where several Annex A controls and a clause 8 record meet: every change to production goes through review and leaves a trail. That is exactly the discipline I describe in evidencing compliance with release registers and security testing per release, and it is precisely what an auditor samples. Backup and recovery mean a tested restore with the recovery time and the possible data loss written down, not a backup job nobody has ever read back. Supplier relationships mean a documented review of the services your platform leans on, their security posture and their incident terms.

This is the engineering I build from the start, so that preparing for certification becomes a matter of gathering evidence rather than rebuilding the system. Every platform I deliver also gets a penetration testing pass with the Kali Linux toolkit before it faces the internet, using tools such as Nmap, Burp Suite and OWASP ZAP, with findings documented by severity and fix. That record is exactly the kind of evidence a Stage 2 audit wants to see.

The honest position

ISO 27001 is worth pursuing when a real buyer is asking for it, or when a concrete plan to reach enterprise buyers makes the standing commitment pay, and it is money poorly spent when nobody is asking and nobody will. When it is worth it, the work divides cleanly. I build the compliant system and prepare the management system for you: the risk assessment, the Statement of Applicability, the access model, the change management and release register, the logging, the encryption, the supplier reviews, the tested recovery, all engineered to leave the evidence an auditor samples. Then you commission an independent, accredited certification body to audit it and issue the certificate, and you pay that body directly. I never issue it, never certify anything, and never fold the certification body's fee into mine. That separation is not a weakness in what I offer. It is what makes the certificate, and my word about it, worth trusting.

If you have been asked for ISO 27001 and are not sure whether you really need it, how wide to draw the scope, or whether your current systems could survive a Stage 2 audit, book the free workshop and I will work it out with you, and the first two weeks of the work are on me.

International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection, Information security management systems, Requirements, catalogue page, iso.org, accessed 13 November 2026, https://www.iso.org/standard/27001 ↩ ↩²
International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 27001:2022/Amd 1:2024 Climate action changes, catalogue page, iso.org, accessed 13 November 2026, https://www.iso.org/standard/88435.html ↩ ↩²
International Organization for Standardization, How to verify an accredited certification (ISO does not perform certifications or accredit certification bodies; accredited certification bodies issue certifications), help.iso.org, accessed 13 November 2026, https://help.iso.org/en/articles/424922-how-to-verify-an-accredited-certification ↩
The Accreditation Regulations 2009 (SI 2009/3155), regulation 3, appointing the United Kingdom Accreditation Service as the national accreditation body, legislation.gov.uk, https://www.legislation.gov.uk/uksi/2009/3155/regulation/3 ↩
European Parliament and Council, Regulation (EC) No 765/2008 setting out the requirements for accreditation, Article 4 (each member state appoints a single national accreditation body), EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008R0765 ↩
International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 27002:2022 Information security controls, catalogue page (the companion standard that details the Annex A controls, 93 controls in four themes), iso.org, accessed 13 November 2026, https://www.iso.org/standard/75652.html ↩ ↩² ↩³
International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 27017:2015 Code of practice for information security controls based on ISO/IEC 27002 for cloud services, catalogue page, iso.org, accessed 13 November 2026, https://www.iso.org/standard/43757.html ↩
International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 27018:2019 Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors, catalogue page, iso.org, accessed 13 November 2026, https://www.iso.org/standard/76559.html ↩
International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 17021-1:2015 Requirements for bodies providing audit and certification of management systems, Part 1, catalogue page (Stage 1 and Stage 2 audits, surveillance and recertification), iso.org, accessed 13 November 2026, https://www.iso.org/standard/61651.html ↩ ↩²
AICPA & CIMA, System and Organization Controls: SOC Suite of Services, aicpa-cima.com, accessed 13 November 2026, https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services ↩
European Parliament and Council, Directive (EU) 2022/2555 (NIS2 Directive), Article 21, cybersecurity risk management measures including supply chain security, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022L2555 ↩
European Parliament and Council, Regulation (EU) 2016/679 (General Data Protection Regulation), Article 33, notification of a personal data breach, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj ↩
DataGuard, How much does it cost to achieve ISO 27001 certification, dataguard.com, accessed 13 November 2026, https://www.dataguard.com/iso-27001/certification/cost/ ↩ ↩² ↩³
Hicomply, ISO 27001 for small businesses: scope, cost and timeline, hicomply.com, accessed 13 November 2026, https://www.hicomply.com/iso-27001/iso-27001-for-small-businesses ↩ ↩²