Most ISO 27001 guides are written for banks, hospitals, or government bodies with dedicated compliance teams. A startup reading them will either give up or hire a consultant who bills by the page count.
This guide is different. It is written for the founder or CTO of a ten- to thirty-person company who has been told — by a customer, an investor, or a procurement team — that they need ISO 27001, and who wants to know what actually needs to happen in the next 30 days.
At Metaluxo we run gap assessments for startups and SMEs across the EU. The ones that certify fastest do not have the longest policies. They have the clearest evidence.
What does Stage 1 readiness actually mean?
Stage 1 is a documentation review, not an operational audit. The certification body checks that your Information Security Management System (ISMS) is designed correctly before it tests whether it runs correctly at Stage 2.
Stage 1 readiness means you can hand over five documents and answer one question: who reviews this, and when?
The five documents are:
- Information security policy — one page, signed by the CEO, stating what you protect and why.
- Risk assessment — a list of risks, scores, owners, and treatments. Not a spreadsheet from a template site; your actual risks.
- Statement of Applicability — the Annex A control list, with each control marked in or out, and a one-line justification for each decision.
- Risk treatment plan — what you are doing about the risks you are not accepting, with deadlines and owners.
- Internal audit schedule — evidence that someone will check this system before the certification body does.
That is it. Everything else — acceptable use policies, password standards, backup procedures — sits inside these five documents or is referenced by them.
Week 1: Scope and risk assessment
Day 1–2: Define the scope.
The scope is the boundary of your ISMS. It should include every team, system, and location that handles the information you are trying to protect. For a SaaS startup this is usually: the production environment, the office or co-working space, remote workers’ endpoints, and any third-party services that process customer data.
Do not scope too widely. An ISMS that covers “everything” is an ISMS that cannot be audited. Scope tightly, document the boundary, and move on.
Day 3–5: Run the risk assessment.
List your assets (data, systems, people, premises). For each asset, list the threats that matter to you — not every threat in the ISO 27005 catalogue, but the ones that would actually stop you trading. A ten-person startup does not need to model state-sponsored espionage. It needs to model: ransomware on the production database, a developer laptop stolen from a café, a supplier going offline.
Score each risk for likelihood and impact. Use a 3×3 or 5×5 matrix. The goal is not mathematical precision; it is a defensible ranking that lets you say “we fixed the top six first.”
Day 6–7: Write the information security policy.
One page. Signed by the CEO. It says: we protect customer data; we comply with GDPR; we review this policy annually. That is enough.
Week 2: Statement of Applicability and treatment plan
Day 8–10: Build the Statement of Applicability.
ISO 27001:2022 has 93 controls in Annex A, organised into four themes. You do not need all 93. You need the ones that apply to your scope and your risks.
For each control, mark it In or Out. If it is In, note which risk it treats. If it is Out, write one sentence explaining why — “We do not develop software in-house, so A.5.25 (secure development) is not applicable.”
A typical startup Statement of Applicability includes 45–60 controls. The auditor is not counting. The auditor is checking that your In/Out decisions are consistent with your scope and your risks.
Day 11–14: Write the risk treatment plan.
For every risk you are not accepting, write down: what you will do, who will do it, and when it will be done. If a control is already in place — for example, you already use MFA on all admin accounts — note it as “implemented” and attach a screenshot or settings export as evidence.
The treatment plan is a living document. It does not need to be finished before Stage 1. It needs to show that you know what remains and that someone owns it.
Week 3: Evidence and internal audit
Day 15–18: Gather evidence.
An auditor does not trust your word. They trust timestamps. For every control you claim is implemented, keep one piece of evidence:
- MFA enabled? Screenshot of the admin console.
- Backups tested? Log entry from the last test restore.
- Access reviews done? Email thread or calendar invite showing the review happened.
- Staff trained? Attendance list or completion certificate.
Store these in a shared folder with a simple index. The auditor will ask for three or four samples. If you can produce them in under a minute, you pass.
Day 19–21: Run an internal audit.
You need evidence that someone independent has checked the ISMS before the certification body arrives. In a startup, “independent” does not mean hiring an external firm. It means the person doing the internal audit did not write the policies they are checking.
The internal audit is a one- or two-day review: read the five documents, check three pieces of evidence, write a short report noting any gaps. If you find gaps, log them as corrective actions with owners and deadlines.
Week 4: Management review and booking Stage 1
Day 22–25: Management review.
The CEO (or whoever is accountable) reviews the ISMS outputs: risk assessment, treatment plan, internal audit findings, and any incidents since the last review. This can be a 30-minute meeting with a one-page minutes document.
The point is not the length of the minutes. The point is that someone with authority looked at the system, decided it was adequate or not, and approved resources to fix what is broken.
Day 26–30: Book Stage 1 and final checks.
Send your five documents to a certification body. Most UKAS-accredited bodies can offer Stage 1 within two to four weeks. Use the wait to close any remaining gaps — not by adding documents, but by collecting the evidence you already claimed to have.
What this roadmap deliberately leaves out
- A 40-page information security policy. One page is enough.
- A separate policy for every Annex A control. Controls are treated in the SoA, not duplicated in standalone policies.
- Penetration testing before Stage 1. Pen tests are valuable, but they are not required for Stage 1. Schedule one between Stage 1 and Stage 2 if your risk assessment says you need it.
- A dedicated GRC platform. A shared folder and a spreadsheet are sufficient for a startup under 20 people. Upgrade tools when the overhead of managing the spreadsheet exceeds the cost of the platform.
When to bring in help
A founder with a technical background can write the first draft of every document in this roadmap. The value of an external partner — whether a consultant or a virtual CISO — is not in writing longer documents. It is in:
- Spotting the gap between what you think you do and what you can prove
- Knowing which controls an auditor actually samples for a company your size
- Keeping the project on a 30-day timeline instead of letting it drift into quarter two
At Metaluxo we run ISO 27001 gap assessments for startups and SMEs, typically delivering a readiness report in four weeks. If your first enterprise deal or health-system contract depends on certification, book a free 30-minute consultation and we will tell you exactly where you stand.
Common questions
How long does ISO 27001 take for a startup?
A focused startup with under 20 people can reach Stage 1 readiness in 4–6 weeks and certification in 3–4 months, compared to 6–12 months for larger organisations.
Do startups need ISO 27001 before they have customers?
No — but enterprise buyers and health system procurement teams increasingly require it. The right time is usually when your first £100K+ contract depends on it.
What is the biggest mistake startups make with ISO 27001?
Over-documenting. Auditors check that controls exist and are reviewed, not that policies are 40 pages long. Brevity is credibility.
