ISO 27001 scenario planning means building two or three versions of your implementation plan, each with different assumptions about scope, starting maturity, staffing and timeline, then comparing them before you commit budget. The standard does not require it by name. But it asks you to plan, resource and reassess your ISMS, and scenarios are the practical way to do that when leadership wants numbers.
This guide shows how to build those scenarios, which variables move the result most, and how to turn the comparison into a plan your executives can approve.
TL;DR
- Build at least three scenarios (lean scope, expected scope, full scope) and change one variable at a time so you can see what drives effort.
- The variables that matter most are scope boundary, starting maturity, team size and ownership, and how much outside help you buy.
- Anchor every scenario in the Plan-Do-Check-Act cycle so each one includes the operate, audit and improve phases, not just the build.
- Treat a scenario as a living document: reassess it as gaps are closed and assumptions change.
- A free 2-minute readiness check gives you a starting maturity input before you model anything.
Table of Contents
- What scenario planning means for an ISMS
- Start from the PDCA cycle
- The five variables that change the plan
- How size and industry shift the scenarios
- Build the scenarios step by step
- Use scenarios to prepare for the audit
- Keep the plan alive
- Our perspective
- Run your scenarios in the calculator
- FAQ
- Sources
What scenario planning means for an ISMS
Most ISO 27001 plans start as a single line in a budget: one number, one date. That works until someone asks what happens if the scope doubles, if the security lead leaves, or if the audit finds more gaps than expected. A scenario plan answers those questions before they become surprises.
A scenario is a coherent set of assumptions and the plan that follows from them. It is not a forecast. Each one should state:
- the scope boundary (which products, sites, teams and suppliers are inside the ISMS),
- the starting maturity (what controls and documentation already exist),
- who does the work and how many hours they can give it,
- what you buy from outside (consultant time, tooling, testing, training),
- the target dates for the certification audit and for the first surveillance cycle.
The output of each scenario is the same three things: effort in hours, cost in dollars, and elapsed time. Comparing them side by side is the whole exercise.
Start from the PDCA cycle
ISO 27001 is built on the Plan-Do-Check-Act cycle. According to NQA’s implementation guide, Plan sets objectives, resources and risks, Do carries out the plan, Check monitors performance against policies and objectives, and Act improves performance. The same guide describes the cycle as applying both to the system as a whole and to each element, forming an upward spiral rather than a loop.
ISACA’s 2024 journal article on the 2022 transition maps the same model to the ISMS: planning and establishment, implementation and operation, monitoring and review, maintenance and improvement. It also notes that clauses 4 through 10 cannot be left out if you want to claim conformity.
Why this matters for scenarios: a plan that budgets only for the “Do” phase is the most common way estimates fall short. Every scenario should carry line items for all four stages, including internal audit, management review and the corrective actions that follow.
| PDCA stage | What your scenario should include |
|---|---|
| Plan | Scope decision, risk assessment, statement of applicability, objectives, resourcing |
| Do | Control implementation, policies, training, supplier work, evidence collection |
| Check | Internal audit, monitoring, management review, metrics |
| Act | Corrective actions, improvements, re-scoping, surveillance audit preparation |
The five variables that change the plan
You can model dozens of inputs, but five do most of the work. Change them one at a time.
1. Scope boundary
Scope is the biggest lever. A single SaaS product run by one engineering team is a very different project from an entire company with several offices and a mix of in-house and outsourced systems. Clause 4.3 of the standard asks you to take internal and external issues and interested parties into account when setting scope, along with the interfaces to anything outside it.
In practice, write down the people, locations, systems, data types and suppliers that touch the in-scope service. Then build one scenario with a narrow scope (the core product only) and one with a wider scope (adding corporate IT, HR or a second business line). The gap between them shows you what each extension costs in hours.
2. Starting maturity
A team with documented access control, regular risk reviews and an incident process starts far ahead of one that handles all of this informally. ISACA lists the readiness gaps it sees most often: missing or informal security policy, inconsistent access control, irregular or incomplete risk assessments, thin documentation of procedures, no formal incident response plan, and insufficient training.
Score yourself honestly against each of those six areas. Every “no” becomes a work item with hours attached, and the count of work items is what separates an optimistic scenario from a realistic one. Our Annex A controls explainer walks through the control themes so you can score each one.
3. Team and ownership
The same work takes a very different calendar time depending on who does it and how much of their week it takes. Model at least two staffing options: a part-time owner with support from IT and HR, and a dedicated lead. Spell out which roles carry which tasks. Our guide to IT team roles in ISO 27001 is a useful template for the split.
4. Outside support
Consultant help, a gap analysis, penetration testing and training are the usual external line items. A scenario that assumes you do everything yourself will show lower cost and a longer timeline. One that buys help for the risk assessment and internal audit will show the reverse. Both are valid; the point is to see the trade.
5. Timeline pressure
Sometimes a customer contract or a procurement questionnaire sets the date. Build a scenario that works backward from that date and see what has to give: scope, outside help, or the number of people assigned. Our pages on the implementation timeline and the certification timeline show how the phases usually stack up.
How size and industry shift the scenarios
Company size changes the shape of the project more than its length. A 20-person startup usually has little documentation to rework but also few people to spread the work across, so one person often owns everything. A larger organization has more systems, more suppliers and more approval layers, so scope definition and evidence collection take longer even when the team is bigger.
Industry changes which risks and which customer expectations dominate. A SaaS company will usually focus on secure development, cloud configuration and customer data handling; our guide for SaaS and tech companies covers that setting. A financial services firm tends to carry more supplier oversight, stricter evidence expectations and more layers of review, which we cover in the audit prep guide for finance companies.
Two practical consequences for your scenarios:
- Add a supplier-risk line to any scenario where third parties process in-scope data. It is a recurring source of audit findings.
- Compare your numbers with model reference comparisons rather than a generic average. A figure that looks high for a startup may be ordinary for a regulated firm.
Build the scenarios step by step
- Take a baseline. Run a readiness check against the four Annex A control themes or the Annex A themes. Record what exists, what is partial and what is missing.
- Define the scope options. Write a narrow, a expected and a wide boundary in plain sentences, with the systems, sites, teams and suppliers each includes.
- Identify the gaps per option. For each scope, list the gap items. The ISO 27001:2022 Annex A has 93 controls in four themes, and your statement of applicability records which apply and how far each is implemented. Controls marked partial or not implemented become your remediation list.
- Link gaps to risk decisions. Each gap ties to a risk and a treatment: implement a control, accept the risk, transfer it, or avoid the activity. Scenarios often differ in which of those treatments you choose, which is a legitimate lever on cost.
- Attach effort and cost. Give each work item hours, an owner, any outside cost and a dependency. Sum by phase.
- Lay it on a timeline. Place the phases on a Gantt view so overlaps and bottlenecks show. Two scenarios with the same total hours can differ by months if the same person owns the critical path.
- Compare and choose. Put the scenarios in one table and pick one, with its assumptions written down.
- Schedule the reassessment. Decide when you will rerun the scenario, for example after the risk assessment and after the internal audit.
A worked comparison
The numbers below are placeholders to show the layout, not benchmarks. Replace them with your own.
| Lean scope | Expected scope | Full scope | |
|---|---|---|---|
| Boundary | Core product and its hosting | Product plus corporate IT | Whole company, all sites |
| Gap items | Fewest | Moderate | Most |
| Owner | Part-time lead | Part-time lead plus IT support | Dedicated lead |
| Outside help | Gap analysis only | Gap analysis and internal audit | Full consultant support |
| Main risk | Customers ask for wider scope later | Competing priorities for IT | Longest timeline |
The value is not in any single cell. It is that the table makes the trade-offs visible, so the decision becomes about scope and risk rather than about a lone budget number.
Use scenarios to prepare for the audit
Scenario planning is also a good way to stress-test audit readiness. Ask, for each scenario, what evidence would exist on audit day. Racert’s 2026 guidance on nonconformities groups the usual findings into a few themes: policies that do not match actual practice, incomplete risk assessments or missing treatment plans, inconsistent controls, low awareness, weak monitoring and unmanaged suppliers. Each theme becomes a question in your plan: who owns it, where is the evidence, and when was it last reviewed?
We cover what auditors ask in our auditor questions guide and the patterns behind failed audits in common audit failures. For technology teams that lean on contractors or outsourced engineering, the procurement and security checklist for data security outsourcing is a helpful companion when you assess supplier risk.
When the risk assessment itself is the weak spot, it also helps to look at risks beyond the server room. Physical access, premises and people can all feed the register, and a physical security risk assessment guide shows one way to structure that review.
Keep the plan alive
A scenario plan that sits in a folder stops being useful within a quarter. ISACA recommends a phased approach with defined tasks, responsibilities and timelines, accessible to all stakeholders, with flexibility built in and regular reassessment as circumstances change. That is exactly what scenario planning supports:
- Revisit the chosen scenario after each phase gate.
- Record which assumptions turned out wrong and why.
- Keep earlier versions so you can show how and why the plan moved.
- Feed what you learn into the Check and Act stages of the cycle.
The final point matters for auditors too. A documented, reviewed plan is evidence that management is actually running the system.
Our perspective
We built ISMS Calculator because a single cost figure for ISO 27001 hides everything a decision-maker needs to see. The useful question is not how much it costs, but how much it costs under which assumptions.
That is why our estimates are real-time, organization-specific and editable. You choose company size, industry and security maturity, change an assumption, and watch effort and cost move. The methodology is traceable and versioned, so you can challenge any figure rather than accept it on trust.
We also think scenarios belong on a timeline. Saving several estimates, comparing them and laying the phases out in a customizable Gantt view turns a debate about numbers into a decision about scope, staffing and dates.
Start with the initial calculation, which needs no signup, then refine it as your gap picture sharpens.
Martin
Run your scenarios in the calculator
If you would rather not build the model in a spreadsheet, our ISO 27001 cost calculator produces tailored estimates from your company size, industry and security maturity, with model reference comparisons to check them against. You can save and compare multiple estimates, export a PDF report, share a link with colleagues and view multi-currency figures.
Not sure where you start? Take the free 2-minute check for an instant read, or go deeper with the ISO 27001 readiness assessment across the four Annex A control themes. Our methodology page explains how the estimates are built. When you are ready for outside help, you can also request an introduction to an independent ISO 27001 consultant.
FAQ
How many scenarios should I build?
Three is a good number: a lean, an expected and a full-scope version. Fewer gives you no real comparison, and more usually adds noise. Change one variable at a time so you can tell which assumption drives the difference.
Is scenario planning required by ISO 27001?
The standard does not use the term. It does require you to plan, determine resources, set scope and review the ISMS, as the PDCA structure and clauses 4 through 10 make clear. Scenarios are a practical way to document those decisions and show management involvement.
What should I model first?
Scope and starting maturity. Those two inputs change the number of gap items, which in turn drive hours, outside help and elapsed time. Do a quick readiness check before you open the budget conversation.
When should I rerun my scenarios?
After the risk assessment, after the statement of applicability is drafted and after the internal audit. Each step replaces assumptions with facts, and the plan should follow. Also rerun when scope, team or target dates change.
Sources
- NQA, ISO 27001:2022 Information Security Implementation Guide
- ISACA Journal 2024, Navigating the ISO/IEC 27001:2022 Transition