How to Build an ISO 27001 Roadmap in 2026 — Including AI and Emerging Threats

Let me be honest with you. Most ISO 27001 roadmaps you find online look like they were written by someone who has never actually been through a certification audit. They make it sound clean and linear. It is not. There are weeks where nothing moves, stakeholders who go quiet, and an internal audit that always surfaces something uncomfortable right before the external one.

What follows is a roadmap built from reality — not theory. And because it is 2026, it also accounts for something most older guides completely ignore: what to do about AI systems sitting inside your environment when the auditor walks in.

Phase 1 — Figure Out What You Are Actually Protecting

Before you write a single policy, you need an honest picture of your information assets. Not the polished version that goes in the board deck — the real one. Where does sensitive data actually live? Who genuinely has access to it? What happens to the business if it walks out the door?

In 2026 this exercise almost always surfaces something uncomfortable: AI tools that staff have been quietly using for months, cloud services that nobody formally approved, third-party integrations that process customer data in ways nobody fully mapped. These are not edge cases anymore. They are the norm. Your asset register needs to include them or your scope will have holes before you even start.

Phase 2 — Define Your Scope Carefully

Scope is one of the most consequential decisions in the whole project and it gets rushed more often than any other step. Too narrow and the certificate means nothing to your customers. Too broad and you have taken on a project that will consume your team for two years.

The honest advice is to start with what matters most to the business and what your customers or regulators actually care about. Then get leadership to sign off on it in writing. ISO 27001 Clause 5 requires top management commitment and auditors will test it — not just ask about it. If your CISO cannot point to a document with the CEO’s name on it, that is already a finding waiting to happen.

Phase 3 — The Risk Assessment Is the Whole Point

Everything in ISO 27001 flows from the risk assessment. The controls you implement, the policies you write, the procedures you document — all of it should trace back to a risk you identified here. If a control cannot be linked to a risk, you should be asking why you are implementing it.

Your threat landscape in 2026 is different from what it was three years ago. Ransomware is more targeted. Supply chain attacks have become routine. And AI systems — whether you built them or bought them — introduce a category of risk that most organisations have not formally assessed yet. Data sent to external model APIs, automated decisions made without human review, staff using AI writing tools on confidential documents — these need to be in the register.

The output is a risk register with likelihood and impact scores, and a treatment plan that maps each risk to an Annex A control decision: apply, accept, avoid or transfer. This document is what your auditor will want to see more than almost anything else.

Phase 4 — Build Documentation That Actually Reflects Reality

This is where most projects slow down. Writing policies is not technically hard. Writing policies that accurately describe how your organisation actually operates — and that an auditor can verify through evidence — is genuinely difficult.

The mandatory documentation set under ISO 27001:2022 includes your Information Security Policy, Risk Assessment Methodology, Statement of Applicability, and records of monitoring, audit and management review. Beyond that you will need operational policies covering access control, incident management, supplier security, business continuity, cryptography and physical security at minimum.

The trap most teams fall into is downloading generic templates and filling in the company name. Auditors have seen thousands of those documents. They know exactly what a copied template looks like and they will ask questions your generic policy cannot answer. The documentation needs to reflect your actual environment — your systems, your processes, your people.

Phase 5 — Implement Controls and Train Your Team

Documentation without evidence of implementation fails certification. Access reviews need to be happening on a defined schedule with records to show it. Incidents need to be logged, reviewed and fed back into the risk register. Supplier assessments need to be conducted, not just planned. Backups need to be tested, not just configured.

Security awareness training has shifted too. Staff in 2026 need to understand more than phishing and password hygiene. They need to know what the rules are around using AI tools with company data, how to recognise social engineering that uses AI-generated content, and what to do when something feels wrong even if they cannot articulate why. A training programme that has not been updated in three years will not reflect the threat environment your auditor is thinking about.

Phase 6 — Internal Audit Before the Real One

Running a proper internal audit before your certification audit is not a box-ticking exercise. It is the best chance you have to find your own gaps before someone else does. The internal audit needs to cover all applicable Annex A controls and Clauses 4 through 10, and it needs to be conducted by someone with enough independence to call things out honestly.

The findings from the internal audit feed into management review — where leadership formally looks at the performance of the ISMS and decides what needs to change. Both need documented records. If you walk into a Stage 1 audit without these, you will not make it to Stage 2.

Phase 7 — The Certification Audit Itself

Stage 1 is a documentation review. The auditor checks that your ISMS is properly documented, scoped and in place. Stage 2 is where the real assessment happens — evidence reviews, staff interviews, process walkthroughs. They will ask your IT team about access controls. They will ask your HR team about onboarding. They will ask someone in finance how they handle information security incidents.

Nonconformities raised during Stage 2 need to be addressed before certification is granted. The more complete and evidence-backed your documentation going in, the fewer findings you receive coming out.

How Long Will This Actually Take?

For a small to mid-size organisation implementing for the first time, a realistic timeline from project kick-off to certification is six to twelve months. Organisations with existing security programmes and mature documentation can move faster. Those starting from scratch should plan for the longer end and build in buffer — because something always takes longer than expected.

The most common reason projects overrun is documentation. Not because people do not know what to write — but because writing good documentation while also running a security programme is genuinely hard to do at the same time. Having a complete, well-structured documentation set on day one is the single biggest thing that compresses the timeline.

Start With a Foundation That Is Already Built

The GRCadia ISO 27001 Toolkit gives you the complete documentation foundation — risk assessment workbook, Statement of Applicability, ISMS manual, internal audit workbook, policies pack and implementation roadmap — all aligned with ISO 27001:2022 and built to customise to your environment.

It will not do the implementation work for you. But it will eliminate the months spent building documentation from scratch — so your team can spend that time on the controls, the evidence and the audit readiness that actually gets you certified.

Explore the ISO 27001 Toolkit →