ISO 27001 Without the Certificate

We implemented ISO 27001 at Spyced Concepts and we are not certified. No audit is booked. Some of the documentation still says "Draft" at the top.

That's not a confession of failure — it was a deliberate choice, and I think it's the right one for most small companies. You just won't hear many people say so, because almost everything written about ISO 27001 is written by people who sell certification.

So there's plenty of advice on how do I get certified? — and almost nothing on the question the owner of a five-person company actually has, which is should I?

A quick word on where this comes from. I've spent years leading software development teams — including a spell covering CTO responsibilities — and I implemented ISO 27001 and ISO 9001 at Spyced Concepts myself: not as a consultant selling a certificate, but as the person who then has to live with them day to day. So this is the view from doing the work, not from selling it.

Two different things wearing the same name

When someone says "we need ISO 27001", they could mean either of two purchases, and they are rarely the same one.

The certificate is an audit. An accredited body examines your management system, agrees it meets the standard, and issues a certificate on a renewal cycle. What that audit actually checks comes down to three plain questions — are you doing what you say you do, have you written it down, and can you prove it? What you're buying is proof to other people: it's really a procurement tool.

The controls are the actual work. The risk register. Knowing what hardware, software and suppliers you have. Deciding who can access what. Writing down what happens when something goes wrong, before it does. What you are buying here is being harder to attack.

They overlap, but they're not the same thing — and it only runs one way round. You can have the controls without the certificate; that's where we are. You can't have the certificate without the controls, because no accredited body will certify a management system that isn't there and written down. The certificate is, in the end, an audit of the practices — which is exactly why doing the practices first is the cheaper route to it.

It's worth being clear about what that certificate actually proves. UKAS — the UK's national accreditation body — describes accreditation as recognition that a certification body is "technically competent to audit and certify activity in accordance with the requirements of national and international standards". So an accredited certificate is a competent third party's word that your management system meets the standard. That's genuinely valuable — but it's plainly a different claim from "nothing will ever go wrong here", and I reckon a lot of the disappointment around ISO 27001 comes from expecting the second when you bought the first.

Put it another way, and there are really three things here, not two. The certificate is a marketing and sales achievement — a badge that helps you win business and clear procurement gates. The audit behind it is a compliance check — a point-in-time confirmation that you're doing what you say you do. But the day-to-day use of the standard is neither of those: it's a business management tool. And that last one is the part you get to keep whether or not you ever certify.

The question is not which is better. It is which one someone is asking you for.

If a client's procurement process has a box requiring the certificate, no amount of good practice fills that box. Get certified. But if nobody is asking — and for most small companies nobody is asking yet — then buying the certificate first is buying the receipt before the thing.

Where you actually sit

There are really three positions a company can be in, and it helps to be honest about which is yours:

• Certified — you've been audited by an accredited body and hold the certificate. A third party has checked your work and vouched for it.
• Applying the standard, uncertified — you're doing the work (the registers, the risk assessment, the reviews) but haven't paid for the audit. This is where we sit.
• Not applying it at all — and there's no shame in that if nobody's asking, as long as you know that's where you are.

The catch is that middle position, because it's the one you can fake. "ISO 27001 aligned" is a phrase anyone can drop on a website; the difference is whether there's a real management system underneath it or just the phrase. So the gap that actually matters isn't between certified and uncertified — it's between doing the work and only saying you do. We'd rather be the uncertified company that's genuinely doing it than the "aligned" one that isn't.

What we built instead

We built the second thing, and we did it as though an auditor might turn up, because documentation written to be read by someone else is better documentation.

That's currently sixty-three controlled documents: a risk register, registers for hardware, software, services and suppliers, a Statement of Applicability, gap analyses, an incident log, and a management review cycle.

The most useful thing in there isn't a policy. It's the review schedule — and specifically, the fact that it's generated rather than maintained.

Every controlled document carries its own review date. A script reads them all and produces the schedule. Nobody keeps a list.

That sounds like a technicality. It's the whole thing. A hand-kept register only ever contains what somebody remembered to add, and the failure is completely silent — the register looks healthy, because the items missing from it are missing from it. We found this the direct way: three SaaS products in daily business use, none of them on the register. Not through carelessness, but because adding them was a manual step at the end of a busy afternoon.

