A startup needs ISO 27001 when buyers ask for it, which in Europe and much of Asia means mid-market and enterprise procurement, and increasingly when a regulated customer treats you as a critical supplier under NIS2 or DORA. US buyers more often ask for SOC 2, and many startups eventually need both. The way to keep it small is a narrow scope, one product and the people and systems that run it, a risk assessment that fits on a page, policies that describe what you actually do, and controls inherited from your cloud provider where the shared-responsibility model allows. A team of ten can be certified: the standard does not scale its requirements down, but it does let you scale the ISMS to the organisation.
ISO 27001 was written for any organisation, and most of its text reads as if for a large one: top management, interested parties, audit programmes. Startups read that and either put it off or over-build it. Both are mistakes. The standard scales down well if you let the scope and the risk assessment do the scaling, and the certificate opens doors a ten-person company cannot open any other way.
When a startup actually needs ISO 27001
- A buyer's procurement requires it. In Europe, the Nordics, the UK and much of Asia the ISO certificate is the default proof of security, and the question arrives in the security questionnaire of the first mid-market or enterprise deal.
- A regulated customer treats you as a critical supplier. NIS2 and DORA push essential entities and financial firms to assess their suppliers, and an ISO 27001 certificate is the evidence they ask for first.
- You sell to the public sector, where tenders name the standard.
- You are raising from or selling to organisations that have it themselves and expect it of their vendors.
If none of those applies yet, build the controls anyway, because they are the same ones you will need, and certify when a deal depends on it. The ISO 27001 and SOC 2 comparison covers which document your market expects, and SOC 2 for startups the US-buyer side of the same decision.
Keeping the first scope small
Clause 4.3 lets you define the ISMS boundary, and the certificate prints it. For a startup the right first scope is the product customers are asking about: its development, hosting and support, the people who do that work, and the systems it runs on. A second product, an internal tool or a subsidiary can wait for a later audit. Write the interfaces down, especially the cloud provider and any outsourced function, so the auditor sees what is inherited and what is yours. The scope article covers the statement itself.
What auditors expect from a team of ten
| What the standard requires | What it looks like at ten people |
|---|---|
| Top management commitment and roles (clause 5) | A founder owns the ISMS, signs the policy and attends the management review; one engineer owns the technical controls |
| Risk assessment and treatment (clause 6) | A register of a few dozen risks against the product, its data and its providers, with a founder as risk owner |
| Statement of Applicability | All 93 controls decided; physical and outsourced-development controls often excluded with reasons; cloud controls partly inherited |
| Policies | A short set, often ten to fifteen pages in total, describing what the team does, acknowledged by everyone |
| Competence and awareness (clause 7) | A yearly awareness session and onboarding, recorded per person |
| Internal audit (clause 9.2) | One audit a year by an outside auditor, because nobody inside is independent of the work |
| Management review (clause 9.3) | A ninety-minute founders' meeting against the clause 9.3 inputs, minuted |
| Evidence that controls operate (clause 8, Annex A) | Records collected from the identity provider, cloud, code and device systems as controls run |
Where the time goes
For a small, cloud-hosted team the ISMS can be built in a few months, and the audit stages then add the calendar time the timeline article describes. The long parts are the ones that need other people: the risk assessment, which needs the founders' decisions; the operating period, which needs the controls to have run; and the certification body's schedule. Start the conversation with certification bodies early, because the lead time for audit dates is often longer than the time to prepare.
Mistakes small companies make
- Buying an enterprise policy template set and adopting it unread, so the policies promise committees and processes that do not exist.
- Scoping the whole company when buyers asked about one product.
- Having the founder who built the ISMS do the internal audit, which fails the independence test.
- Treating physical controls as not applicable without a reason, when the real answer is that the office is serviced and the data centre is the provider's.
- Collecting evidence by screenshot the week before Stage 2.
- Setting objectives that cannot be measured, so the management review has nothing to review.
After the certificate
The certificate is valid for three years with a surveillance audit each year, and the ISMS has to keep running between them: the yearly internal audit and management review, the risk assessment refreshed when the product or the team changes, and evidence that accumulates. As the company grows the scope widens at a surveillance audit rather than through a new certification, and the controls built for one product carry across to the next. Noru is built for this stage: the ISO 27001 plan walks from scope to Stage 2 in order, evidence is collected from the systems you connect, Cortex drafts the policies from the controls you selected, and the audit package bundles what the certification body asks for.