True story.
A security manager I trained last year told me this: he’d been with his company for three months. His predecessor left. The handover was a shared drive. Inside it: 200 documents, a risk register from 2022, an information security policy that referenced GDPR but not ISO27001, and a Statement of Applicability with another company’s name still in the footer.
His boss said: “We’re up for recertification in six months. You’re leading it.”
He smiled. He nodded. He went home and started updating his LinkedIn.
If you’ve been anywhere near an ISO27001 implementation, some version of this story probably sounds familiar. Maybe you didn’t inherit a mess. Maybe you’re building from scratch. But the feeling is the same: the standard tells you what needs to exist. It never tells you how to build it.
This article is about that gap. And how to close it.
The document everybody pretends to understand
ISO/IEC 27001:2022 is 30 pages long. It’s beautifully structured. Clauses 4 through 10, Annex A, 93 controls, 34 mandatory subclauses. It reads like a clear set of instructions.
Until you try to follow them.
“The organisation shall determine external and internal issues that are relevant to its purpose.” Great. What does that look like in practice? A workshop? A PESTLE analysis? A conversation with the CEO over coffee? The standard doesn’t say.
“The organisation shall define and apply an information security risk assessment process.” Perfect. Qualitative or quantitative? Three-point scale or five? How do you define “likely” so that IT and finance agree? How do you make sure the risk owner column doesn’t just say “Dave” for everything? The standard doesn’t say.
“The organisation shall produce a Statement of Applicability.” Brilliant. But what makes a good SoA? How detailed should the justifications be? What counts as evidence of implementation? How do you stop it from becoming a 93-row spreadsheet of “Yes, implemented” with nothing behind it? The standard absolutely does not say.
This isn’t a flaw. ISO27001 is deliberately technology-neutral, sector-neutral, and size-neutral. It has to be. But that neutrality creates a gap between the people who understand the standard and the people who can actually implement it. And that gap is where careers stall, projects fail, and audits go sideways.
Five ways I’ve seen ISO 27001 implementations die
I’ve been a CISO for long enough to have seen the same mistakes over and over. Not because people are bad at their jobs. Because nobody taught them the methodology.
- The risk register that’s really a spreadsheet of opinions.
Everyone sits in a room. Someone says “ransomware” and everyone nods. Likelihood: high. Impact: high. Risk owner: IT. Next risk. Repeat for three hours. The result is a list of things people are worried about, scored by gut feeling, with no documented methodology behind it. The auditor asks “how did you define your impact scale?” and the room goes quiet.
- The SoA that was copied from the internet.
I’m not making this up. I’ve reviewed Statements of Applicability where the justification column says “implemented” for every single control, the evidence column is blank, and the document properties still show the original author from a completely different company. Your SoA is the auditor’s first stop. If it’s a copy-paste job, the audit is over before it started.
- The ISMS that lives in a SharePoint folder and nowhere else.
Policies nobody has read. Procedures nobody follows. An asset inventory that’s missing two departments. A management review that happened once, eighteen months ago, and was never followed up. This is paper compliance. It ticks boxes on a spreadsheet but falls apart the moment someone asks: “show me this working in practice.”
- The audit that catches everyone off guard.
Stage 1 is documentation review. Stage 2 is operational evidence. Most teams prepare for one and panic at the other. They’ve got beautiful documents but can’t demonstrate the controls are running. Or they’ve got working controls but can’t produce the evidence trail. The auditor doesn’t care which gap you have, both are nonconformities.
- The board that thinks ISO 27001 is a firewall.
You ask for budget. The CFO says “we already bought the firewall.” You try to explain that ISO 27001 is a management system, not a technology purchase. The CFO checks their phone. This is a leadership buy-in failure, and it kills more implementations than any technical gap ever will.
What actually works
Every successful ISO 27001 implementation I’ve been part of has the same ingredients. Not magic. Just methodology.
A clear scope with a documented justification. Not “everything” with no explanation. Not artificially narrow to avoid complexity. A scope that makes sense for the organisation, with boundaries that can be explained to an auditor in two minutes.
A risk assessment methodology that’s repeatable and defensible. Defined scales. Calibrated criteria. Clear distinction between threats, vulnerabilities, and risks. Owners who actually understand what they own. Documentation that an auditor can follow without you standing next to them explaining it.
An SoA that tells a story. Not a checkbox exercise. Each control has a justification that connects back to the risk assessment. Exclusions are explained, not left blank. Evidence of implementation is referenced, not assumed.
Leadership that understands what they’re signing off on. Management reviews that produce decisions, not just minutes. A security policy that the CEO has actually read. Resource allocation that reflects the scope of the ISMS, not just the IT budget.
Audit preparation that starts on Day 1, not the week before. Every document, every record, every process designed from the start to produce evidence. Because if you can’t prove it happened, it didn’t happen.
That’s what the 5 days are for
May 11 to 15. Online. In English. A live cohort, capped at 6 participants, built around the implementation methodology I use in real projects.
This isn’t a walk-through of the standard. You can read the standard yourself. This is the operating system that sits behind it: how to initiate the project, how to structure the risk assessment, how to write the SoA, how to select and deploy controls, how to set up monitoring and measurement, how to prepare for the certification audit, all of it, step by step, with exercises and case studies at every stage.
DayFocusMondayISO 27001 in context. Initiating the implementation. Understanding the organisation, its context, interested parties. Defining and justifying the ISMS scope.TuesdayGetting leadership buy-in. Analysing what you already have. Writing the security policy. Building the risk assessment methodology. The Statement of Applicability.WednesdaySelecting and designing Annex A controls. Deploying controls that fit. Documentation management. Communication, competence, awareness. Running security operations.ThursdayMonitoring and measurement. Internal audit. Management review. Handling nonconformities. Continual improvement. Preparing for Stage 1 and Stage 2.
By Friday, you walk out with a methodology you can use the following week, and a credential that proves it.
Who teaches this
Me. Christophe. Active CISO, founder of Cyber Academy.
I don’t teach ISO 27001 because I read a book about it. I teach it because I implement it. When I talk about risk assessment, it’s because I’ve sat in rooms and facilitated them. When I talk about audit preparation, it’s because I’ve prepared organisations for Stage 1 and Stage 2 and watched what the auditor actually does. When someone in the course says “my risk register is a disaster,” I don’t give them a theory answer. I give them what I’d do if I were sitting in their chair on Monday.
That’s the difference between training and a slide deck.
The guarantee
Complete the course. Sit the exam. If you don’t pass, we refund your training fee.
No conditions beyond completing the programme and taking the exam. No fine print. We call it Certified or Refunded, and we mean it.
Why? Because the methodology works. The pass rate proves it. And if you’re investing a week of your time and your company’s money, you deserve to know that the provider is betting on the same outcome you are.
The details
Course: ISO/IEC 27001:2022 Lead Implementer, PECB Certified
Dates: May 11–15, 2026
Format: Live online. Interactive. Not recorded.
Language: English
CPD: 31 credits
Free retake: Within 12 months
Your move
If you’re in the middle of an implementation and you’re stuck, this is the course that unsticks you.
If you’ve been asked to lead a project and you don’t have a methodology, this gives you one.
If you’re a consultant and you need the credential to back up what you already know, this gets you certified.
If you inherited a SharePoint folder and a prayer, this is your five-day rescue plan.
Questions? Email me directly. No sales team. No chatbot. Just me.
Christophe