Who should read this: founders, CTOs, IT managers and operations leads at companies of 20 to 250 people who have been asked for ISO 27001 by a customer, an insurer or an investor, and who have nobody whose job title contains the word security.
Most explanations of ISO 27001 are written for people who already run a security function. They talk about the ISMS, the risk treatment plan and Annex A as if those words meant something obvious. If you are the CTO who also owns the roadmap, the infrastructure and half of support, that is not useful. So here is what the standard actually asks of a company like yours, in order, with the parts nobody warns you about.
ISO 27001 is a management system, not a security score
This is the single most useful thing to understand before you spend any money.
ISO 27001 does not certify that your company is secure. It certifies that you have a working system for deciding what needs protecting, choosing what to do about it, doing it, checking that it happened, and fixing it when it did not. An auditor is not testing your firewall. They are testing whether the machine that is supposed to look after your firewall exists and runs.
That has two consequences. The good one: a small company can pass, because the standard scales to your size and risk. The uncomfortable one: you can pass while leaving real weaknesses in place, as long as you decided about them deliberately and wrote the decision down. We come back to that at the end, because it is the whole reason this article exists.
The five decisions nobody can make for you
Consultants and platforms can produce documents. They cannot make these calls, and every project that drifts is a project where these were left open.
What is in scope. Which parts of the company, which systems, which locations and which services the certificate covers. This decision drives cost more than anything else. It also decides whether the certificate answers the question your customer is actually asking.
What you are protecting and from whom. Not a generic threat list. What would genuinely hurt this business: your source code leaking, a production outage of four days, a customer data breach, a payment fraud, a key person leaving with the only copy of something.
Who owns security. A named person, with the authority to say no and the time to do the work. The standard requires top management commitment and it is the requirement companies fake most often.
What risk you accept. Every organisation accepts risk. ISO 27001 only asks that you do it explicitly, at the right level of seniority, with a reason.
What you will not do. The unglamorous half. If you are not going to run a formal secure development lifecycle this year, say so and say why, rather than writing a policy that describes a company you are not.
If you want a structured version of these five before committing budget, that is exactly what an independent vCISO Security Audit is for: it produces the decisions, the ranked gaps and the roadmap, and it is useful whether or not you ever certify.
What the standard makes you build
Strip away the jargon and ISO 27001 requires a fairly short list of things to exist and stay alive.
- A defined scope. One or two paragraphs, plus a boundary you can defend.
- A risk method and a risk register. A repeatable way to identify, rate and treat risks, and the record of having done it. Not a spreadsheet written once in March.
- A Statement of Applicability. Every control from Annex A, marked applicable or not, with a justification. This is the document auditors read first, and it deserves its own explanation, which is why we wrote scope and Statement of Applicability without the jargon.
- Policies that people have actually accepted. Written, approved, versioned, and acknowledged by staff. An unread policy is a finding waiting to happen.
- Evidence that controls operate. Access reviews with dates, backup restore tests with results, joiner and leaver records, patch records, supplier reviews.
- Internal audit and management review. You check yourself before the auditor does, and leadership formally looks at the results.
- Corrective action. When something fails, there is a record of what you did about it.
Notice how much of that is record keeping rather than technology. That is the honest shape of the work.
The 93 controls, and why the number frightens people more than it should
The 2022 edition of ISO 27001 lists 93 controls in Annex A, grouped into four themes: organisational, people, physical and technological. The 2013 edition had 114, so the standard got shorter, not longer, mostly by merging overlapping items.
Two things make the number less alarming. First, a meaningful share of them will not apply to you, and saying so in writing is a legitimate answer. Second, many are things you already do informally: you already onboard people, you already have backups, you already restrict who can reach production. The work is usually formalising and evidencing what exists, not building from nothing.
Eleven controls were new in 2022, and they are the ones that catch small companies out because they were never part of the old muscle memory: threat intelligence, information security for cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding. If you are a software company, configuration management, secure coding and monitoring are where you will spend real effort.
What changed recently, and what it means for you now
Three points that matter in practice.
The transition window from the 2013 edition closed on 31 October 2025. Every audit now runs against the 2022 controls, so any template, policy pack or consultant deliverable that references the old numbering is out of date. Check this before you pay for anything.
Amendment 1 to the standard added climate considerations to the clauses about your context and your interested parties. In plain terms, you have to consider whether environmental conditions are relevant to your information security, and record the conclusion either way. For most software companies the honest answer is a short paragraph about the physical resilience of the facilities you depend on. It is a documentation requirement, not a green transformation.
Clause 6.3 requires you to plan changes to the management system rather than letting it drift. This one is genuinely useful. It is the clause that stops your ISMS from being accurate in month one and fiction in month fourteen.
Auditor behaviour has shifted alongside this. The emphasis has moved from whether a policy exists to whether a control demonstrably ran, and the evidence expected is typically several months of operational records rather than a snapshot assembled the week before the audit. Plan for that from the start, because retrofitting six months of evidence is impossible.
The honest timeline
For a 20 to 250 person company with no security team, working steadily rather than heroically:
- Scoping, risk assessment and the Statement of Applicability: four to eight weeks.
- Closing the gaps that matter: two to five months, and this is the part that varies most, because it depends on how much real work the assessment turns up.
- Running the system long enough to have evidence: three months minimum, six is more comfortable.
- Internal audit and management review: two to four weeks.
- Stage 1 and Stage 2 audits: separated by a few weeks, plus time to clear findings.
Nine to twelve months is a realistic first certification for a company starting from a normal, unmanaged position. Anyone promising three months is either selling you a very narrow scope or planning to assemble evidence rather than generate it. On what this costs and where the money actually goes, we have written separately about whether €50k for ISO 27001 is worth it.
Where companies without a security team actually get stuck
Four patterns, in the order we see them.
The scope was drawn to make the audit easy, not to answer the customer. The certificate arrives, the customer reads the scope statement, and asks why their service is not in it. Now you are doing it twice.
Nobody owns it after the kick-off. The project has energy for six weeks, then the CTO gets a product deadline. The single strongest predictor of a project that stalls is that security ownership was never anybody’s actual job.
Evidence was never a habit. Controls were designed but nothing records them running, so the month before the audit becomes an archaeology exercise.
Suppliers were left to the end. Your vendor list is longer than you think, and the standard expects you to have assessed and monitored the ones that matter. The same problem shows up under other regimes, which we covered in supply chain security and vendor risk.
If ISO 27001 is landing on you at the same time as NIS2, do the work once rather than twice. The overlap is large and the mapping is well understood, which we set out in certification standards and ISO 27001 under NIS2, and there is a broader view of what regulation asks of smaller companies in our piece on NIS2 for SMEs. A structured view of the whole ISO 27001 route is on our ISO 27001 solutions page.
The technical reality: what the certificate leaves open
Here is the part most guides skip.
ISO 27001 verifies that your controls were selected deliberately and operate as described. It does not verify that they are sufficient against a competent attacker. Those are different tests, and the gap between them is where breaches at certified companies happen.
Concretely, a company can hold a valid certificate while:
- multi-factor authentication is enabled but not enforced on the legacy path everyone actually uses,
- backups run and are tested by confirming the job succeeded, never by restoring a system end to end under time pressure,
- logs are collected but nobody looks at them, because the control said collect, not detect,
- a dependency with a known critical vulnerability sits in production because the patch window was documented as quarterly and that was the accepted decision,
- an offboarding checklist is signed while the person’s tokens and shared credentials remain valid.
Every one of those passes an audit. Every one of those is exploitable.
Closing them is a different kind of work: enforcing rather than enabling, restoring rather than checking the job status, alerting on the log rather than storing it, and shortening the patch window for the things actually exposed. It is not more paperwork. It is the operational half that the certificate does not ask for and an attacker does not skip.
So the useful way to run an ISO 27001 project in a company with no security team is to treat certification as the deadline that gets budget approved, and the gap list underneath it as the thing you are actually buying. Get the certificate. Then keep going, because the certificate is the floor, not the ceiling.
