ISO 27001 at thirty people

ISO 27001 usually arrives the same way: a customer sends through a procurement questionnaire, or a contract renewal now lists certification as a condition. Suddenly a standard written with large organisations in mind is your problem, and there is no security team to hand it to.

The good news is that the standard scales down better than its reputation suggests. The bad news is that most of the effort goes somewhere people do not expect.

What it actually asks for

ISO 27001 is a management system standard. It is not a checklist of security controls, which is the most common misunderstanding, and the one that causes the most wasted work.

What it requires is that you can demonstrate a system: you identified your information risks, you decided what to do about each one, you implemented those decisions, and you check periodically whether it is still working. Annex A provides a catalogue of controls to consider, but you are not required to implement all of them. You are required to have considered them and to have justified your decisions.

That distinction matters enormously for a smaller business. “We do not do this, because our risk assessment concluded it is not proportionate to our size and the nature of our data” is a valid, auditable answer. Buying a tool you do not need in order to tick a box is not a better one, and it costs money every year thereafter.

Where the work actually is

Not in tooling. For a company of this size, the effort concentrates in three places:

Writing things down that already happen. You almost certainly already onboard staff, control who has admin access, and back things up. What you probably do not have is a document saying so, evidence it happened consistently, and a named owner. Much of a first certification is converting existing practice into evidence.

The decisions nobody has made. How long do you keep customer data? Who approves an exception to a policy? What counts as an incident, and who decides? These questions have no answers at many small companies, and the standard forces them into the open. This is genuinely useful work, and it is also the part that generates the most meetings.

Evidence discipline. An auditor does not accept “we review access quarterly”. They ask to see the last four reviews, with dates and names. Building the habit of leaving a trail is harder than any individual control, because it changes how people work rather than what software you run.

The timeline nobody wants to hear

Certification is not a project you complete in a quarter while doing everything else. A realistic sequence for a company of this size:

1. Gap assessment — where you actually stand against the controls, and what is missing.
2. Remediation — closing the gaps, sequenced so it fits around delivery work rather than replacing it.
3. Operating period — you need evidence that the system has been running, not just that it exists. This is the part most plans omit, and it cannot be compressed by spending more.
4. Stage 1 audit — the auditor reviews your documentation.
5. Stage 2 audit — the auditor tests whether you actually do what the documentation says.

The operating period is the constraint. You cannot show four quarterly access reviews in a month, no matter how much you spend. If a customer deadline is driving this, that is the fact to plan around, and it is worth telling the customer early rather than discovering it at Stage 2.

Things that are usually a waste of money

• Buying a compliance platform first. These are genuinely useful once you know what you are doing. Bought at the start, they mostly produce a large quantity of policy documents that do not describe your business and that your team cannot answer questions about.
• Templated policy packs. An auditor will ask your staff about the policy. If it was written for someone else’s company, that conversation goes badly, and it goes badly in front of the auditor.
• Scoping too broadly. The scope is your choice. A narrower scope that genuinely covers the systems handling customer data is easier to certify and easier to defend than an enthusiastic “everything”.

If you are starting from nothing

The first useful step costs nothing: write down what data you hold, where it lives, and who can reach it. Not in a formal register — a spreadsheet is fine.

Most of the risk assessment falls out of that document, and it usually surfaces two or three things worth fixing regardless of whether you ever pursue certification. If you go no further, you have still improved your position. If you do proceed, you have built the foundation the rest of the work sits on.

That is a reasonable place to stop and decide whether the certification is worth it — which, if the customer contract is large enough, it usually is.