ISO 27001 timeline: the time you cannot buy

Ask how long ISO 27001 takes and you get answers between three and fourteen months. That spread is already the answer.

The range comes from an ISMS.online overview of certification timelines, which puts companies with 50 to 250 employees at 6 to 9 months. Eleven months between the fastest and the slowest case, with the same standard, the same two-stage audit and often the same certification body. So the standard does not explain the spread. What explains it sits inside your operation.

And the part that drives the timeline appears in no proposal. You can buy consultant days, templates and software. You cannot buy operating time, and you cannot buy the decision speed of your own people.

How long does an ISO 27001 certification take?

For an SME with 50 to 250 employees, published benchmarks put the path from project start to certificate at 6 to 9 months, and across all company sizes at 3 to 14 months. Which end of the range you hit depends less on the standard than on how you cut your scope, how long your ISMS has been running and how quickly decisions get made in your company.

That is the short answer. The longer one is more useful, because it shows you where your own schedule tips over.

The three items that make up the timeline

Do not treat the timeline as one number. Treat it as three items that behave very differently.

The build. Defining the scope, capturing and assessing risks, writing policies and procedures, implementing controls, organising evidence. This is the item that consultants, templates and ISMS software shorten. This is the lever every vendor sells, and it is real. What it does to the invoice is laid out in our article on the cost of an ISO 27001 certification.

The operating time. The ISMS has to run before there is anything to audit. The same overview gives a rule of thumb: an ISMS should be operational at least three months before the stage 2 audit. This item does not respond to budget. It responds to the calendar.

The audit window. Stage 1 reviews the documentation, stage 2 the implementation as it is lived. According to the same source, four to eight weeks usually sit between the two, and the gap must not exceed six months. On top of that comes the lead time for the appointment itself, because certification bodies book auditors months in advance. How the audit day runs and what a nonconformity means is covered in our article on the ISO 27001 certification process.

The distribution is the point. The item you pay the most for is rarely the item that sets the schedule.

The item you cannot shorten

Operating time is not something the certification body invented. It is in the standard. ISO/IEC 27001 requires an internal audit under clause 9.2 and a management review under clause 9.3. Both must have taken place before the certification body examines implementation in stage 2. An internal audit of a system nobody has used yet finds nothing. A management review without operating data assesses nothing.

Then there is audit practice. The auditor does not only check whether a policy exists, but whether it has left traces in daily work. Approvals with different dates, a ticket where someone requested an exception and gave reasons, minutes where a risk was consciously accepted. An ISMS whose documents all carry the same creation date can be formally complete and still prove nothing.

That is why the most aggressive schedules fail on the physics of the calendar rather than on effort. You can add two more consultants and finish the documentation in half the time. You cannot fit three months of operation into three weeks.

Decision speed beats the project plan

Here is the part that, in our experience, explains most of those eleven months, and it appears in no project plan as a line of its own: the speed at which decisions get made in your company.

Four decisions come up in almost every ISMS project, and each one can cost weeks.

  • The scope: which sites, which systems, which services are in, and what is deliberately left out. That is a decision for the management team, not busywork for the project team. Postpone it three times and weeks are gone before the first policy is written.
  • The risk owners: the standard wants an owner for every material risk. It means a person with a name. This is where meetings regularly go quiet, because a name means responsibility and responsibility is rarely volunteered for.
  • The accepted risks: not every risk gets treated. Whoever accepts a residual risk has to sign it off. That too is a leadership decision that needs a slot in the calendar.
  • The supplier side: collecting evidence from service providers takes as long as those providers take. You have no control over that pace, you can only start early.

Seen soberly, the ISO 27001 timeline is largely a leadership metric. It measures how quickly an organisation assigns responsibility and stands by it. That is uncomfortable, because it cannot be delegated, and it explains why two companies of the same size with the same consulting budget can end up months apart.

The one lever that moves all three items at once

The lever is called scope.

A narrow scope means less to document, less operation to evidence and a smaller audit. This is why many companies first certify the part their customers ask about, such as the platform, the data centre operation or a single business unit, instead of the whole company at once. That is consistent with the standard and in many cases the more sensible sequence.

The price for it, however, is printed on the certificate. The scope is part of the document, and your customer reads it. If it names one site and the customer asks about the group, you have only postponed the discussion. On top of that, extending the scope later brings its own build and audit work.

From this follows a rule that usually saves the schedule. Cut the scope along what you want to promise your customers, not along a desired date. Whoever shrinks the scope to hold a date pays a second time with the next customer questionnaire. The same logic applies when choosing the standard itself, for instance in the question of ISO 27001 or TISAX: the proof follows whoever wants to see it.

The promise of "ISO 27001 in three months"

The promise exists, and it is not even wrong. It just means something other than what you assume when reading it.

Three months usually refers to audit readiness of the documentation, meaning the vendor's own deliverables. ISMS tools do compress that part considerably, because policy templates, risk catalogues and evidence management no longer have to be built by hand. What they do not compress: the months the system has to run, the internal audit, the management review and the certification body's calendar.

The useful counter-question in a sales conversation is therefore not "how fast can you do it", but: which event stands at the end of your three months? Handover of the documentation, a passed stage 1 audit or the certificate in hand. In reality those three answers lie months apart, and the question costs you ten seconds.

You know the same pattern from the other direction. Hang the schedule on a customer request and you often build more system than the operation can carry. A baseline assessment before the ISMS project tells you up front how long the road is, instead of letting you find out in month four.

How to tell whether your schedule holds

You do not need a project plan with two hundred lines for this. Three checkpoints are enough, and they work in the middle of a running project too.

First: are there dates in the calendar for the internal audit and the management review, or only a date for the certification audit? If those two mandatory appointments are missing, the plan has not been fully costed yet.

Second: does the scope have a name as its owner and a decision date? A scope that is still being discussed is an open item with an unknown duration.

Third: how many weeks sit between finishing the last policy and the stage 2 appointment? If it is fewer than eight, plan the buffer now rather than later under pressure.

Hesitating on one of these three points is not yet a problem. It is information about the realistic date, and right now it is still cheap to get. This is exactly the baseline we establish at the start of our ISO 27001 ISMS engagements, before anyone commits a date to a customer. If you want to know where you stand, an informal first conversation is the shortest way there.

A date that holds

A certification appointment is a commitment to an auditor, and in the background usually to a customer as well. That is why a date you can defend is worth more than a date that sounds good. The difference between the two lies not in the number of consultant days, but in whether the decisions are in the plan or only the documents.

The question we find most useful in first conversations is therefore not how long you will need. It is: who in your company decides on the scope, and when does that person next have time for it?

Frequently asked questions

How long does an ISO 27001 certification take for an SME?

Published benchmarks put an SME with 50 to 250 employees at 6 to 9 months from project start to certificate, and 3 to 14 months across all company sizes. Where you land in that range depends on how you cut the scope, how long your ISMS has been running and how quickly your company makes decisions.

Can you get ISO 27001 in three months?

For the documentation yes, for the certificate rarely. Three-month promises usually refer to audit readiness of the paperwork. On top of that come the operating time of the ISMS, the internal audit, the management review and the certification body's lead time. Ask which event stands at the end of those three months.

Why does an ISMS have to be running before the audit?

Because otherwise there is nothing to audit. ISO/IEC 27001 requires an internal audit and a management review before the certification body examines implementation, and the auditor wants evidence from daily work. An ISMS whose documents all carry the same creation date can be formally complete and still prove nothing.