Use a 12-week, 30/60/90-day project plan when you have executive sponsorship, a dedicated ISMS lead, and some baseline security controls already in place. That structure gets you to audit-ready artifacts (charter, gap analysis, risk assessment, and Statement of Applicability) fast. Without those conditions, budget 4 to 12 months instead. Either way, the first deliverables never change: a signed project charter, a documented scope, a clause-by-clause gap analysis, and an initial risk register.
TL;DR:
- Organizations with a dedicated ISMS lead working full-time and strong executive support can achieve ISO 27001 certification in 12 weeks, provided controls are already in place.
- For organizations starting from scratch or with limited control maturity, the project timeline extends to four to twelve months, emphasizing foundational setup and awareness.
- Key milestones include a signed project charter, a documented scope, a clause-by-clause gap analysis, and an approved information security policy, all completed within the first 30 days.
- Risk assessment and Statement of Applicability require consistent, simple methodologies, asset classification, threat identification, and detailed control mapping, progressing through weeks 31 to 60.
- Accelerating the process risks evidence gaps and scope creep, so strict time-boxing, pre-built templates, and parallel task execution are essential to maintain audit readiness without compromising quality.
Table of Contents
- What Is the Right ISO 27001 Project Plan Timeline for Your Organization?
- Prerequisites and a Planning Checklist Before You Start the Clock
- Days 1 Through 30: The Foundation Phase, Week by Week
- Days 31 Through 60: Risk Assessment, the SoA, and Core Procedures
- Days 61 Through 90: Implementation, Training, and Certification Prep
- A 12-Week Timeline You Can Copy Into Your Own Plan
- What Staffing and Budget Actually Look Like
- How to Accelerate Without Wrecking the Audit
- What I’ve Seen Break ISO 27001 Projects (And What to Fix First)
- Plan Your Budget and Timeline With Real Numbers, Not Guesses
- Sources
What Is the Right ISO 27001 Project Plan Timeline for Your Organization?
The honest answer depends less on company size and more on three things: how much dedicated time your ISMS lead can commit, how much executive backing exists to make fast decisions, and how mature your existing controls already are. Organizations with a 0.5 to 1.0 FTE ISMS lead, a weekly steering meeting, and someone with authority to approve risk treatment on the spot can realistically hit a 90-day certification-ready state. Everyone else should plan for something longer.
A 12-week fast-track only works if you’re not starting from zero. If you already have access controls, a patch management process, and some form of asset inventory, you’re compressing documentation and formalization work, not building security from scratch. That’s a very different project than one where you’re standing up MFA, endpoint protection, and vendor risk management at the same time you’re drafting an information security policy.
The phased structure itself doesn’t change much between a 90-day sprint and a 9-month rollout. You move through the same three stages:
- Foundation — scoping, governance, and gap analysis against ISO 27001:2022 and Annex A
- Development — risk assessment, control mapping, and the Statement of Applicability
- Implementation — deploying controls, training staff, running an internal audit, and prepping for certification
What changes is how much runs in parallel versus in sequence, and how much slack you build in for iteration.
The most common blocker isn’t technical, it’s organizational. Projects stall when nobody owns the risk register, when scope keeps expanding mid-project because someone insists a new business unit needs to be included, or when department heads treat the ISMS as an IT initiative rather than an organizational one. Any of these can turn a tight 90-day plan into a 6-month slog with the same amount of actual work.
Prerequisites and a Planning Checklist Before You Start the Clock
Before you write a single procedure or run a gap analysis, get four things locked down. Skipping this stage is the single most common reason ISO 27001 projects blow their timeline.
- Secure executive sponsorship in writing. A project charter should name the executive sponsor, the ISMS manager, budget authority, and a RACI matrix covering who’s Responsible, Accountable, Consulted, and Informed for each major workstream. Set a steering committee cadence, weekly for a fast-track, biweekly or monthly for a longer rollout.
- Define scope and exclusions explicitly. Write down which business units, locations, systems, and third parties fall inside the ISMS boundary, and just as importantly, which don’t. A vague scope statement is where certification audits go sideways months later.
- Procure the standard and set up your documentation home. Buy ISO 27001:2022 and ISO 27002:2022 directly rather than relying on summaries. Stand up a central repository (SharePoint, Confluence, or a dedicated GRC tool) before you start generating documents, not after.
- Run baseline awareness training for the core team. Everyone touching the project, not just the ISMS manager, needs to understand Annex A structure and what a Statement of Applicability actually is before week one starts.
The minimum technical baseline for a realistic fast-track includes access control policies, some form of logging, a patch cadence, and an asset list, even an incomplete one. If none of that exists yet, a 12-week roadmap isn’t realistic. Plan for 6 to 12 months and treat weeks 1 through 4 as the point where you build that baseline instead of documenting it.
Pro Tip: Buy your documentation repository and access permissions before the kickoff meeting, not during week one. Teams lose entire days to “who can edit this folder” arguments that should never have happened.
Days 1 Through 30: The Foundation Phase, Week by Week
The first 30 days set the trajectory for everything after. Get this phase sloppy and you’ll spend weeks 5 through 12 fixing scope and governance problems instead of building controls.
- Week 1: Kickoff and governance. Hold the formal kickoff, finalize the charter, assign the RACI matrix, set up the document repository, and deliver initial ISO 27001 awareness training to the core project team.
- Week 2: Context and scope. Document the organizational context, identify interested parties (regulators, customers, insurers), draft the formal scope statement, and start a first-pass asset register covering people, systems, and data.
- Week 3: Gap analysis. Run a clause-by-clause assessment against ISO 27001:2022’s management clauses and every Annex A control. A structured, time-boxed gap analysis using a simple Red/Amber/Green score prevents this from turning into an open-ended audit that eats a month by itself.
- Week 4: Policy and executive signoff. Draft the information security policy, define roles and authorities for the ISMS, set measurable security objectives, and get formal executive signoff on all of it.
By day 30, you should have a signed charter, a documented scope statement, a completed gap analysis with RAG-scored findings, and an approved information security policy sitting in your repository. That’s the acceptance bar. If any of those four are missing or still in draft, don’t move into risk assessment yet. Fix the foundation first.
Roadmaps built around a 90-day/12-week structure work for SMEs with dedicated resources and existing baseline controls, but larger or less mature organizations typically need 4 to 12 months to cover the same ground properly. There’s no shame in that longer timeline; rushing a gap analysis to hit an arbitrary 30-day mark just pushes the same unresolved problems into weeks 5 through 8, where they’re harder to fix.
Days 31 Through 60: Risk Assessment, the SoA, and Core Procedures
This phase is where most of the intellectual heavy lifting happens, and where sloppy shortcuts show up hardest during external audit.
Start by designing a risk methodology simple enough that anyone on the team can apply it consistently. A 5x5 likelihood/impact matrix with clearly defined scoring criteria works for most organizations. Overcomplicating this step is a common trap: auditors care less about methodological sophistication and more about whether you applied your own method consistently.
From there:
- Classify assets by sensitivity and business criticality using the register you started in week 2.
- Identify realistic threats and vulnerabilities per asset category, not per individual asset, to keep the register manageable.
- Score each risk against your methodology and decide a treatment option: accept, mitigate, transfer, or avoid.
- Map every treated risk to a specific Annex A control (or a custom control if none fits) and write a one-line justification for every Annex A control you’re excluding.
That mapping exercise produces your Statement of Applicability, which functions as the master index auditors use to trace every decision back to a documented rationale. Designing a documented risk methodology and producing an SoA that maps risks to Annex A controls sits at the center of the entire certification process, not as an afterthought you generate at the end.
Once the SoA is drafted, prioritize procedures for the controls with the highest risk scores first: access control, incident response, and backup/recovery typically top that list. Write each procedure with evidence collection built in from day one. If a procedure says quarterly access reviews happen, the procedure should also specify where the review sign-off gets stored.
Pro Tip: Draft procedures and evidence templates together, not sequentially. A procedure without a matching evidence template is a policy nobody can prove they followed six months later.
Days 61 Through 90: Implementation, Training, and Certification Prep
This is the phase where the ISMS goes from documented to demonstrable. Auditors don’t certify paperwork, they certify evidence that the paperwork reflects reality.
Start implementing controls in the order your risk treatment plan prioritized, and build the evidence trail as you go rather than reconstructing it later:
- Deploy technical and procedural controls from the treatment plan, logging completion dates and owners for each.
- Stand up evidence folders or a GRC tool structured around your SoA, so every control maps to a specific piece of proof.
- Roll out role-based training, general awareness for everyone, deeper technical training for admins and developers, and keep signed attendance records.
- Track training completion against a deadline; incomplete training records are a routine finding in Stage 1 audits.
With controls operating and evidence accumulating, shift to internal audit and management review:
- Define internal audit scope covering every Annex A control claimed in the SoA, not a sample.
- Build an audit plan and schedule, ideally with someone outside the department being audited to preserve independence.
- Log every nonconformity found, assign a corrective action owner, and set a remediation deadline.
- Convene a formal management review with inputs including audit results, risk register status, and objective performance, and document decisions made.
- Assemble the full documentation pack, policies, risk register, SoA, procedures, training records, audit reports, for external auditor review.
Evidence traceability matters more to auditors than polished policy language. A logging policy with three months of actual access review sign-offs behind it will outperform a beautifully written policy with no supporting records every time.
A 12-Week Timeline You Can Copy Into Your Own Plan
Here’s how the three phases break down week by week, with the deliverable each week needs to produce.
| Week | Focus | Key Deliverable |
|---|---|---|
| 1 | Kickoff, charter, RACI, repository setup | Signed project charter |
| 2 | Context, interested parties, scope, asset register (v1) | Documented scope statement |
| 3 | Clause-by-clause gap analysis vs. Annex A | RAG-scored gap analysis report |
| 4 | Policy drafting, roles, objectives, exec signoff | Approved information security policy |
| 5 | Risk methodology design and asset classification | Documented risk methodology |
| 6 | Threat identification and risk scoring | Draft risk register |
| 7 | Risk treatment decisions and control mapping | Draft Statement of Applicability |
| 8 | Procedure drafting for top-priority controls | Access control, incident response procedures |
| 9 | Control implementation and evidence templates | Evidence collection framework live |
| 10 | Training rollout (general and role-based) | Signed training completion records |
| 11 | Internal audit execution | Internal audit report with findings |
| 12 | Management review and documentation pack | Certification-ready evidence package |
Weeks 3, 7, and 11 are the milestone checkpoints worth treating as go/no-go gates. If the gap analysis, SoA draft, or internal audit findings look shaky at any of those points, that’s your signal to add slack before pushing forward rather than after.
What Staffing and Budget Actually Look Like
Most project plans underestimate time commitment because they treat ISO 27001 as a document-writing exercise rather than an operational change. It’s both, and the operational half takes longer.
For a fast-track 12-week project, a realistic staffing model looks like:
- ISMS manager: 50 to 100% of their time for the full 12 weeks; this role can’t be a side project.
- Executive sponsor: 2 to 4 hours a week for steering meetings and rapid risk-treatment decisions.
- IT lead: 25 to 40% of their time, heaviest during weeks 5 through 10 as controls get implemented.
- HR and facilities reps: a few hours a week for training rollout and physical security controls.
- Department representatives: 2 to 5 hours a week each during the gap analysis and risk assessment phases.
Small organizations (under 50 employees) can often run this almost entirely with internal staff plus a part-time consultant for the initial risk methodology and internal audit. Mid-size and larger organizations usually blend internal ownership with an external consultant for the gap analysis and a certified lead auditor for Stage 1 prep, since internal auditors reviewing their own department’s controls creates an independence problem.
Cost drivers to watch: consultant day rates for gap analysis and audit support, the certification body’s audit fees (usually split across Stage 1 and Stage 2), and any tooling costs for a GRC platform. A role-by-role breakdown of ISO 27001 responsibilities is worth reviewing before you finalize headcount assumptions, since underestimating IT lead time is one of the most common budget misses.
Pro Tip: Budget consultant hours separately from internal staff hours in your project plan. Mixing them hides the real cost of external support until the invoice arrives.
How to Accelerate Without Wrecking the Audit
Compression is possible, but only within limits, and every shortcut carries a trade-off worth naming out loud before you take it.
- Time-box the gap analysis to a strict 2 to 3 week window and force RAG prioritization rather than exhaustive documentation of every finding. This is the single highest-leverage compression tactic available.
- Use pre-built SoA templates and control mapping libraries rather than drafting justifications from a blank page for all 93 Annex A controls.
- Run risk assessment and procedure drafting in parallel instead of sequentially, once your risk methodology is locked.
- Use tool-assisted evidence collection (automated log capture, ticketing system exports) instead of manual screenshot compilation.
The trade-off is real: compress too aggressively and you shift audit risk forward, evidence gaps surface at Stage 1 rather than getting caught internally. Heavier reliance on external consultants to hit a tight deadline also raises cost per week even as it shortens the calendar. Treat acceleration as something you earn through existing maturity, not something you force through sheer project management effort.
What I’ve Seen Break ISO 27001 Projects (And What to Fix First)
The projects that stall almost never fail on technical grounds. They fail because evidence is inconsistent, scope quietly expands three weeks in, or nobody can say who actually owns the risk register once the initial excitement of kickoff wears off. I’ve seen teams draft beautiful policies and then discover, two weeks before Stage 1, that nobody kept the training sign-off sheets those policies promised existed.
If you take one prioritization rule from this whole plan, make it this: build SoA traceability and demonstrable control evidence before you polish anything else. A rough policy backed by six months of real access review logs will pass an audit that a flawless policy with no evidence trail won’t. Auditors are trained to pull threads, and an unraveled thread on one control makes them pull harder on the next one.
Before Stage 1, make sure you can hand an auditor these without scrambling: a current SoA with every exclusion justified, a risk register showing treatment decisions and dates, training records matching your policy’s stated cadence, and at least one completed internal audit cycle with closed corrective actions. Everything else in your documentation pack matters less than those four.
— Martin
Plan Your Budget and Timeline With Real Numbers, Not Guesses
Most ISO 27001 project plans fall apart at the budgeting stage, not the execution stage, because leadership approved a timeline based on a generic template instead of numbers specific to your company size, industry, and existing security maturity.
Ismscalculator’s readiness assessment generates a tailored cost and effort estimate in minutes, benchmarked against companies your size and sector, so you’re not defending a 12-week timeline to your CFO with nothing but a blog post as backup. Run a maturity check across all 14 ISO domains, export the resulting schedule as a customizable Gantt chart your steering committee can actually review, and save multiple scenarios if you’re weighing a fast-track against a phased rollout. If you just need a gut-check before committing project resources, the 2-minute readiness check gives executives a fast enough signal to approve a charter without waiting on a full consulting engagement. Start with the readiness assessment, save your estimate, and bring it into your first steering committee meeting as the baseline everyone works from.
Sources
The ISO 27001 implementation roadmap from GLOCERT International lays out the 30/60/90 structure this article builds on, including realistic timeline variances by organization size. Copla’s implementation roadmap guide covers time-boxed gap analysis and RAG scoring in more depth. ISACA’s journal piece on planning and implementing ISO 27001 remains one of the clearer explanations of how risk assessment connects to the SoA. For evidence prep specifically, tekRESCUE’s risk assessment checklist offers a practical eight-step framework worth cross-referencing against your own methodology. If you want a longer view of what a full timeline looks like end to end, Ismscalculator’s own implementation timeline breakdown and 80-step certification checklist are both built to pair directly with the plan above.
- ISO 27001 Implementation Roadmap: 30-60-90 Day & 12-Week Plan
- Planning for and Implementing ISO 27001