"How long will it take?" is the first question every founder asks about ISO 27001. The honest answer is "it depends" -which is unsatisfying enough that most blogs invent a confident-sounding number instead. The result: timelines that bear no relation to what actually happens.
This piece gives you the honest version. Four variables decide the timeline, three project profiles cover most real situations, and the slippage patterns are predictable enough to plan for. If you have read our implementation roadmap, this is the schedule view of the same content.
1. The Four Variables That Decide Your Timeline
Project length is not a function of how hard you want it. It is a function of four conditions:
| Variable | Fast Path | Slow Path |
|---|---|---|
| Organisation size | Under 50 people, single location | 500+ people, multi-site or multi-country |
| Scope | Single product or service, one platform | Multiple products, multiple cloud providers, legacy systems |
| Starting maturity | Some security policies exist, basic controls operating | Greenfield -no documented policies, no internal audits ever run |
| Dedicated resources | Full-time project lead plus engaged executives | Part-time owner with day job, low executive engagement |
The single most predictive variable is the fourth -dedicated resources. A small organisation with a full-time project lead will finish faster than a large organisation with a part-time owner, even though the larger organisation has more people to work on it. ISO 27001 is a project that needs an owner, not a side hustle.
The most common reason projects take 14+ months instead of 9 is that the project owner has a day job. The work happens in stolen evenings and weekend hours. Documentation gets drafted but never reviewed. Controls get designed but never implemented. The project does not slip dramatically -it slips constantly, by a few days each week, until the calendar has gone past 18 months.
2. Three Typical Timelines
Most real ISO 27001 projects fit into one of three profiles. Pick the one your organisation actually matches -not the one you wish it did.
The Sprint Profile
A small organisation (under 50 people), a tight scope (single SaaS product on one cloud platform), an already-mature security posture (you have policies, you do code reviews, you have an incident response runbook), and a dedicated full-time project lead.
This profile exists. It is not the norm. About 1 in 6 real projects fits these conditions. The certification body Stage 1 to Stage 2 gap alone consumes 4-8 weeks of the timeline, which makes anything under 4 months practically impossible regardless of how prepared you are.
The Standard Profile
A small-to-medium organisation (50-250 people), a typical scope (one or two products plus the supporting infrastructure), a moderate starting baseline (some security work has been done, but documentation is patchy and internal audits have never been run), and a dedicated internal lead -either full-time on this project or with this as the clear 50%-plus priority.
This is the most common profile. About half of real projects fit here. The project runs roughly: 6-8 weeks gap assessment and scope, 12-16 weeks implementation, 4-6 weeks internal audit and management review, 6-10 weeks certification audit cycle.
The Extended Profile
Any project where one or more variables go to the slow path. A larger organisation, a wide scope, low starting maturity, or a part-time owner -any of those tips the project past 12 months. Two or more, and you are looking at 16-20 months.
This is not a failure profile. Plenty of organisations land here for legitimate reasons -multiple business units that need stakeholder alignment, legacy systems that need significant uplift before they can be brought into scope, geographic distribution requiring local champion enrolment. The cost is in carrying the cost of the project longer; the certification is identical at the end.
3. Phase-by-Phase Breakdown
The 9-12 month standard timeline broken down into its constituent phases. Sprint profile compresses these; extended profile stretches them, particularly Phase 2.
| Phase | Standard Duration | Critical Output |
|---|---|---|
| Gap assessment + scope | 4-6 weeks | Gap register, scope statement, project plan |
| Risk assessment | 3-4 weeks | Risk register, treatment plan, SoA v1 |
| Control implementation | 12-20 weeks | Policies, procedures, technical controls operating |
| Records accumulation | 6-12 weeks (overlap) | Operating evidence -audit logs, change records, training |
| Internal audit | 4-6 weeks | Internal audit report, corrective actions started |
| Management review | 1-2 weeks | Documented review with all required inputs |
| Stage 1 certification audit | 1 week onsite + 1 week reporting | Stage 1 report, findings to address |
| Stage 1 to Stage 2 gap | 4-8 weeks | Stage 1 findings closed, evidence ready |
| Stage 2 certification audit | 1-2 weeks onsite + 2-3 weeks reporting | Certificate issued |
Auditors at Stage 2 want to see controls operating for at least 2-3 months -that means logs, evidence, records over a meaningful window. You cannot implement a control on Monday and audit it on Friday. Build records-accumulation into the schedule before the internal audit, not after.
4. Two Common Timeline Myths
Myth 1: "10-week ISO 27001"
You will see this in some marketing material. The reality is that 10 weeks is roughly the time it takes to write the documentation, not the time it takes to get certified. The certification audit cycle alone takes 4-8 weeks across Stage 1 and Stage 2. Add the time controls need to operate before they can be tested, and 10 weeks is structurally impossible -not because of consulting hours, but because of how the audit standard works.
Myth 2: "We can compress the Stage 1 to Stage 2 gap"
Some teams hope to book Stage 1 and Stage 2 back-to-back. Certification bodies generally will not do this. The gap exists for a reason -to allow closure of Stage 1 findings and accumulation of the operational evidence Stage 2 will sample. A typical certification body requires at least 4 weeks between stages; some require 6. Plan the calendar around this.
5. Where Projects Actually Slip
From the patterns we see across implementations, three slippage causes dominate. They are predictable; if you plan for them you avoid most of the delay.
Cause 1: Scope changes mid-implementation
Month 4 of an 8-month project, someone realises the proposed scope leaves out the customer support tooling. The decision is to expand scope. The expanded scope adds 2-3 months of work. The result: 11-month project. Mitigation: lock scope by month 2, in writing, signed by the executive sponsor. Treat scope changes as project changes that require new sign-off and a revised timeline.
Cause 2: Insufficient operational evidence at Stage 2
The team designs all the controls, writes all the policies, and arrives at Stage 2 expecting certification. The auditor asks to see 3 months of access reviews; the team has done one. The auditor asks for 6 months of vulnerability scans; the team has done two. Stage 2 produces Minor or Major NCs on every under-evidenced control, and certification slips by the corrective action window. Mitigation: start operating controls 4-6 months before Stage 2, not 4-6 weeks. Records cannot be retrofitted.
Cause 3: Unavailable certification body slots
This is outside the team's control but predictable. In tight markets, certification body slots are booked 3-6 months ahead. If you wait until you are "ready" to book the audit, the next available date may be 4 months away. Mitigation: book Stage 1 and Stage 2 dates by month 4 of the project, before you are ready, with the contract structured to permit rescheduling. The booked date functions as a forcing function for everything else.
6. After Certification -Surveillance & Recertification
The certificate is valid for three years. To maintain it:
- Year 1 surveillance audit. Approximately 12 months after certification. Smaller audit than Stage 2 -typically 1-3 days onsite. Auditor samples a subset of the ISMS, focuses on changes since certification, and checks that the management system is being maintained.
- Year 2 surveillance audit. Same structure as Year 1. Different auditor scope -they will sample what Year 1 did not.
- Year 3 recertification audit. Closer in scale to the original Stage 2. Re-tests the full ISMS scope, refreshes the certificate for another three years.
Plan for 5-10 person-days of internal time per surveillance audit and 15-25 person-days for recertification. The ongoing cost is significant but predictable.
Get a realistic timeline for your project
We will scope your project against the four variables and give you an honest timeline -not the marketing number. Plus the schedule, milestones, and certification body availability you will need to plan around.
Book a scoping call →FAQ
Only in narrow circumstances -a very small organisation, a tight scope, an already-mature security posture, and a dedicated project team. For most organisations starting from a low baseline, 3 months is unrealistic. The certification audit alone requires 4-6 weeks between Stage 1 and Stage 2, plus the corrective action window, so even a perfectly executed project rarely finishes in under 5 months end-to-end.
For a small-to-medium organisation with moderate maturity and a part-time internal lead, 9-12 months from project kickoff to certificate. Faster is possible with full-time resources and external consultancy; slower is common when the project loses momentum or scope creeps mid-implementation.
Three things in order of frequency -scope changes mid-implementation, missing operational evidence at the time of audit (controls designed but not yet operating long enough to test), and unavailable certification body slots which can add 4-8 weeks to the calendar regardless of how ready you are.
Three years. Surveillance audits occur annually in years 1 and 2, and a full recertification audit in year 3. The certificate remains valid as long as surveillance audits pass and no major nonconformities arise.
Yes, and it is recommended. Certification body slots are scarce in some markets and booking 3-6 months ahead is common. The contract is usually flexible enough to reschedule if you slip, but securing the date keeps the project honest about its deadline.