The first ISO 27001 programme I watched an SME attempt began with a consultant’s Statement of Applicability template and a promise that the risk register would “fill itself in later.” Six weeks later the spreadsheet had ninety-three rows of hopeful applicability and almost no risks that named the firm’s actual work: customer CAD on a shared portal, an ageing ERP, shop-floor PCs that still shared a login. That is the naive reading of “holistic, risk-based security”: treat Annex A as the work, and invent evidence to match.

Practice pushes the other way. Efficient ISO 27001 for a small organisation is a thin, repeatable chain — risk assessment, risk treatment, then the Statement of Applicability — sized to real assets and headcount. Annex A is the completeness check at the end of that chain, not the shopping list at the start.

What “holistic” and “risk-based” actually require

ISO/IEC 27001:2022 is explicit that an information security management system should be scaled to the organisation’s needs, size, and structure, and integrated with processes that already exist. Holistic, in that sense, does not mean a second bureaucracy that only security people attend. It means security decisions show up in the same management rhythm that already covers quality, delivery, and suppliers.

Risk-based is equally concrete. Clause 6.1.2 wants written acceptance criteria, a method you can run twice and get comparable results, and risks that name CIA impact on information inside scope — with owners, consequence, realistic likelihood, and a priority order for treatment.

Clause 6.1.3 is the next link: choose treatment options, determine the necessary controls, compare those controls with Annex A so nothing necessary was missed, produce a Statement of Applicability, then get risk owners to approve the treatment plan and residual risk.

Official SME guidance says the same thing in plainer language: pick a method that fits the business, build on the management system you already have, and do not turn the ISMS into paperwork for its own sake. The ISO SME handbook frames the same constraint for limited-resource firms. Comparability is using the same scoring twice. It is not a purchase order for enterprise GRC software.

For a forty-person firm, that often means the managing director is also the residual-risk accepter, and the operations lead owns half the treatments. The documentation still has to exist. The cast list does not have to look like a corporate security department.

Annex A is a completeness check, not a mandate

Here is the pivot most SME programmes miss.

The controls you need are the ones that treat your assessed risks (and any hard legal or contractual obligations). Those are the necessary controls. Annex A is a reference set you compare against afterwards, so you did not overlook a control type that really is necessary.

Presence of a row in Annex A does not make that row necessary. You do not become more ISO-compliant by implementing a control you do not need. You become more expensive.

The Statement of Applicability — the document that lists necessary controls, why they are included, whether they are implemented, and why any Annex A control is excluded — is where that decision trail lives. It is not a conformance colouring book. Auditing practice notes go further: necessary controls need not reuse Annex A names or wording, custom controls are allowed, and copying Annex A text into the SoA then failing to do exactly what that text says is a reliable way to earn a nonconformity.

Take a mid-market tooling supplier on a shared industrial estate. Customer drawings arrive through a portal; CNC programmes sit behind the ERP; the landlord owns the building shell. Several physical-perimeter Annex A rows may be unnecessary for this organisation if the risk sits with the landlord and the ISMS scope says so — provided the justification is factual. Drawing-portal access, supplier CAD exchange, and ERP ransomware exposure will almost certainly be necessary. Write those as controls that describe what the firm actually does (MFA on the portal, named accounts on the shop floor, offline backups tested quarterly). Map them to Annex A afterwards. Do not paste the Annex A sentence and hope operations will stretch to match it.

Build forward: risk, treatment, then SoA

A lean method that stays comparable

Requirement, in stakeholder language: “We need ISO 27001 without hiring a full-time GRC team, and the certificate has to cover the services we sell to OEMs.”

Sketch: one scoped ISMS boundary (customer portal + ERP + engineering laptops + shop-floor PCs that touch drawings); a one-page risk method (likelihood 1–5, consequence 1–5 against defined harm levels, acceptance threshold stated); a register of a handful of risks with owners; a treatment plan that points at controls; a SoA whose inclusion and exclusion lines cite risk IDs or contractual drivers.

