The first question almost every founder, COO, or compliance lead asks when they start scoping ISO 27001 is: how long is this going to take?
The answers they get from the internet are unhelpfully wide. Some sources say three months. Some say eighteen. Consultants give different timelines depending on what they are selling. The honest answer — it depends — is true but useless without the variables that drive it.
This post walks through what an ISO 27001 certification timeline actually looks like in 2026, the factors that compress or extend it, and a realistic month-by-month set of milestones for a first-time implementation.
The Headline Answer
For a first-time ISO 27001 implementation at an Indian organisation of roughly 50 to 200 people, with no existing formal information security programme:
- Fastest realistic timeline: 5 to 6 months
- Typical timeline: 8 to 10 months
- Slow but common timeline: 12 to 15 months
Anything below 5 months is rarely possible without significant compromises in the quality of the management system. Anything beyond 15 months usually indicates that the project has stalled rather than that it is genuinely complex.
These numbers are for the 2022 edition of the standard, which is the only version certification bodies will audit against in 2026.
The Phases of a First-Time Implementation
Whether your timeline lands at 5 months or 15, the project moves through the same broad phases. The difference is how long you spend in each.
Phase 1: Project setup and scoping (weeks 1–4)
You define the scope of the ISMS — which products, business units, locations, and people are in. You appoint an internal project owner, secure leadership commitment, and establish the project's resourcing.
This phase is short in elapsed time but consequential. Scope decisions made here define the cost, complexity, and credibility of the eventual certificate. The most common error is scoping too broadly — covering the entire company when only one product or function is actually relevant to customers.
Output: A defined scope statement, a project plan, an executive sponsor, a working group.
Phase 2: Gap analysis (weeks 3–6)
You compare your current state to the requirements of ISO 27001:2022 — Clauses 4 through 10 and the 93 Annex A controls. The output is a structured list of gaps, each with an owner and remediation approach.
This phase often runs in parallel with Phase 1's tail end. A good gap analysis is the single most useful artefact in the project. It defines everything that follows.
Output: A gap register, a remediation roadmap, an early Statement of Applicability draft.
Phase 3: Risk assessment and risk treatment (weeks 5–10)
You build an asset inventory, identify threats and vulnerabilities, assess risk, and decide which risks to mitigate, accept, transfer, or avoid. The mitigations chosen feed into the Statement of Applicability — the document that records which Annex A controls you have implemented and why you have excluded any.
For first-time implementers, this is often the most cognitively demanding phase. The methodology you choose (qualitative, semi-quantitative, fully quantitative) shapes how much time it takes.
Output: Asset inventory, risk register, risk treatment plan, draft Statement of Applicability.
Phase 4: Policy and documentation build (weeks 6–14)
You write or adapt the documented information the standard requires — information security policy, supporting policies, procedures, work instructions. The 2022 edition requires a defined set of documents, and auditors have well-formed expectations of what each should contain.
This is one of the phases most commonly compressed by using credible templates. It is also one of the phases where compression hurts most — generic policies that do not reflect how the organisation actually operates produce audit findings later.
Output: Information security policy, supporting policies, procedures, records framework.
Phase 5: Control implementation (weeks 8–22)
You implement the technical and organisational controls that the risk treatment plan calls for — access management, encryption, logging and monitoring, vendor controls, secure development practices, physical safeguards, HR processes, training, and so on. The 11 new controls in the 2022 edition (threat intelligence, cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, secure coding) often require new tooling or process changes.
This is the longest phase, the most expensive in tooling cost, and the most variable across organisations. A company already running a mature engineering shop with logging, monitoring, vulnerability scanning, and SDLC discipline can compress this phase substantially. A company starting with minimal technical security tooling cannot.
Output: Implemented controls, evidence collection processes, operational records.
Phase 6: Operate the ISMS (weeks 16–28)
Auditors want to see the management system running, not just built. You operate the ISMS for a period — typically three to six months — generating real evidence of risk reviews, change management, access reviews, incident handling, training, vendor reviews, and so on.
This phase cannot meaningfully be compressed without affecting audit outcomes. The Stage 2 auditor will look for operational evidence across this period, and there is no shortcut for time itself.
Output: Operational evidence — reviewed access lists, logged incidents, completed training, conducted vendor assessments.
Phase 7: Internal audit (weeks 24–28)
You conduct an internal audit of the ISMS against the standard. This is a required step before external audit, and the findings often produce a final round of fixes before Stage 1.
Output: Internal audit report, corrective actions.
Phase 8: Management review (weeks 26–30)
Top management formally reviews the ISMS — its performance, the results of the internal audit, the risk landscape, the effectiveness of controls, and the resources required for continual improvement. This is required by Clause 9.3 and is one of the standard's most under-appreciated requirements.
Output: Management review minutes with documented inputs and outputs.
Phase 9: Stage 1 audit (weeks 28–32)
The certification body conducts a documentation audit. The auditor reviews the ISMS documentation, the SoA, the risk assessment, and key policies. Stage 1 typically takes 1 to 3 days for an organisation of this size and surfaces any documentation-level gaps that need to be addressed before Stage 2.
Output: Stage 1 audit report, list of any required corrections.
Phase 10: Stage 2 audit (weeks 32–36)
The certification body conducts an implementation audit. The auditor interviews staff, reviews evidence, and walks through controls in operation. Stage 2 typically takes 3 to 7 days depending on scope and complexity.
If Stage 2 produces no major non-conformities, the certificate is issued. Minor non-conformities can usually be addressed with documented corrective action plans without delaying the certificate.
Output: ISO 27001:2022 certificate, valid for three years, with annual surveillance audits.
What Compresses the Timeline
Some organisations realistically certify in 5 to 6 months. The factors that make this possible:
- An existing mature security programme. If you already run a structured security function with logging, vulnerability management, access governance, and a real SDLC, you are starting from 60% of the work already done.
- Strong executive sponsorship. Projects with active C-level ownership move twice as fast as projects with a delegated mid-level owner.
- A dedicated internal lead. A full-time or near-full-time project owner is the single biggest accelerator.
- A small, well-defined scope. A focused certification covering one product and the corporate functions that support it moves much faster than enterprise-wide coverage.
- Use of a GRC platform. Modern platforms (including XiliShield-class tooling) compress evidence collection, control mapping, and Statement of Applicability work significantly.
- Templates and prior art. Credible policy templates, adapted carefully, save weeks compared to writing from scratch.
What Extends the Timeline
The most common reasons projects stretch to 12 to 15 months:
- Scope creep. The scope expands midway through the project, often because someone asks "shouldn't this also cover…?" and gets a polite yes.
- No dedicated owner. The project is parked with someone whose day job consumes 90% of their time. Progress happens in fits and starts.
- Tooling gaps. The risk treatment plan calls for technical controls (logging, MDM, DLP, EDR) the company does not have, and procurement timelines stretch the implementation phase.
- Documentation perfectionism. The team rewrites every policy three times. None of the rewrites materially improve the auditability.
- Audit body scheduling. Stage 2 audits at major certification bodies often need to be booked 2 to 3 months in advance. Late booking creates a forced delay at the end of the project.
- Treating it as a side project. When ISO 27001 is "the thing we work on when we have time," it never finishes.
Realistic Milestones for a 9-Month Implementation
For a typical 100-person Indian SaaS company starting from a moderately mature baseline, a realistic milestone plan looks like:
- Month 1: Scope locked, project team in place, gap analysis kicked off
- Month 2: Gap analysis complete, risk methodology agreed, asset inventory in draft
- Month 3: Risk register drafted, Statement of Applicability v1, policy build begins
- Month 4: Core policies and procedures complete, control implementation in flight, training programme rolled out
- Month 5: Most controls operational, evidence collection processes running, vendor reviews underway
- Month 6: Full ISMS operational, three months of evidence accumulating, internal audit prep
- Month 7: Internal audit conducted, corrective actions, management review
- Month 8: Stage 1 audit, address Stage 1 findings
- Month 9: Stage 2 audit, certificate issued
This timeline is achievable. It is not aggressive, but it is not leisurely either.
What Happens After Certification
The certificate is valid for three years, with annual surveillance audits. The maintenance commitment in years 2 and 3 is significantly lower than the year-1 build — typically 25% to 35% of the original effort, depending on how well the ISMS was operationalised. At the end of year 3, a full recertification audit is conducted.
The most common post-certification mistake is treating the certificate as the finish line. The organisations that get the most value from ISO 27001 treat the year-1 work as the foundation and use the maintenance years to deepen the integration of the ISMS into normal business operations.
A Closing Note
ISO 27001 is not a sprint, and treating it as one usually produces an audit-ready document set on top of a fragile management system that wobbles at the first surveillance audit. It is also not a multi-year saga, and projects that stretch beyond a year are usually suffering from organisational issues (no owner, no sponsor, scope creep) rather than from any inherent complexity of the standard.
The most realistic frame for a first-time Indian implementation in 2026 is 9 months of focused work, with leadership engaged and a defined owner. Compress this if your starting position is already mature; extend it if your environment requires building several control areas from scratch; but treat 9 months as the planning baseline.
The companies that finish on time are not the ones that work harder. They are the ones that scope tightly at the start, resource the project realistically, and resist the pull to expand it midway.
The single highest-leverage decision in the project is the scope statement in Month 1. Get that right and the rest of the timeline mostly takes care of itself.