A generated schedule cannot have that failure. A new controlled document appears in it automatically. A deleted one disappears. And overdue reviews surface on their own, which matters more than it sounds, because paperwork nobody re-reads is theatre with a version number.

What keeps it sustainable

Two habits, more than any single policy, are why a company this size can keep it going.

Review dates spread across the year. Every controlled document has its own review date, and they're deliberately staggered — a handful falling due each month rather than all landing at once. There's no week-before-the-audit scramble to re-read everything, because the re-reading never piles up in the first place. Compliance stops being a dreaded annual event and becomes a light, steady rhythm.

AI to carry the admin. The honest reason a small team can maintain a library this size is that we use AI to take the repetitive weight — drafting and cross-referencing documents, generating the review schedule, surfacing what has fallen overdue. The judgement stays human: what the risks are, which controls apply, what to accept and why. The typing, the cross-referencing and the chasing do not. For a small company that's the difference between a living system and a folder nobody opens.

Between them, these turn compliance from an event into a habit — and that's the quiet payoff. Once the discipline is in place — inventory what you have, assess the risk, decide what applies, write it down, review it on a cycle — it stops being a security-only exercise. It becomes a structured way of thinking about the whole business: its products, its services, its suppliers. That's what the standard really gives a small company: not a certificate, but a repeatable framework for building things properly. The certificate proves it to outsiders; the habit is what actually improves how you run.

What it actually cost

Not money. Time — which for a small company is the scarcer of the two.

The expensive part was the asset registers, and that surprised me. You can't inventory what you've never written down, and the first pass is genuinely archaeological: every machine, every SaaS subscription, every supplier with access to something. It took far longer than any policy.

It was also the most valuable part, and for a reason worth stating plainly. Every other control depends on it. You can't assess risk to assets you haven't listed. You can't control access to systems you've forgotten. The registers aren't a compliance artefact; they're the map everything else is drawn on.

The cheap parts were document control, review dates, and the incident log. Hours, not weeks, and they're the things that have paid back most.

What we skipped

This is the part the certification industry won't write, so here it is.

We skipped policies written for organisations with departments we don't have — a joiners-movers-leavers process is a bit pointless with no joiners. We skipped controls that assume employees we haven't hired. And we deferred formal internal audit for now.

That last one's worth unpacking, because "internal audit" sounds heavier than it is. An internal review is really just two honest questions put to your own system: are we actually doing what our documents say we do, and does it still serve the purpose it was written for? It's genuinely worth doing once things have bedded in — but for a management system that's only a few months old, mostly what you'd be checking is how recently you wrote it.

The generalisation behind all three: ISO 27001 is written for organisations of all sizes and every sector — BSI, the UK national standards body, is explicit that it applies across "public, private, government, or not-for-profit" organisations of all sizes — so for a small company the work is scoping, not volume.

Annex A is a menu, not a shopping list. Its ninety-three controls sit in four themes — organisational, people, physical and technological — and the standard doesn't require you to implement all of them. It requires a Statement of Applicability that records which apply, which don't, and why. "We have no employees" is a perfectly respectable why, provided you've written it down and can defend it.

Compliance-by-volume is how small companies end up with a folder of documents nobody has read since the day they were written, which is worse than having nothing, because it looks like something.

When you do need the certificate

Get certified when someone is actually asking. Enterprise procurement gates, a contractual requirement, a sector where it's table stakes — these are real, and no amount of internal good practice substitutes.

There's also a plainly commercial reason: the certificate is marketable. ISO 27001, ISO 9001 and the like are recognised badges — they tell a buyer, at a glance, that you take security and quality seriously, which is worth having in any competitive pitch. But public-sector work is where it stops being a nice-to-have and becomes a hurdle you simply have to clear. From what I've seen in this space, ISO 27001 turns up again and again in government and NHS procurement — and on Crown Commercial Service frameworks such as G-Cloud, particularly for anything touching data at the OFFICIAL classification — as a stated requirement or a scored criterion. It has increasingly shifted from a nice-to-have to what is, in practice, a hard requirement for a great deal of government technology work. If that's the work you're chasing, the certificate isn't optional — and the sooner the controls are genuinely in place, the sooner you can clear the bar.

