---
title: "ISO 27001 implementation: a phased roadmap for growing firms"
canonical: https://www.grcmana.io/vault/iso-27001/implementation
published: 2023-09-06
updated: 2026-10-20
author: "Harry West"
framework: "ISO 27001"
control: "Guide ISO 27001 implementation"
journeyStage: implementation
---

# ISO 27001 implementation: a phased roadmap for growing firms

## Key takeaways

ISO 27001 implementation is the work of building an information security management system that meets ISO/IEC 27001:2022 and runs as part of the business. For a 25–250-person firm it breaks into five phases, from scope and leadership to internal audit and management review. The order matters more than the speed, because each phase produces the inputs the next one needs.

- **Five phases** — Scope and leadership, risk assessment and the Statement of Applicability, controls and documentation, operating and measuring, then internal audit, management review and the certification audit.
- **Where it starts** — With context, stakeholders and a written scope under Clauses 4.1 to 4.3, plus visible leadership ownership under Clause 5.1. Every later phase depends on that boundary.
- **What decides controls** — The risk assessment and treatment decisions under Clause 6.1, recorded in the Statement of Applicability. Annex A is checked against those decisions, never used as the starting list.
- **Before certification** — The ISMS must have run long enough to produce records: metrics with history, a completed internal audit and a minuted management review with owned actions.

