Free checklist

The ISO 27001 readiness checklist for startups

Forty plain-English checks covering everything a certification body will look at, from scope and leadership through risk, controls and the audit itself. Written by Lead Auditor trained practitioners for companies without a compliance team.

Eight sections Scope, leadership, risk, the Statement of Applicability, people, operations, monitoring and audit preparation.
Plain English Every check written the way an auditor would actually probe it, not the way the standard phrases it.
Startup-sized What genuinely matters for a 5 to 250 person company, with the enterprise theatre left out.

Tick items off as you go: your progress saves automatically and helps us tailor any follow-up conversation. Anything you cannot tick is a conversation worth having.

1. Scope and context

Auditors confirm scope before anything else, because everything hangs off it.

You can state in two sentences what your Information Security Management System (ISMS) covers: which products, teams, locations and systems.
The scope is written down and matches reality, including remote workers and any office you actually use.
You have listed your interested parties (customers, regulators, suppliers, staff) and what each expects of your security.
Internal and external issues that affect security are captured somewhere reviewable, not in someone's head.
Nothing on your website or sales material overstates what the scope covers.

2. Leadership and policy

Certification fails at the top more often than at the firewall.

An information security policy exists, is approved and dated by leadership, and every employee can find it.
Security roles and responsibilities are assigned to named people, and nothing important is owned by everyone.
Leadership can explain why the company wants certification beyond winning a tender.
Security objectives exist, are measurable, have owners and get reviewed. A cost-cutting target is not a security objective.

3. Risk assessment and treatment

The engine of the whole standard. Everything else should trace back to it.

A documented risk assessment exists and was reviewed within the last year.
Each risk has an owner, a score and a treatment decision: reduce, accept, transfer or avoid.
Accepted risks are genuinely signed off by someone entitled to accept them.
When something significant changes (new product, lost staff, new supplier), the risk register moves too.
Risk treatments connect to real controls you can point at, not just to policy documents.

4. The Statement of Applicability

The document auditors read next to reality. Mismatches here are classic findings.

A Statement of Applicability (SoA) covers all 93 controls of Annex A, marking each applicable or not, with a reason.
Every control marked implemented is actually running, and you could show evidence today.
Exclusions have honest justifications that would survive a follow-up question.
The SoA agrees with the risk assessment: treatments promised there appear here.

5. People

Awareness that exists only in attendance records is a finding waiting to happen.

New joiners get security induction, and you can show what it covers.
Security training happens regularly, and you check understanding, not just attendance.
Staff know how to report a security concern, and would actually do it without fear.
Screening appropriate to the role happens before people join.
Joiners, movers and leavers each trigger a checklist that includes access and equipment.

6. Operations and technical controls

The checks an auditor samples hardest in a cloud-native company.

An asset inventory exists, has owners and includes every company device, including the phones executives carry.
Access follows least privilege, admin accounts are few and known, and access reviews happen on a schedule someone owns.
Backups run, and you have tested a restore. Provider mirroring is availability, not backup: if the account itself is compromised, you know where you would recover from.
Multi-factor authentication is on everywhere it can be.
Laptops are encrypted and centrally managed, and a lost device can be wiped.
Patching happens promptly and you could show when critical fixes went out.
Logs exist for your key systems. Centralising them is good practice, but existing and being looked at is the requirement.
Suppliers that touch your data are listed, risk-assessed and checked for their own certifications on a schedule.
An incident response process exists, staff know the first step, and past incidents show root cause analysis and lessons learned.

7. Monitoring, internal audit and management review

The clauses that prove the system runs, rather than merely exists.

You measure something meaningful about security performance, and the measures drive behaviour you actually want.
An internal audit has been performed by someone independent of the work they audited, with a report.
Findings from internal audits have corrections, root causes and corrective actions, with dates and evidence of closure.
Management review happens on schedule, covers the required inputs and produces decisions, not just minutes.
Actions from previous reviews and audits were actually done, and you can show it.

8. Certification audit preparation

What makes the certification body's visit boring, which is the goal.

You have quotes from accredited certification bodies and understand the Stage 1 and Stage 2 structure.
Your ISMS has run long enough to have evidence: weeks of records, not documents written last Friday.
The people who own controls can each speak to their part without a script.
Documents carry consistent names, owners and dates, and nobody's name appears on a document they have never read.
You have had an independent readiness or internal audit, so nothing at Stage 2 is a surprise.

What to do with the gaps

Anything unticked is normal: that is what a gap analysis is for. If you want a prioritised, fixed-price plan for closing them, book a free introductory call or try the cost calculator to get a tailored estimate.