Part 1: Before the Walls Go Up
You've been given the task. Get us certified. ISO 27001. Someone heard it's required for a tender, or a client asked about it, or the board decided it's time to take security seriously. Either way, it's now your problem.
You're not a security specialist. You might be the IT lead, the operations manager, or the founder who handles everything that doesn't have a clear owner yet. You've inherited a spreadsheet someone started, maybe a template downloaded from somewhere. There's a lot of talk about controls and policies and audits. It feels like you're supposed to already know how this works.
Here's what most guides won't tell you: the controls and policies come later. The real foundation of your management system is set in the first four steps, before any of that. Get these right, and everything else has something solid to stand on. Rush through them, and you'll spend months building on sand.
Think of it like establishing a base camp before building a fortress. You're not constructing walls yet. You're choosing the ground, understanding the terrain, figuring out what you're protecting and from what. Skip this, and you'll end up with impressive-looking defences in the wrong place.
These four steps are: getting management support, defining your scope, understanding your context, and identifying your risks. None of them are glamorous. All of them matter.
Part 2: The Four Moves
Move 1: Get Management Support
This sounds like a formality. Get the CEO to sign something. Tick the box. Move on.
It's not. Management support means the leadership team actually understands why you're doing this, what it will require, and what it will cost in time and attention. Not just money — though there's that too — but genuine organisational focus.
The business case isn't complicated. Maybe you need the certificate to compete for contracts. Maybe a key client has started asking questions about your security posture. Maybe you've grown to the point where informal practices aren't enough anymore. Whatever the reason, leadership needs to own it, not just approve it.
What this looks like in practice: a conversation, not a signature. Can your CEO explain in one sentence why you're pursuing certification? If not, you haven't finished this step.
The Socratic difference: Instead of drafting a business case and hoping it gets read, you work through the questions together. What are we trying to protect? What happens if we don't? What does success look like? The answers become the foundation, not a document filed away.
Move 2: Define Your Scope
Scope is simply: what's in, and what's out.
ISO 27001 doesn't require you to certify your entire organisation. You can certify a specific business unit, a particular service, a defined set of processes. For a 15-person company, you might certify everything. For a larger organisation, you might start with one division.
The temptation is to go too broad (and drown in complexity) or too narrow (and miss the point). A good scope is one you can actually manage, that covers what your clients and stakeholders actually care about.
What this looks like in practice: a clear statement of what's included. Which teams, which systems, which locations, which processes. Written plainly enough that anyone could read it and understand what's covered.
The Socratic difference: Instead of copying a scope statement template, you answer the real questions. What do our customers expect us to protect? Where does sensitive information actually live? What would an auditor expect to see included? The scope emerges from the answers.
Move 3: Understand Your Context
Context is everything that shapes your security situation. Internal factors: your structure, your culture, your capabilities. External factors: your industry, your regulations, your threats.
This is where most organisations lose the thread. The standard asks for things like a SWOT analysis, a stakeholder register, an understanding of legal requirements. These sound like bureaucratic exercises, and they often become exactly that — documents created to satisfy a requirement, then never looked at again.
But context is genuinely useful. Knowing who your stakeholders are (clients, regulators, partners, employees) tells you whose expectations you need to meet. Knowing your legal landscape (GDPR, sector-specific regulations, contractual obligations) tells you where the hard boundaries are. Knowing your strengths and weaknesses tells you where to focus.
What this looks like in practice: a clear picture of the world you're operating in. Not exhaustive, but accurate. If someone asked "who do you need to keep happy, and what rules do you have to follow?" you could answer without checking a document.
The Socratic difference: This is where automation genuinely helps. AI can gather public information about your industry, your regulatory environment, your typical threat landscape. It can identify stakeholders you might have missed, surface legal requirements you weren't aware of. But then it asks: does this apply to you? What's missing? Which of these stakeholders actually matters? The research is automated. The judgement stays human.
Move 4: Identify Your Risks
Now you know what you're protecting (scope), for whom (stakeholders), within what constraints (legal and regulatory context). The next question: what could go wrong?
Risk identification isn't about listing every possible bad thing. It's about understanding what matters for your specific situation. A data breach means something different for a healthcare provider than for a design agency. A system outage means something different if you're running critical infrastructure versus selling software.
For each risk, you'll eventually assess probability and impact, decide on treatment, assign ownership. But that comes later. The first step is simply: what are the risks that matter here?
What this looks like in practice: a list of risks that anyone in your organisation would recognise as real. Not abstract categories copied from a framework, but actual threats to the things you're trying to protect.
The Socratic difference: Instead of generating a risk register from a template and hoping it's relevant, you build it through questions. What would hurt us most? What's happened to companies like ours? What keeps you up at night? The risks that emerge are ones you understand, because you thought through them yourself.
Part 3: From Tent to Encampment
When these four steps are done well, you have something. Not a fortress yet — that comes with controls and policies and continuous improvement — but a solid encampment. Ground you understand. A perimeter you can explain. A clear view of what you're defending against.
The risk register isn't just a spreadsheet; it's a tool you built and can use. The scope isn't just a statement; it's a decision you made for reasons you can articulate. The context isn't just a document; it's your understanding of the world you operate in.
This is what makes the difference between compliance that lives and compliance that's performed. Between a management system people actually use and one that sits in a folder until audit season.
The test is simple: can you explain it? If someone asked why you chose this scope, who your key stakeholders are, what your top five risks are — could you answer without looking anything up? If yes, you've built a foundation. If no, you've built documentation.
What Comes Next
These four moves get you to base camp. From here, you start building: controls to address your risks, policies to guide behaviour, processes to keep everything running. The certification journey continues.
But everything that follows stands on what you've built here. A control is only as good as the risk it addresses. A policy is only as useful as the context it's designed for. Rushing the foundation doesn't save time. It costs you understanding.
And understanding, in the end, is what makes the difference between an organisation that's genuinely secure and one that just has the certificate.