But note the order. If you've already done the controls work — and, just as importantly, if you're actually following your own policies rather than just filing them — then certification becomes an audit of something that already exists and already works, not a scramble to invent it under time pressure. Remember what the audit is really asking: are you doing what you say you do, is it written down, and can you prove it? A company that has been quietly living its controls can answer all three on the day. The groundwork is never wasted — it's the cheaper, calmer route to the same certificate if and when you decide you need it.

And if you do get certified, none of this stops — that's the part people underestimate. The certificate isn't a finish line; it's a standing commitment, with surveillance audits along the way to check you're keeping it up. The same habits carry you through them: live your policies rather than file them, keep the reviews spread across the year so nothing piles up, and make sure every document still meets its requirement and has its next review booked. Certified or not, the discipline is identical — the certificate just means someone else is now checking too.

The smaller step nobody mentions

If all of this sounds like a lot, there's a deliberately smaller thing between doing nothing and pursuing ISO 27001: Cyber Essentials, which the NCSC describes as "the minimum standard of cyber security recommended by the Government for organisations of all sizes". Five technical controls — firewalls, secure configuration, security update management, user access control, malware protection.

It isn't a substitute for an information security management system, and it doesn't pretend to be. But it's achievable, and it carries real procurement weight: under the Cabinet Office's Procurement Policy Note 014, Cyber Essentials certification is required for certain public-sector contracts — though notably the same note tells buyers not to apply it "to all contracts as a matter of course", only where it is "relevant to the subject matter of the contract, proportionate and necessary". Which is, incidentally, the same scoping discipline this whole post is arguing for, coming from the other direction.

There are two tiers, and the difference matters if you're chasing government work. Basic Cyber Essentials is a verified self-assessment. Cyber Essentials Plus is the same five controls, but independently tested by an assessor — and that audited version tends to be what public-sector and government contracts actually ask for in practice, especially anything touching data at OFFICIAL, where it's commonly expected alongside ISO 27001. If government work is the goal, assume Cyber Essentials Plus, not the basic tier.

And it's the same pattern as everything else here. The certificate — Cyber Essentials, Cyber Essentials Plus, ISO 27001 — is the marketable part, the thing that clears the procurement gate. The controls underneath are the business tool: they're what actually make you harder to attack, whether or not anyone ever audits them.

One practical caveat: it must be renewed every twelve months, or the certificate lapses. For a very small company it still buys more actual security per hour spent than a folder of policies will.

Where to start

Not with policies. With a gap analysis: where you stand against the standard today, before deciding whether the certificate is a purchase you need to make. It turns an open-ended anxiety into a concrete list.

The honest advice stands whoever does it, and doing it yourself with the standard open is entirely possible. If you'd like a hand with it — or with improving your compliance workflow more broadly — get in touch.

Whatever you do, decide which purchase you're making. Most of the waste I've seen comes from companies buying the certificate when what they actually needed was the controls, and finding out afterwards.

References

• BSI — ISO/IEC 27001 Information Security Management — applicability across organisations of all sizes and sectors; two-stage certification audit
• BSI — ISO/IEC 27001:2022 Transition FAQs — Annex A: 93 controls across four themes (organisational, people, physical, technological)
• UKAS — What is UKAS accreditation? and Accreditation vs Certification — what an accredited certificate attests to
• NCSC — Cyber Essentials overview — the five technical controls, and its positioning as the government-recommended minimum standard
• Cabinet Office — Procurement Policy Note 014: Cyber Essentials Scheme — when Cyber Essentials is required for public-sector contracts, the proportionality caveat, and the 12-month recertification requirement
• ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements. The Statement of Applicability requirement sits in the risk treatment clause of the standard itself.

Stu Last is the founder of Spyced Concepts, an IT security, software and compliance consultancy in Falmouth, Cornwall. He spent years leading software development teams — including a spell covering CTO responsibilities — before setting up Spyced Concepts, where he built and runs the ISO 27001 and ISO 9001 management systems described in this post. This is written from doing the work, not from selling the certificate.