True story.
A guy I trained last autumn was a security manager at a mid-sized company in the Netherlands. Smart. Diligent. Had his Foundation certification. Had read ISO 27001 cover to cover. Multiple times. He could explain what Clause 6 required. He could list the four categories of Annex A controls from memory. He could draw the Plan-Do-Check-Act cycle on a whiteboard with his eyes closed.
His company decided to get certified. His manager said: "You know the standard. You lead it."
And then he sat down at his desk on a Monday morning and realised he had absolutely no idea what to do first.
Not because he was incompetent. Because the standard had never told him. It told him what needed to exist. It never told him how to build any of it.
Three months in, he still wasn't sure his scoping was right. The risk assessment methodology had been rewritten twice because nobody could agree on what "likely" meant. The SoA was half-filled and he didn't trust any of it. He'd made progress, but it was the kind of progress where you're moving without knowing if you're moving in the right direction.
By the time he came to my course, he'd been at it for the better part of a year. Not because the work was too hard. Because he'd been doing it without a methodology.
If any part of that sounds familiar, this article is for you.
The standard is not an instruction manual. It was never supposed to be.
This is the thing nobody says out loud: ISO 27001 is deliberately incomplete.
That is not a criticism. It is the design. The standard has to work for a five-person startup and a fifty-thousand-person bank. It has to work across every industry, every jurisdiction, every technology stack. The only way to do that is to specify what needs to exist without specifying how to build it. That generality is what makes it powerful. It is also what makes it useless as a step-by-step guide.
"The organisation shall determine external and internal issues that are relevant to its purpose." How? Workshop? PESTLE? Interviews? Napkin sketch over coffee? The standard doesn't say, because the answer depends on whether you're a hospital, a SaaS company, or a law firm.
"The organisation shall define and apply an information security risk assessment process." Great. But what does that process look like? What methodology? What scales? How do you calibrate so that the word "high" means the same thing to the legal department and the SOC team? The standard doesn't say.
"The organisation shall produce a Statement of Applicability." Fine. But what makes a good SoA? How granular should the justifications be? What counts as evidence of implementation? Is a policy enough, or does the auditor want logs? The standard absolutely does not say.
People who understand the standard but can't implement it are not missing intelligence. They are missing methodology. And that is not a failure of the person. It is a gap the standard was never designed to fill.
Five decisions the standard leaves entirely to you
I've implemented ISO 27001 in over a hundred organisations. These five decisions are where every implementation either finds its footing or loses months.
How to scope it. Most people think scoping is easy. Define what's in, define what's out, move on. Then they spend three months arguing about it. Should the development environment be in scope? What about that subsidiary that shares the same Active Directory? What about the offshore support team that accesses production data? Every scoping decision has downstream consequences for risk, controls, and audit. The standard says "determine the scope." It does not tell you how to navigate these trade-offs, or how to write a scope statement an auditor will accept in thirty seconds instead of spending two hours picking apart.
How to assess risk. This is where the most time gets wasted. Not doing the assessment, but designing the methodology. I have reviewed risk registers where the entire likelihood column says "medium." Where the impact column has five levels but nobody can explain the difference between a three and a four. Where the same risk is scored differently by two teams sitting in adjacent rooms because nobody calibrated the scales. The standard says "apply a risk assessment process." It does not tell you how to build a methodology that's repeatable, defensible, and doesn't collapse the first time the auditor asks "why is this a three and not a four?"
How to write the SoA. The Statement of Applicability is the most important document in your ISMS and the most commonly botched. I have reviewed SoAs where every control is marked "implemented" with no evidence. Where the justification column says "see policy" for ninety-three rows. Where the document properties show it was last edited by someone at a completely different company because it was downloaded from the internet and the names were never changed. The auditor reads your SoA first. If it falls apart, nothing else saves you.
How to make leadership care. Clause 5 says top management shall demonstrate leadership and commitment. In practice, this means you need to get your board to allocate budget, attend management reviews, and sign off on risk acceptance decisions. The standard says "leadership shall." It does not tell you how to walk into a board meeting and explain why the company needs to spend money on something that has no visible ROI until the day something goes wrong. That is a communication problem, not a security problem, and most implementations fail here, not at the technical layer.
How to prepare for the audit. Stage 1 is documentation review. Stage 2 is operational evidence. Most people prepare for one and panic at the other. They build beautiful documents and then can't demonstrate the controls are actually running. Or they have working controls and can't produce the evidence trail. The standard says "prepare for the certification audit." It does not tell you what the auditor opens first, what questions come in the first hour, or what trips people up every single time. I know, because I've been on both sides of that table.
What methodology actually means
When I say this course teaches you the methodology, I don't mean you get a checklist. I mean you learn the operating system that sits behind the standard.
A methodology tells you what to do first, and why. It tells you how to run the scoping workshop so it takes a day, not a quarter. It gives you a risk assessment framework you can defend, not just fill in. It shows you what a good SoA looks like and what makes a bad one obvious. It teaches you how to present security to a board that doesn't care about security, in language that makes them care. And it tells you what the auditor is going to do, in what order, so you can prepare for it instead of surviving it.
That is the difference between knowing the standard and being able to implement it. And it is the difference between a six-month project that succeeds and a twelve-month project that produces a filing cabinet full of documents nobody uses.
That's what the 5 days are for
August 17 to 21. Monday to Friday. Live online, in English. A cohort capped at six people, because at seven the conversation dies and the exercises become performative.
| Day | What you learn |
|---|---|
| Monday | ISO 27001 in context. How the standard is built and where it fits alongside NIS 2, DORA, GDPR. How to initiate the implementation project. How to understand your organisation's context. How to scope the ISMS so it holds up under scrutiny. |
| Tuesday | How to get leadership buy-in. How to analyse what you already have. How to write a security policy that means something. How to build the risk assessment methodology. How to write the Statement of Applicability. |
| Wednesday | How to select controls from Annex A based on actual risk, not copy-paste. How to implement them. How to manage documentation without drowning. How to build competence and awareness across the organisation. |
| Thursday | How to monitor and measure your ISMS. How to run internal audits. How to run management reviews that produce decisions. How to handle nonconformities. How to prepare for Stage 1 and Stage 2 so you walk in ready, not hopeful. |
| Friday | PECB certification exam. Three hours. Open-book. Scenario-based. You've been building towards this all week. |
Every line in that table starts with "how." That's deliberate. The "what" is in the standard. You can read it for free. The "how" is what you're paying for.
Who teaches this
Me. Christophe. Active CISO, founder of Cyber Academy, PECB Gold Trainer.
I don't teach implementation from a textbook. I teach it from the job. When I explain risk assessment methodology, it's because I've built risk frameworks and then sat across from an auditor who tried to take them apart. When I explain how to get leadership buy-in, it's because I've stood in front of boards who didn't want to hear it and found a way to make them listen. When someone in the course says "my SoA is a disaster," I don't give them the exam answer. I tell them what I'd do if I were sitting at their desk on Monday, because I've sat at that desk.
Two hundred audits. A hundred implementations. The war stories in this course are mine. That matters, because the gap between the standard and reality is not theoretical. It's operational. And you learn to close it from someone who closes it for a living.
The guarantee
Complete the course. Sit the exam. If you don't pass, we refund your training fee.
No fine print beyond completing the programme and taking the exam. We call it Certified or Refunded, and we mean it. 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 a provider betting on the same outcome you are.
The details
- Course: ISO/IEC 27001:2022 Lead Implementer, PECB Certified
- Dates: August 17–21, 2026
- Format: Live online. Interactive. Not recorded.
- Language: English
- Cohort size: 3 to 6 participants
- Exam: 3-hour PECB exam on Day 5, open-book
- Materials: 450+ pages included
- CPD: 31 credits
- Free retake: Within 12 months
- Price: €2,499
- Guarantee: Certified or Refunded
Your move
If you've read the standard and you still don't know what to do on Monday morning, this is the course that closes that gap.
If you've been handed an implementation project and you've been Googling "ISO 27001 risk assessment template" at midnight, this gives you the methodology so you never have to Google it again.
If you're a consultant and your clients expect you to lead this end-to-end, this is where you stop improvising and start knowing.
If you're eight months into a project that should have taken four, this is your five-day reset.
Reserve your spot below.
Questions? Email me directly. No sales team. No chatbot. Just me.
Christophe Founder & Trainer, Cyber Academy | Become the Code Father cyberacademy.net