ISO 27001 is widely misunderstood as a checklist of security controls. Organisations start by buying tools, implementing the technical measures in Annex A, and only later discover that the auditor is far more interested in something else entirely: whether they can demonstrate a functioning management system.

Understanding that distinction early is the difference between a certification project that improves your security and one that produces an expensive folder.

What the standard is actually about

ISO 27001 certifies an Information Security Management System — a process for deciding what needs protecting, choosing controls deliberately, and reviewing whether they work.

The controls in Annex A are a reference list to select from, with justification. The auditable substance is the management system around them: how you assess risk, how you decide, who is accountable, and what evidence exists that the process ran.

This is why two organisations with near-identical technical setups can have completely different outcomes. One decided deliberately and recorded why; the other bought the same tools with no documented reasoning.

Where the effort actually goes

Scope

The first real decision, and the one most often rushed. Which parts of the organisation, which systems, which locations and which services fall inside the ISMS?

Scope too broadly and you carry enormous evidential burden. Scope too narrowly and your certificate does not cover what customers care about — a genuinely wasted exercise. The right scope is usually the systems and teams that handle the information your customers are asking about.

Write the boundary down precisely, including what is excluded and why. Auditors probe scope boundaries hard, because that is where organisations hide inconvenient systems.

Risk assessment

This carries more weight than anything else, and it is where template-driven projects fail most visibly.

You need a repeatable method: how risks are identified, how likelihood and impact are rated, what your acceptance criteria are, and who owns each decision. Then you apply it and record the results.

A generic risk register downloaded and lightly edited is obvious to an experienced auditor within minutes, because it will not reflect anything specific about how your business runs. A real assessment contains risks that could only belong to you.

Statement of Applicability

For every Annex A control: whether it applies, whether it is implemented, and the justification. Exclusions are permitted — they simply have to be reasoned.

This document is the auditor’s map. It is also the artefact that most clearly shows whether you engaged with the standard or copied someone else’s answers.

Evidence that the system runs

This is the part organisations consistently underestimate. The auditor wants proof the management system operated over time:

• Management review meetings, with minutes and decisions
• Internal audits, with findings and what happened to them
• Corrective actions raised, tracked and closed
• Access reviews actually performed on the stated schedule
• Incidents recorded and handled per your own procedure
• Training delivered, with records
• Supplier assessments carried out before onboarding

Note the shape of that list: it is all process running over months. You cannot generate it in the fortnight before an audit, which is precisely why certification timelines are measured in months rather than weeks.

The failure mode to avoid

The most common way certification goes wrong is building a system for the auditor rather than for the organisation.

The symptoms are recognisable: policies nobody has read, written in language nobody uses; procedures describing a process that is not how work actually happens; a risk register updated annually the week before the audit; access reviews performed as a paperwork exercise without anyone genuinely deciding who should still have access.

This passes audits. It also provides close to zero security benefit, and it decays — because nobody follows a process that exists only to be inspected.

The test worth applying to every document you write: would we do this if there were no audit? If not, either the process is wrong or the document is describing something you do not actually do.

How long, and what it costs

For an organisation starting from a reasonable baseline — some security practices already in place, but nothing formalised — expect several months rather than weeks. The binding constraint is not writing documents; it is accumulating the evidence that the system has been operating.

Costs fall into three buckets, and buyers frequently budget only for the third:

1. Internal effort, usually the largest single cost. Someone must own this, and it is a real time commitment, not a side project.
2. Consultancy, if you use it, to build the ISMS and prepare for audit.
3. The certification body, which must be independent of whoever helped you prepare. Certification is a two-stage audit followed by annual surveillance and recertification every three years.

That last point matters commercially: certification is not one-off spend. Budget for surveillance audits and for the ongoing internal effort of keeping the system alive.

Should you certify at all?

An honest question worth asking before committing.

Certify if customers or tenders require it, you sell into regulated sectors, or you need a recognised way to demonstrate security maturity. In those cases the certificate has direct commercial value.

Consider alternatives if the goal is genuinely to be more secure rather than to prove it. The same budget spent on penetration testing, fixing what it finds, and improving access control and monitoring will usually produce a larger security improvement than certification will.

The strongest position is treating the standard as a framework worth following, and certifying when there is a commercial reason to. Organisations that certify because a customer demanded it, without engaging with the substance, get the certificate and very little else.

ISO 27001, SOC 2 or Cyber Essentials?

Buyers routinely ask which of these they need, usually because a customer named one in a questionnaire. They are not interchangeable, and picking the wrong one wastes months.

ISO 27001 certifies that you run a management system for information security. It is internationally recognised, sector-neutral, and the usual expectation in European, Middle Eastern and Asian enterprise procurement. It says your process for managing security is sound.

SOC 2 is an attestation report produced by an accredited auditor, describing whether your controls were suitably designed and — in a Type II report — operated effectively over a period. It is dominant in North American procurement, particularly for SaaS vendors. It says an auditor examined your controls and reported on them, and the output is a detailed report your customer reads rather than a certificate.

Cyber Essentials is a UK scheme covering five fundamental technical controls. It is far cheaper and faster than either of the above, and it is deliberately basic. It says you have the essentials in place — valuable as a baseline or for UK public-sector work, but it will not satisfy a customer asking for ISO 27001.

The practical guidance: let the buyer decide. Ask which your customers and target tenders actually name, and pursue that one. Organisations that pick based on internal preference frequently end up certifying against a standard nobody asked for, then doing it again.

If you sell in both North America and Europe you may eventually need both. They overlap substantially in underlying controls, so the second is meaningfully cheaper than the first — the evidence routine you build for one carries most of the way to the other.

Questions auditors reliably ask

Worth rehearsing honestly before your first audit, because each one probes whether the system is real:

• Show me the risk assessment, and walk me through how you rated this specific risk.
• Who approved this policy, and when was it last reviewed?
• Show me the last access review. Who was removed as a result?
• You raised a corrective action in March. What happened to it?
• This supplier holds customer data. Show me the assessment you did before onboarding them.
• Your procedure says incidents are logged within 24 hours. Show me the last incident.

Notice that every question asks for evidence of something happening, not for a document describing what should happen. That is the whole distinction between a working ISMS and a decorative one.

Working with us

Our information security engagements build an ISMS sized to your organisation — scope, risk method, Statement of Applicability, policies written for the people who must follow them, and an evidence routine that runs without heroics. Where the assessment surfaces technical gaps, our cyber security team can test and close them.

Get in touch to talk through whether certification is the right goal for you.