Who should read this: anyone who has been asked how long ISO 27001 will take and does not want to give an answer they will have to walk back in February.
The short version. A company of 20 to 250 people, starting from a normal unmanaged position, with nobody whose job is security, should plan for nine to twelve months. If someone quotes you three, they are either scoping very narrowly or planning to assemble evidence rather than generate it, and one of those is a problem you will meet at Stage 2.
Here is where the months actually go.
The phases, with honest durations
| Phase | Realistic duration |
|---|---|
| Scoping, risk assessment, Statement of Applicability | 4 to 8 weeks |
| Closing the gaps that matter | 2 to 5 months |
| Running the system to accumulate evidence | 3 months minimum, 6 is comfortable |
| Internal audit and management review | 2 to 4 weeks |
| Stage 1 audit | a few days to two weeks |
| Gap between Stage 1 and Stage 2 | 4 to 6 weeks |
| Stage 2 audit | 1 to 2 weeks of calendar time |
| Certification decision and certificate issued | up to 3 months |
Add those up and the arithmetic looks worse than reality, because several of them overlap. The important thing is which ones can overlap and which cannot.
The one thing you cannot compress
Your management system has to have been operating for a minimum period before Stage 2, typically three months. Auditors want to see a history: access reviews with dates, patch records, incident tickets, a management review that actually happened, supplier assessments filed over time.
That is calendar time, not effort. You cannot buy it, parallelise it, or work weekends to shorten it. Everything else in the list above is compressible with money and focus. This is not.
Which produces the single most useful scheduling insight available: the clock that matters starts when your evidence starts, not when your documentation is finished. Most projects run in the wrong order, spending three months perfecting policies and then starting the evidence clock in month four, which pushes certification out by a full quarter for no gain.
Turn on the boring recurring things in week one. Access reviews, patch records, log retention, the first supplier assessments. They can be imperfect. They cannot be missing.
Why 40% of Stage 2 audits get rescheduled
Roughly four in ten organisations that go into Stage 1 without a managed security programme have to move their Stage 2, because the evidence is not there when the auditor arrives.
The pattern is always the same. Stage 1 is a documentation review, and documentation is the thing consultants are good at producing, so Stage 1 goes well. Stage 2 asks whether the documented system actually ran, and that is where a project that front-loaded paperwork falls over.
The specific causes, in the order we see them:
- The risk assessment or the Statement of Applicability is incomplete at Stage 1, so the auditor cannot even establish what they are supposed to test.
- Operational records are missing for the three-month window. The controls were designed but nothing recorded them running.
- Major nonconformities at Stage 2 that need remediation before a certificate can be issued, which adds weeks and sometimes a repeat visit.
- The scope was drawn badly and has to be redrawn, which invalidates part of the work already done. Worth reading scope and Statement of Applicability before you commit to a boundary.
What actually makes it slower, in order
Ownership that is not real. The strongest predictor of a project that drifts is that security is nobody’s actual job. The project has energy for six weeks, then the CTO gets a product deadline, and three months evaporate. If you cannot name the person and point at time in their calendar, add a quarter to your estimate.
Decisions left open. Scope, risk appetite, what you will not do this year. Every week one of these stays open is a week of work happening around it that may need redoing. These are covered in the decisions only you can make.
The supplier long tail. Inventorying vendors, classifying them, getting security information back, recording it. The constraint is other people’s response times, which is why it should start in week one and never does.
Engineering work competing with the roadmap. Configuration management, separation of environments, secure development. Real weeks of real engineering, and the only group where throwing documentation at the problem does nothing.
Certification body scheduling. Book earlier than feels necessary. Audit slots are not always available when you want them, and the gap between Stage 1 and Stage 2 is four to six weeks by design anyway.
What genuinely shortens it
Not much, and be suspicious of anyone claiming otherwise. But three things are real:
- Start the evidence clock in week one. Worth up to a full quarter, as above, and it costs nothing.
- Scope deliberately rather than broadly. A scope drawn to answer your customer’s actual question is smaller than “the whole company” and smaller means faster. It also means fewer controls in play, which shrinks groups 4 and 5 of the control work.
- Know your gaps before you start. Most of the variance in that “2 to 5 months” remediation band is simply not knowing what is broken. An independent audit up front converts an unknown into a plan, which is the difference between a project and a drift.
If you are doing NIS2 at the same time, do the work once. The overlap is substantial and the mapping is well understood, set out in certification standards and ISO 27001 under NIS2. For the full picture of a first certification with no security team, start with ISO 27001 for a company without a security team, and on where the money goes, is €50k for ISO 27001 worth it. The route is laid out on our ISO 27001 solutions page.
A timeline you can actually hand to your board
For a 40 person software company, cloud hosted, scoped to the product and the teams that build and run it:
- Months 1: decisions, scope, risk assessment, Statement of Applicability. Evidence generators switched on. Supplier inventory started.
- Months 2 to 4: remediation. Engineering work runs in parallel with documentation. Evidence accumulating.
- Month 5: internal audit, then management review. Fix what the internal audit finds, which is the point of doing it.
- Month 6: Stage 1.
- Month 7 or 8: Stage 2, four to six weeks after Stage 1.
- Months 8 to 10: certificate issued, allowing for the certification decision.
That is the good case, with real ownership and no surprises. Ten to twelve is the safer number to say out loud.
The technical reality: a compressed timeline buys a certificate, not security
Here is the part worth being blunt about.
Every one of the compression tricks that circulate actually works. Narrow the scope hard, buy a policy pack, run the evidence period at the minimum, mark generously in the Statement of Applicability, and you can hold a valid certificate in six months. The standard permits all of it.
What you should know is where the time went. Compression never comes out of the documentation, because documentation is what the auditor reads first and it is cheap to produce. It comes out of remediation. The gap list that would have taken four months to close gets triaged down to the items that block the audit, and the rest move to a roadmap that quietly stops being reviewed.
So the honest framing when someone asks how long it takes is this: certification takes six to twelve months. Becoming defensible takes as long as your gap list takes, and the certificate does not tell you which one you bought.
If the deadline is a customer contract and the certificate genuinely unblocks revenue, compress it, take the certificate, and keep the untouched half of the gap list somewhere it gets read every quarter. That is a legitimate business decision. The failure mode is not compressing the timeline. The failure mode is compressing it and then believing the certificate meant you were finished.
