Parts one and two gave you a floor: three frameworks nested into one spine, and the five technical controls that make up the Cyber Essentials baseline. So far, though, everything rests on your own word. The self-assessment is a claim you sign.

This part is about turning the claim into something other people can trust — first through the independent test of Cyber Essentials Plus, then through the management system that ISO 27001 asks for, which is what stops all of it quietly decaying the week after the assessor leaves.

What Cyber Essentials Plus actually tests

Cyber Essentials Plus is the same five controls, checked by a qualified assessor on your real machines rather than taken on trust. It is not a harder questionnaire. It is someone sitting with your kit, testing whether the answers you gave were true.

The sequence matters, and Danzell tightened it. Your verified self-assessment has to be finalised before the Plus testing begins, and you may not adjust your answers afterwards to match what the test found. The self-assessment is the claim; the Plus audit checks the claim; you cannot edit the claim once it has been checked. That closes an old loophole.

The testing itself, following the IASME test specification, covers a representative sample of your devices — chosen to include each operating system build you run — and looks at four things in particular:

Danzell added teeth to the retest rule. If the sample fails, you remediate and are retested against a new, random sample — you cannot simply fix the machines that happened to be tested. And a second failure revokes your verified self-assessment certificate altogether. The message is blunt and correct: patch the whole estate, not the tested corner of it.

Passing Plus is an operational test, not a paperwork one

Because Plus is hands-on, you cannot document your way through it. The preparation is different from Cyber Essentials, and it is worth doing deliberately:

Book Plus close behind your Cyber Essentials certification — the scheme expects it within three months — so you are testing the same estate you certified, not one that has drifted.

From a certificate to a system

Here is the limitation that ISO 27001 exists to fix. Cyber Essentials, even with Plus, is a point in time — Danzell now defines that explicitly as the date the certificate is issued. It says your controls were sound on that day. It says nothing about the day after, or the day a new laptop is imaged without the hardened build, or the day someone turns off MFA to troubleshoot a login and forgets to turn it back on.

ISO 27001 is the answer to "and then what?" It is not a bigger pile of controls. It is a management system — a defined, repeating way of running security so that the state you certified is the state you stay in. If Cyber Essentials is passing your MOT, ISO 27001 is servicing the car on a schedule so it keeps passing.

Building the ISMS core, proportionately

The mistake firms make with ISO is treating it as a documentation exercise and hiring someone to produce a binder nobody reads. The standard is deliberately risk-based so you can scale it to your business. For a firm of ten to fifty people, the core is smaller than the consultants imply, but every piece has to be real. Here is what actually matters.

A risk assessment and treatment plan (clauses 6.1.2 and 6.1.3). The beating heart of ISO. List the things that could go wrong for your information — loss, theft, leak, outage — assess how likely and how damaging each is, and decide what you are doing about each: apply a control, accept it consciously, transfer it (insurance), or avoid it. A plain risk register in a spreadsheet is entirely acceptable at your size. What matters is that it is honest and that someone owns each line.

A Statement of Applicability. The defining ISO document: a list of all 93 Annex A controls, marked as applicable or not, implemented or not, with a justification for anything you exclude. This is where your Cyber Essentials work pays a second dividend — the technological controls are already largely in place and evidenced, so a big slice of the SoA is populated before you start.

A small set of policies that are actually enforced. Not thirty documents; a handful that people follow: an overarching information security policy, an acceptable-use policy, access control, supplier security, incident response, and business continuity and backup. Short, plain, and applied beats comprehensive and ignored. The brand rule applies here as everywhere — substance over polish.

Asset and information management (A.5.9 to A.5.13). You already built the inventory for scope in part one. ISO adds classification (what is sensitive) and ownership (who is responsible for each). Extend the inventory you have; do not start a new one.

People (the A.6 controls). Screening on hire, security responsibilities in contracts, a disciplinary route, and — the highest-return control in the whole standard for a small firm — awareness training. The joiners-movers-leavers process you built for user access control lives here too. Most incidents at your size start with a person clicking something; a workforce that has been taught what a modern phishing or deepfake lure looks like is cheap protection that works.

Supplier security (A.5.19 to A.5.22). This one matters disproportionately for SMBs, because you outsource so much — your IT, your cloud platforms, your accounting. ISO wants you to assess your suppliers' security and set expectations in the contract. In practice: know what each supplier holds and can reach, ask them for their own Cyber Essentials or ISO status, and make security an explicit term rather than an assumption. Your outsourced IT provider being certified is not the same as you being certified, and the certificate names you.

Incident management (A.5.24 to A.5.28). A written plan: who does what when something goes wrong, how staff report it, who decides, who to notify (including the ICO within 72 hours where personal data is involved), and how you learn afterwards. A plan you have never tested is a wish; part four is where we test it.

ISO 27001:2022 also added eleven controls in its last revision, several of which map neatly onto decisions you are already making: A.5.23 for the security of the cloud services you just brought fully into scope, A.5.7 for threat intelligence, A.5.30 for ICT readiness for business continuity, A.8.23 for web filtering, and A.8.16 for monitoring. You do not need heavyweight tooling for these at your size; you need a proportionate, documented answer to each.

Right-size it, and mean it

ISO 27001 for a thirty-person professional services firm is not ISO 27001 for a bank, and the standard does not ask it to be. The controls are chosen and scaled according to your risk assessment, which is the point of doing the risk work first. Resist the two failure modes: the under-cooked version that documents nothing and falls over at audit, and the over-cooked version where a consultant sells you a management system three sizes too big that nobody in the business can actually operate.

The test of a good ISMS at your size is simple: could the named owner from part one run it themselves, in the hours they realistically have, and would it survive a member of staff leaving? If yes, it is right-sized. If it needs a full-time person you do not have, it is theatre, and it will lapse.

Where this leaves you

At the end of this part you have proof, not just a claim — Cyber Essentials Plus — and the skeleton of a management system that keeps the controls alive: a risk register, a Statement of Applicability your Cyber Essentials work half-filled, a small set of enforced policies, and named owners for assets, suppliers and incidents.

What you do not yet have is the proof that it runs — that the backups restore, the incident plan works under pressure, and the whole thing improves rather than drifts. That, plus a quarter-by-quarter roadmap for the rest of 2026 and the road to certification, is part four.