Two Days with ISO 27001: A Practitioner's Training Review
I completed ISO/IEC 27001 information security management training in 2024, paired with an internal auditing certification. I had lived with the standard in practice for years. Two days of formal instruction still managed to teach me things — mostly about the gaps between how I'd been thinking about it and how the standard actually works.
The Setup
By the time I attended the ISO/IEC 27001 information security management training in 2024, I had spent several years working with the standard in practice — first building an ISMS at Vincit, then driving ISO 27001 compliance at Visma. I knew the structure. I could recite the clauses. I had written more risk assessment documentation than I care to count.
So why bother with a two-day training? Two reasons. First: formal instruction has a way of surfacing the things you have quietly gotten wrong. When you learn a standard by doing it, you fill in the gaps with educated guesses. Some of those guesses are wrong, and you don't find out until someone asks a question you can't answer cleanly. Two days of structured teaching was a chance to audit my own understanding. Second: the internal auditing certification that came with it was genuinely useful in a new way. I'd commissioned audits. I hadn't formally run one.
Day One: The Standard Itself
The first day covers the ISO 27001 framework proper — the structure, the clauses, and the logic connecting them. For anyone with implementation experience, roughly the first half of the day is review: the Plan-Do-Check-Act cycle, the relationship between the standard and its companion ISO 27002 (controls guidance), the scoping decisions that precede everything else.
Where it got more interesting was the treatment of Annex A. The 2022 revision reorganised the 114 controls of the 2013 version into 93 controls across four themes: organisational, people, physical, and technological. This is more than a cosmetic change. Several controls were merged, a handful were added (notably covering cloud services and threat intelligence), and the framing shifted subtly from "controls you implement" toward "controls you consider and document your reasoning about." The Statement of Applicability is still the key document, but the 2022 version pushes harder on the "why not" justification for exclusions than the 2013 version did.
I had been working against a 2013-era ISMS. The trainer walked through the delta carefully, and I came away with a concrete list of things to revisit — particularly around the new controls for secure coding (A.8.28, covering exactly the practices our development teams were already following but hadn't formally mapped) and cloud service management (A.5.23, which we had addressed partially but not systematically).
Risk Assessment: Where Everyone Has Opinions
The risk assessment methodology session generated the most discussion in the room, which is predictable — ISO 27001 is famously agnostic about how you do risk assessment, requiring only that you apply a consistent methodology. The standard doesn't tell you whether to use a 3×3 or 5×5 likelihood/impact matrix, whether to score inherent or residual risk first, or how to handle risks that span multiple assets. Every organisation that implements ISO 27001 makes these choices and then has strong feelings about them.
The training's approach was to present a reference methodology and then be explicit that it was one valid choice among several. This was honest and useful. What I hadn't fully appreciated before: the standard requires you to define risk acceptance criteria, meaning the threshold below which you accept a residual risk without further treatment. In practice I had seen this treated as a formality — organisations pick a number and write it down without much thought about whether that number reflects actual risk appetite. The trainer made a point I found genuinely clarifying: your risk acceptance criteria should be derivable from your business context, not from what produces a clean-looking risk register. If you're processing health data, your criteria should reflect that. If you're a small SaaS company processing no sensitive data, they should reflect that instead.
Day Two: Internal Auditing
The second day shifted to the auditing certification. The internal auditing course covers audit planning, evidence gathering, nonconformity classification, and reporting. It's structured around the ISO 19011 guidelines for auditing management systems.
The most useful part for me was the nonconformity framework. ISO 27001 auditors distinguish between major and minor nonconformities and observations. A major nonconformity indicates a systematic failure — a required clause is not being addressed, or a control is absent entirely. A minor nonconformity is a gap in implementation that doesn't undermine the ISMS as a whole. An observation is a weakness that doesn't (yet) rise to nonconformity. These distinctions matter because they determine the corrective action requirements and, in a certification audit, whether certification is granted or withheld.
What I had been doing in practice was calling things "findings" and leaving it to whoever read the report to assess severity. Adopting the formal classification changes how you write audit reports — and, more importantly, how conversations with auditees go. Telling a team lead "this is a minor nonconformity, here's why, here's the corrective action timeline" lands differently than "here's a finding." The vocabulary carries weight.
Evidence Collection in Practice
The auditing section also covered evidence collection techniques: document review, interviews, observation, and sampling. Sampling was handled more rigorously than I expected for a two-day course. Statistical sampling versus judgement sampling, sample sizes relative to population sizes, and the risk of drawing conclusions from unrepresentative samples — these are things that matter when you're auditing, say, whether access reviews are being conducted for all systems, but that most practitioners handwave past.
The interview technique guidance was practical. Good audit interviews are not interrogations; they're structured conversations designed to surface evidence of either conformance or gap. The trainer walked through interview question structures: open questions to elicit process descriptions, closed questions to confirm specific facts, and probing questions to follow up on inconsistencies. I had been doing this intuitively. Seeing it written down as a technique made it easier to train others on.
What Was Actually New
Honest accounting: roughly 60% of the two days was confirmation of things I already knew. The remaining 40% broke down roughly as follows:
- The 2022 Annex A reorganisation and its implications for existing ISMSs (significant)
- The formal nonconformity classification framework for audits (immediately applicable)
- The risk acceptance criteria discussion (reshaped how I think about a document I'd been writing by habit)
- The sampling methodology for audit evidence (useful for planning future audits)
- The ISO 19011 audit process structure, particularly the audit programme concept — the idea that individual audits sit within a multi-year programme with defined objectives, scope, and resources (something we'd been doing informally without the framework)
That 40% is worth two days. The 60% review wasn't wasted time either — there's a difference between knowing something well enough to implement it and knowing it well enough to teach it or defend it to an external auditor.
The Credential Question
The certifications from these two days — ISO/IEC 27001 Information Security Management and Internal Security Auditing — are not the same kind of signal as, say, CISSP or ISO 27001 Lead Implementer. They're course completion certificates, not examination-based credentials. Anyone who attends the training gets them.
I don't think this makes them worthless. The credential signals that you've sat through a structured treatment of the material, which is a different claim from "I've been doing this for years." In procurement contexts and client conversations, having the formal certificate alongside the practical experience is more useful than either alone. The certificate answers "have you been formally trained on this standard?" The experience answers "have you actually applied it?"
The credential is not the point. The point is the gap between what you thought you knew and what you knew precisely. Two days of formal instruction is a cost-effective way to find out which is which.
Who Should Attend
The training is worth it for anyone who has been implementing or working with ISO 27001 informally and wants to formalise their understanding — particularly around the 2022 revision if their ISMS was built against the 2013 standard. It's also worth it for engineering leaders who will be participating in certification audits as auditees: understanding what auditors are looking for and how nonconformities are classified changes how you prepare and how you respond during the audit itself.
For someone with no prior exposure to the standard, two days is probably not enough. The formal ISO 27001 Lead Implementer or Lead Auditor courses run five days for good reason. The two-day format assumes you're filling in gaps and formalising experience, not building from zero.
For someone who has been living with the standard in practice: yes, the two days are worth it. The 40% that's new is worth more than 40% of two days.