You have been handed [ISO 27001](https://www.grcmana.io/vault/iso-27001) alongside your day job. A customer wants the certificate, the board wants a date, and the standard reads like it was written for a company ten times your size. ISO 27001 implementation does not need to stall the business while it happens.

This guide is for founders, security leads and the people who inherited compliance at 25–250-person firms. It sets out a five-phase roadmap, maps each phase to the clauses it satisfies, and shows where implementations usually stall and how to build an ISMS that keeps running after the certificate arrives.

## How long does ISO 27001 implementation take?

For a 25–250-person firm starting from a low baseline, ISO 27001 implementation usually takes six to twelve months before a certification audit. The work itself is measured in weeks. The elapsed time comes from the ISMS needing to run long enough to produce records: metrics with history, a completed internal audit and a minuted management review.

That distinction changes how you plan. Most of the effort is front-loaded into the first two phases, where decisions about scope, risk and controls are made. The later phases are lighter in effort but cannot be compressed, because an auditor wants to see the system operating over time.

Three factors move the timeline more than headcount does:

- **Starting maturity.** A firm already running access reviews, change control and backups has evidence on day one. A firm without them builds the habit first, then the record.
- **Leadership time.** Decisions on scope, risk appetite and budget sit with top management. When they wait for a board meeting, the project waits too.
- **Scope breadth.** More entities, sites and services mean more owners to interview, more risks to assess and more controls to evidence.

If you do not yet know your starting point, run a [gap analysis](https://www.grcmana.io/vault/iso-27001/gap-analysis) first. It turns "how long will this take?" into a scored list of what is missing.

## What are the phases of an ISO 27001 implementation?

ISO 27001 implementation runs in five phases. Set the scope and leadership ownership, assess and treat risk, build the controls and documentation, operate and measure the system, then audit, review and certify. Each phase maps to specific clauses of ISO/IEC 27001:2022 and produces the inputs the next phase needs, so the order is not optional.

The [ISO committee page for ISO/IEC 27001](https://committee.iso.org/isoiec-27001-information-security.html) describes the standard as the requirements for an information security management system that protects confidentiality, integrity and availability by applying a risk management process.

The phases below are that process, sequenced for a firm without a dedicated security department.

| Phase | Clauses | Main outputs | Indicative effort at 50 people |
| --- | --- | --- | --- |
| 1 Scope and leadership | 4.1, 4.2, 4.3, 5.1 | Context record, stakeholder register, approved scope, leadership agenda slot and budget line | Two to three weeks |
| 2 Risk assessment and SoA | 6.1.2, 6.1.3, 8.2 | Risk method, risk register, treatment decisions, Statement of Applicability | Two to four weeks |
| 3 Controls and documentation | 8.3, Annex A, 7.5 | Implemented controls, treatment evidence, controlled policies and procedures | Six to twelve weeks |
| 4 Operate and measure | 9.1, 7.3 | Metric set with thresholds, awareness programme, accumulating records | Ongoing, two to three months of history |
| 5 Audit, review and certify | 9.2, 9.3, 10.2 | Internal audit report, management review minutes, corrective actions, certification audit | Four to eight weeks before Stage 1 |

The effort figures are working estimates for a firm of around 50 people, not requirements of the standard. They assume the scope is mostly one organisation and that someone owns the project with protected time each week.

### Phase 1: Scope and leadership

Phase 1 decides what the ISMS covers and who owns it. Start with a short leadership workshop on context under [Clause 4.1](https://www.grcmana.io/vault/iso-27001/clause-4-1-context-of-the-organisation): the regulations that bite, what clients now demand, how the company actually runs, and the shortcuts it carries. Half a day is enough at this scale, provided legal, operations and people leads attend as well as IT.

Then build the stakeholder register under [Clause 4.2](https://www.grcmana.io/vault/iso-27001/clause-4-2-understanding-the-needs-and-expectations-of-interested-parties). Contracts are the richest source here. The security schedule in your largest client's agreement is often the most demanding document you are subject to.

Context and stakeholders together decide the boundary. Write the scope under [Clause 4.3](https://www.grcmana.io/vault/iso-27001/clause-4-3-determining-the-scope-of-the-information-security-management-system) around the service your clients buy and the data that flows through it.

Leadership ownership under [Clause 5.1](https://www.grcmana.io/vault/iso-27001/clause-5-1-leadership-and-commitment) is the last piece of phase 1, and the one that keeps every later phase funded. Four artefacts make it real:

1. A standing security item on the leadership agenda, minuted.
2. A small set of objectives leadership actually chose, in business terms.
3. An accountability matrix that names people, including executives.
4. A security budget line justified by risk.

A policy signed by someone who cannot explain it is not leadership commitment. It is a signature.

### Phase 2: Risk assessment and the Statement of Applicability

Phase 2 turns context into decisions. Write the risk methodology before assessing anything, as [Clause 6.1](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) expects. A five-by-five likelihood and impact grid is plenty if each score is anchored in real consequences: pounds, hours of downtime, clients lost. State which scores you will tolerate and which force action.

Build the assessment on an asset inventory, as [Annex A 5.9](https://www.grcmana.io/vault/iso-27001/annex-a-5-9-inventory-of-information-and-other-associated-assets) requires: systems, data sets, key suppliers, sites and the people who hold critical knowledge. Frame each risk as a concrete scenario with a named owner senior enough to fund the treatment.

Treatment comes next. Risk treatment is the decision about what to do with each risk that scores above your acceptance line, and the work that decision creates. ISO 27001 does not prescribe the options. It requires a recorded, reasoned choice for every such risk, approved by the named risk owner along with the exposure that remains afterwards.

Practitioners group the choices into four options:

| Option | Also called | What it means | Example | What the auditor wants to see |
| --- | --- | --- | --- | --- |
| Reduce | Treat, or modify | Apply controls that lower the likelihood or impact until the risk sits within your acceptance line | Multi-factor authentication and least-privilege access to cut the risk of account takeover | The controls in the Statement of Applicability and treatment plan, and a lower re-scored risk |
| Accept | Tolerate, or retain | Keep the risk as it is, knowingly, because it is within your appetite or treating it would cost more than the harm | A short outage of an internal wiki | The risk owner's recorded sign-off, with a date to review it |
| Avoid | Terminate | Stop or change the activity that creates the risk | Dropping a planned feature that would have stored customer card data | Evidence the activity stopped or was redesigned |
| Transfer | Share | Move part of the financial or operational impact to another party, through insurance or a contract | Cyber insurance, or a managed security service with responsibilities set out in the contract | The policy or contract, and someone who can explain what it does and does not cover |

One risk can take more than one option. Most are reduced with controls first, and the exposure that remains, called residual risk, is then accepted. That residual risk still needs the owner's signature.

Transfer moves the bill, not the risk.

Derive the control set from those choices first. Only then check the full Annex A list of 93 controls as a sweep, recording why each one is needed or not. Our [Annex A controls guide](https://www.grcmana.io/vault/iso-27001/annex-a-controls) explains the themes and how the Statement of Applicability records those decisions.

Starting from Annex A instead of from risk is how small firms end up building controls no risk asked for.

Finally, agree when the assessment runs again. [Clause 8.2](https://www.grcmana.io/vault/iso-27001/clause-8-2-information-security-risk-assessment) expects it at planned intervals and on significant change, so write the trigger list now: a platform migration, a new customer-facing service, an acquisition, a serious incident.

### Phase 3: Controls and documentation

Phase 3 is where most of the elapsed time goes. Execute the treatment plan under [Clause 8.3](https://www.grcmana.io/vault/iso-27001/clause-8-3-information-security-risk-treatment) in the systems, not in the documents. Enforce multi-factor authentication and least-privilege access, run the patching workflow, close penetration test findings. The configuration is the treatment; the policy describing it is not.

Give every plan line a named owner, a budget and a date, then re-score the risk once the work is done. The before-and-after score is what shows the treatment worked.

Documentation follows the controls, not the other way round. Write each policy or procedure once the practice it describes exists, keep it short, and put it under version control with an owner and a review date. Our guide to [ISO 27001 mandatory documents](https://www.grcmana.io/vault/iso-27001/documents) lists what the clauses require. [Clause 7.5](https://www.grcmana.io/vault/iso-27001/clause-7-5-documented-information) covers how to control those documents.

Capture evidence as the work happens: tickets, configuration exports, decommissioning records. Evidence reconstructed in the month before an audit reads as exactly that.

### Phase 4: Operate and measure

Phase 4 proves the system works. Under [Clause 9.1](https://www.grcmana.io/vault/iso-27001/clause-9-1-monitoring-measurement-analysis-and-evaluation), choose eight to twelve metrics by risk, not by what your tools happen to export. Cover both technical health, such as patch currency and endpoint coverage, and process health, such as incident response times and training completion.

A starter set for a 50-person software firm might look like this. The thresholds are examples to tune to your own risk appetite, not targets the standard sets.

| Metric | Risk it tracks | Example threshold | Typical source |
| --- | --- | --- | --- |
| Critical and high vulnerabilities patched on time | Exploitation of known weaknesses | 95% within 14 days | Vulnerability scanner |
| Devices running a healthy endpoint agent | Malware on unmanaged laptops | 100%, gaps closed within 48 hours | Endpoint console against the asset inventory |
| Accounts with multi-factor authentication enforced | Account takeover | 100%, including admin accounts | Identity provider |
| Leavers whose access was removed within one working day | Former staff keeping access | 100% | HR system against the identity provider |
| Access reviews completed on schedule | Privileges building up over time | 100% each quarter | Identity provider or ticketing |
| Successful test restores of critical systems | Data loss after an outage or attack | One per critical system each quarter, all passing | Backup tool |
| Time from incident report to containment | Incidents spreading before anyone acts | Critical incidents contained within four hours | Ticketing |
| Security training completed on time | Mistakes by untrained staff | 95% | Training platform |
| Staff reporting simulated phishing emails | Successful phishing | Report rate above click rate, trending up | Phishing simulation tool |
| Critical suppliers reviewed on schedule | Compromise through a supplier | 100% each year | Supplier register |

Every metric should trace to a risk or an objective. If its owner cannot say why a number is tracked, drop it.

Give every metric a threshold and wire breaches to action. A below-target number should open a corrective action with an owner. A red number on a dashboard that never becomes a task is decoration.

Run awareness under [Clause 7.3](https://www.grcmana.io/vault/iso-27001/clause-7-3-awareness) in parallel, and start it early. Induction before access is granted, periodic refreshers and role-specific content for finance, engineering and the executive team all generate the records an auditor will sample. Behaviour trends only exist once you have been measuring for a while.

Phase 4 has no shortcut. It is the phase where the ISMS stops being a project and starts being how the business runs.

### Phase 5: Internal audit, management review and certification

Phase 5 checks the system before an external auditor does. Plan the first internal audit under [Clause 9.2](https://www.grcmana.io/vault/iso-27001/clause-9-2-internal-audit) once clauses 4 to 8 have produced records worth sampling. The auditor must be independent of what they examine, so pair functions to audit each other or bring in an external practitioner.

Then hold a [management review under Clause 9.3](https://www.grcmana.io/vault/iso-27001/clause-9-3-management-review). Leadership weighs the required inputs, including metrics, audit results and changes in context, and records decisions with named owners and dates. Findings from the internal audit and the review feed [corrective action under Clause 10.2](https://www.grcmana.io/vault/iso-27001/clause-10-2-nonconformity-and-corrective-action), which closes each issue only when the fix is verified.

With one cycle complete, you are ready to book the certification audit. Our guide to the [ISO 27001 certification process](https://www.grcmana.io/vault/iso-27001/certification-process) covers choosing a certification body, Stage 1 and Stage 2, and what happens after the certificate is issued.

## Who needs to be involved in an ISO 27001 implementation?

An ISO 27001 implementation needs a named project owner, visible top management, and the heads of every function the scope touches: engineering, operations, HR, finance and legal. Security cannot be implemented by IT alone, because clauses 4 to 7 describe how the business governs itself, not how its servers are configured.

At 25–250 people, one person usually owns the project and spends part of each week on it. Everyone else contributes in short, scheduled bursts. A simple responsibility table keeps those bursts predictable:

| Role | Responsible for | Typical time commitment |
| --- | --- | --- |
| Top management (CEO or MD) | Scope approval, risk appetite, budget, management review decisions | A standing agenda slot, plus sign-offs |
| Project owner (security or compliance lead) | Plan, risk method, Statement of Applicability, evidence, internal audit programme | Part of each week throughout |
| Engineering and operations leads | Technical controls, change, backups, access, monitoring metrics | Workshops, then control ownership |
| HR | Screening, onboarding and leavers, awareness records, disciplinary process | Workshops, then process ownership |
| Finance and procurement | Supplier register, contract security terms, budget tracking | Workshops, then supplier reviews |
| Legal or company secretary | Regulatory and contractual obligations, stakeholder register | Phase 1, then annual review |

Name people, not teams. A control owned by "the IT team" is a control nobody owns, and auditors treat it that way.

## Where do ISO 27001 implementations stall?

ISO 27001 implementations usually stall at the same few points: leadership attention fading after the kick-off, a risk assessment that never connects to controls, documentation written ahead of practice, and a long gap between building the system and running it. Each one is avoidable if you know to look for it.

The common stall points, and what keeps the project moving past each:

- **Leadership drift.** Engagement peaks at kick-off and fades. A recurring agenda item with decisions minuted keeps it alive.
- **Risk register without consequence.** Risks get scored, then nothing changes. Every above-the-line risk should trace to a treatment decision and a plan line with a date.
- **Policies before practice.** A full policy set written in week two describes a company that does not exist yet. Write each one when the practice is real.
- **Tool-first thinking.** A platform bought before the method exists becomes an expensive document store.
- **The quiet middle.** Controls are built, then nobody measures them for three months. Start metrics and awareness as soon as the first controls are live.
- **Audit week heroics.** Evidence gathered in a rush the week before Stage 1 is visible in its timestamps.

Buying a GRC platform before the risk assessment automates a decision you haven't made.

## How do you build an ISMS that runs itself?

Build the ISMS so that evidence is a by-product of normal work, not a separate task. Pull control evidence straight from the systems that generate it: identity provider, ticketing, CI pipeline, cloud accounts. Then monitor it continuously, so drift shows up in days rather than at the next audit. Your people stay focused on judgement: risk decisions, exceptions and improvement.

This is what we mean by GRC Engineering. The manual version of ISO 27001 asks someone to screenshot an access review every quarter. The engineered version runs the review from the identity provider, records the result automatically and flags only the exceptions for a human to decide.

Three habits make the difference at 25–250 people:

1. **Instrument what already runs.** Most evidence exists somewhere: tickets, logs, configuration exports. Connect to it instead of recreating it.
2. **Treat change as a trigger.** A new cloud account, supplier or service opens a scope, risk and control review automatically. Continuous monitoring under [Annex A 8.16](https://www.grcmana.io/vault/iso-27001/annex-a-8-16-monitoring-activities) gives the same discipline to your technical estate.
3. **Report trends, not exports.** Leadership needs ten metrics with a narrative at management review, not a hundred-row spreadsheet.

The [NCSC's risk management guidance](https://www.ncsc.gov.uk/collection/10-steps/risk-management) makes a related point. Boards need the information to make risk decisions in a form they understand, and policies they approve and own. An engineered ISMS delivers that from its own records.

An ISMS that exists only in the weeks before an audit is a performance, not a system.

The payoff is commercial as well as operational. When a customer's security questionnaire arrives, the answers and evidence are already current, and the certificate becomes a record of how you work rather than a project you survived.

## Frequently asked questions

### Can you do ISO 27001 implementation without a consultant?

Yes. The standard does not require outside help, and a capable internal owner with protected time can deliver it. Consultants earn their place by shortening the learning curve on risk methodology, Statement of Applicability reasoning and audit expectations. The one role that must sit apart from the work is the internal auditor, who cannot audit their own areas.

### How much does ISO 27001 implementation cost?

Cost depends on scope, starting maturity and how much external support you use, alongside certification body fees that scale with headcount. Internal time is usually the largest line and the one most often left out of budgets. Our guide to [ISO 27001 certification cost](https://www.grcmana.io/vault/iso-27001/certification-cost) breaks down each line for UK firms.

### Can we implement ISO 27001 and SOC 2 at the same time?

Yes, and one control set can serve both if you design for it. Build the ISMS on ISO 27001's risk-based structure, then map SOC 2's criteria onto the same controls and evidence. The main extra work is SOC 2's observation period and its report format, not a second set of controls.

### Do we need software to implement ISO 27001?

No. The standard is tool-neutral, and many small firms reach certification with a ticketing system, a document store and a well-kept spreadsheet. Tooling pays off once the method is settled and you want evidence collected automatically. Buy it to run a process you have already defined, not to define the process for you.

### What happens after the certificate is issued?

The ISMS keeps running. Certification bodies run surveillance audits during the certificate's life and a recertification audit at the end of the cycle, so metrics, internal audits and management reviews continue on their planned schedule. Treat the certificate date as the end of phase 5's first cycle, not the end of the project.