That sketch is the thin chain. ISO/IEC 27005 can deepen the method later if you want more guidance; it is optional reading for a first lean register, not a second certification.

Worked example: tooling supplier register

Proof of concept — small enough to falsify in a fortnight:

  1. Write acceptance criteria on one page. Example: any risk scoring 12 or above must be treated or formally accepted by the managing director; scores below that are monitored. Prove: two people can apply the same scores to the same scenario and land within one point.
  2. List five to eight risks that name real failure modes. Stolen laptop with customer CAD; shared shop-floor account; supplier CAD mailbox compromise; ransomware on ERP; untested restore of drawing backups; landlord power loss if utilities are in scope. Prove: each row names an information asset inside scope and an owner who can accept residual risk.
  3. Choose treatment per risk. Mitigate, transfer, avoid, or accept — with a date and an owner. Prove: no “monitor” row without a named reviewer and a next review date. (If every row says “monitor,” you have not chosen yet.)
  4. Derive necessary controls from the treatments. Portal MFA and logging; unique shop accounts; supplier transfer procedure; backup restore test record. Prove: every high residual risk points at a control that would change likelihood or impact.
  5. Compare to Annex A and draft the SoA. Include necessary controls with risk-ID justifications; exclude Annex A rows that truly do not apply (for example landlord-controlled perimeter) with a one-line factual reason; note implementation status honestly. Prove: an outsider can walk from SoA row → risk ID → treatment without inventing a story.

Run the weakness check on that design while it is still cheap. Ordinary failure: the late file still arrives by personal email because the supplier procedure is paper only. Drift: the OEM expands scope to “all company IT” the week before Stage 1, and your narrow boundary no longer matches the certificate’s sales job. Opportunist path: the shared shop login remains “just for the night shift” after unique accounts are declared implemented. Fix those in the register and SoA before you buy more template packs.

Where SME programmes burn time

SoA-first templates are the classic waste. They force you to invent risks backwards to justify green cells. Policy cloning from a 5,000-person firm produces the same failure in a different costume: documents nobody can operate, then an internal audit that finds the gap you built in.

Asset-inventory maximalism burns the calendar another way — weeks spent tagging monitors while the drawing portal still has a shared password.

Scope needs a harder conversation. Narrow scope reduces control load. It must still cover the services the certificate will be used to sell. If OEMs buy “the company,” a portal-only scope will not carry the commercial weight you want from the audit days.

Exclusions need the same honesty. “We cannot afford it” is a weak exclusion when residual risk sits above your acceptance line; treat the risk or accept it formally with a named owner. Silent acceptance — “we’ll live with it” with no signature — is not efficiency. It is a finding waiting for Stage 2.

The same honesty applies to implementation status on the SoA. Marking a control “implemented” while the shared shop login still exists does not accelerate certification. It relocates the nonconformity from documentation review to the floor walk.

When ISO is not the efficient first move

If no customer or regulator has asked for ISO 27001, forcing a certification programme can be the wrong spend. Adaptive self-help guidance exists precisely because a full ISMS certification programme can be a poor fit for tiny organisations with minimal headcount. Start with the controls and habits that reduce real loss; open the Clause 6 chain when the commercial need arrives.

UK buyers make the picture messier. Cyber Essentials and ISO/IEC 27001 are not automatic substitutes. The five Cyber Essentials controls may appear among Annex A selections, but only if your risk assessment and scope actually covered that commodity-internet attack outcome. Cyber Essentials Plus physical testing is not part of a standard ISO 27001 assessment. If the tender named Cyber Essentials, an ISO certificate does not answer that question by itself. You may need both.

What remains on the desk

The mature programme looks boring on purpose: a short method, a short register, treatments with owners, a SoA that cites risks, and Annex A used as the aide-memoire it was meant to be. Parallel security committees that never touch operations are usually the inefficiency — not the risk method itself.

Which risk on your current register would still make sense if the SoA spreadsheet disappeared tomorrow — and which SoA row exists only because a template painted it green? If you have already cut a programme down to a thin chain that survived audit, I would value hearing which exclusions held and which ones you had to reverse.