ISO 27001 implementation: a phased roadmap for growing firms

You have been handed 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 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 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.

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: 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. 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 around the service your clients buy and the data that flows through it.

Leadership ownership under Clause 5.1 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 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 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:

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 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 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 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 lists what the clauses require. Clause 7.5 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, 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.

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 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 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. 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, 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 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:

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 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 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