How Long ISO 27001 Certification Actually Takes
The 2013 version became invalid on October 31, 2025. Stage 1 and Stage 2 audits, the three-year cycle, and the gap between getting certified and staying certified.
Short answer: ISO 27001 certification is granted through a two-stage audit and the certificate is valid for three years. But certification is only the start: there is a surveillance audit every year and a recertification at the end of the third, so the management system has to be kept running.
When a customer says "let's get ISO 27001", we ask why they want it before we talk about how long it takes. If the answer is "our customer is asking for it", the scope can be kept narrow. If the answer is "we genuinely want to fix security", it is a different project, with a different scope and timeline.
First, where things stand: the 2013 version is no longer valid
The three-year window for moving to the 2022 version closed on October 31, 2025. After that date all ISO/IEC 27001:2013 certificates are treated as invalid. The deadline for transition audits was earlier still; according to the timeline published by certification bodies, transition audits had to be completed by July 31, 2025.
The practical consequence: an organization that missed the transition can no longer have a "transition audit" performed. A company holding an expired 2013 certificate is treated as a new client and has to go through Stage 1 and Stage 2 audits from the beginning: a full certification process instead of a short gap audit.
The same applies when assessing suppliers: if a supplier's certificate says 2013 on it, that certificate means nothing today.
How the process runs
Defining scope. Which business units, locations and systems the certification will cover. Making the scope wider than necessary is the most common mistake; the certificate is audited against that scope every year, and a wide scope is a permanent burden.
Gap analysis. The difference between what the standard requires and where you are. The output is a task list.
Implementation. Policies, risk assessment, statement of applicability, procedures and technical controls. This is the longest part of the process and its length depends entirely on the starting point.
Internal audit and management review. The system must have been audited once internally before the certification audit. This step cannot be skipped; it is the first thing the auditor asks about.
Stage 1 audit. The certification body reviews documentation and readiness. It usually ends with a list of gaps, which is normal.
Stage 2 audit. The real audit. Controls are checked against evidence that they operate as written.
After certification. The certificate is valid for three years. Surveillance audits in years one and two, recertification at the end of year three.
The most misunderstood point
ISO 27001 is not a technology certificate but a management system certificate. Instead of requiring a particular product or technical configuration, it asks you to select controls based on your risk assessment, implement what you selected, and prove that you did.
In practice, two companies in the same industry can both hold ISO 27001 and be in very different places technically. The certificate does not say "you are secure"; it says "you know your risk and you manage it".
That distinction matters when assessing a supplier: besides asking whether the certificate exists, ask about its scope, its statement of applicability, and its version. A certificate scoped to a single office is not the same thing as one covering the whole operation.
Which controls does the infrastructure side cover?
Some of the standard's controls map directly to infrastructure and operations work. If you work with a managed service provider, these can be covered on the supplier side:
Access control and privileged account management. Logging and monitoring. Backup and evidence of restore. Vulnerability management and patching. Cryptography and key management. Capacity management. Change management. Business continuity readiness.
For every control covered on the supplier side, the auditor wants the same thing: evidence. A restore record showing backup works, a report showing the patch process runs, a signature showing access review was performed. If your contract does not require those outputs to be handed over to you, the gap is yours at audit time.
Two items cause the most trouble. First, recovery evidence: the auditor wants a record that the plan actually works, meaning a drill date and a measured recovery time. We set out the method in the disaster recovery failover test guide. Second, records management: how long each type of log is kept must be set by a written policy; we covered that in log retention periods.
Which is harder, getting certified or staying certified?
Most organizations get their first certificate and then struggle at the year-two surveillance audit. The reason is always the same: once the project ends, the system loses its owner. The risk assessment is not updated, the internal audit is not run, the policies are not read.
The simplest way to prevent that is to write the annual calendar the moment the certificate arrives: when the internal audit happens, when the management review happens, when the risk assessment gets updated. A one-page calendar makes the second year's work predictable.
You can see how we build this layer on the ISO standards page.
Sources
- ISO/IEC 27001:2022 transition timeline: the October 31, 2025 deadline and what follows it
This article is general information. The certification process and its timing vary with the accredited certification body you choose and with your scope.