Reality Check
Start from what’s real, and you will be protecting the business. Start from the framework, and you will be protecting a picture of the business that fits the frame.
You are in a kickoff meeting for an ISO 27001 implementation — a mid-size software company, about 80 people, with an experienced consultancy guiding the certification.
The consultant opens with: “Let’s start by going through the Annex A controls and identifying which ones apply to your organisation.”
Ninety-three controls. One by one. For each: does this apply? Yes, no, justification if no. The team — the CTO, a dev team lead, and a project manager who’s been in the role for three weeks — spends four hours working through a checklist of requirements they’ve never seen before, trying to map abstract control descriptions to their specific environment.
By lunchtime they’ve covered about forty controls and everyone is glazed. The project manager is taking notes they don’t fully understand. The CTO keeps asking “but what does this actually mean for us?” and getting answers framed in ISO language that doesn’t really connect to their world.
Nobody has asked: what does your company really do?
Not in the polite, perfunctory way that opens so many consulting engagements. In the genuine, operational way: what services do you provide? What data flows through your systems? Who are your customers, and what do they depend on you for? What would actually hurt if something went wrong?
These questions aren’t skipped because the consultant is incompetent. They’re skipped because the methodology starts from the framework. And when you start from the framework, you start from someone else’s model of what matters. You spend your first day mapping abstract requirements to your reality, rather than understanding your reality and then identifying which requirements are relevant.
This is how many security programmes begin. It’s backwards.
Start from what’s true
The alternative starts with a different question: what’s actually true about your organisation?
Don’t treat this as the warm-up before the real work of implementing controls. This is the real work. Everything that follows — which risks matter, which controls to implement, how much effort to invest, what to evidence — flows from your answer to this question. Skip it, or rush through it, and the rest of the programme is built on someone else’s assumptions about what matters.
Get it right, and the programme stops feeling like an external obligation and starts reading like a description of how you protect what matters — often the same controls, with a completely different relationship to them.
Asking the right questions
Here are the questions to ask at the start of every security programme:
What do you actually do? Not your mission statement — your operations. What services do you provide, and who depends on them? What data flows through your systems? A SaaS platform, a consulting firm, and a manufacturer will answer in completely different ways; that’s the point.
What do you depend on? The systems that would stop the business if they went down, the vendors you couldn’t operate without, the places your data actually lives — both the cloud accounts and the laptops nobody lists.
What would actually hurt? Not the theoretical confidentiality, integrity, and availability risks, but the real ones. If your customer database was exposed tomorrow, what happens? If the vendor holding it disappeared overnight, how quickly could you recover?
Who has access to what? The actual access that org charts don’t capture: who can reach production, who can see customer data, who still has admin rights from a role they left behind.
These questions might appear simple, but answering them meaningfully is surprisingly hard, because many organisations haven’t thought about themselves this way. They know what they do — of course they do. But they haven’t mapped the operational reality in a way that connects to security decisions. The CTO knows the tech stack. Finance knows the vendor contracts. HR knows the org chart. The security programme needs all of it, connected, and nobody has assembled that picture before.
That assembly is the work. It produces the foundation that makes everything else proportionate, connected, and reality-based.
Why context changes everything
Let me make this concrete using a single security control: access reviews.
A framework says you should periodically review who has access to your systems. But how you implement that control depends entirely on your context.
If you’re a 20-person startup where three developers have access to production, a quarterly access review is a 15-minute conversation. You know everyone. You know what they do. The review is practically automatic.
If you’re a 200-person company with dozens of systems, multiple teams, and staff turnover, the same control is a different exercise altogether. Systems have different risk profiles. The production database with customer data needs a rigorous quarterly review; the design-asset library can wait for the annual pass. The staging environment? Somewhere in between.
Without that context — which systems hold what data, who depends on them, what the business impact of unauthorised access would be — you can’t make these distinctions. You either apply the same depth everywhere (expensive, and most of the effort is wasted on low-risk systems) or you guess (dangerous, because you’ll inevitably under-invest somewhere that matters).
Context is what turns a generic control into a proportionate one. “Review access” becomes “review access to these specific systems, at this frequency, with this depth, because this is what’s at stake.” That’s a different sentence, and it produces a different outcome.
This is also the starting point for everything the second half of the book builds on: you can’t give people clarity about their security tasks without context, you can’t give meaningful feedback about whether controls are working without knowing what they’re protecting, and you can’t invest proportionately without understanding which assets carry the most risk. Context first. Everything else follows.
This is true for every control. Vulnerability management means something different when your main asset is an internet-facing application handling user data versus an internal tool used by five people. Incident response means something different when you’re subject to GDPR’s 72-hour notification requirement and NIS2’s 24-hour early warning versus when you have no regulatory reporting obligations. Business continuity means something different when your revenue depends on a single SaaS platform versus when you have a redundant infrastructure.
The framework can’t tell you these things. Only your context can. Until you’ve captured that context, every control implementation is a guess — educated, perhaps, but a guess.
Security objectives before framework selection
This will sound like heresy to some in the compliance industry: the framework should come second.
Many programmes start with: “We need ISO 27001” or “We need SOC 2” or “NIS2 applies to us.” The framework becomes the organising principle. Every activity is oriented around satisfying its requirements. The scope is defined by what the framework demands. The controls are selected from its catalogue. The evidence is structured around its audit expectations.
This produces a certificate and a programme shaped like the framework rather than shaped like the business. It also creates the fragmentation problem from Chapter 4: when you add a second framework, you’re building a second programme rather than applying a second lens to the same reality.
The alternative: start from your security objectives. What does the business need the security programme to achieve?
These objectives aren’t abstract. They’re specific:
- Protect customer data from unauthorised access and exposure.
- Ensure critical services can recover from disruption within four hours.
- Meet the security requirements of enterprise customers.
- Reduce the risk of a material security incident that would damage customer trust or trigger regulatory action.
- Comply with NIS2 reporting obligations before enforcement begins.
These are business objectives with security implications, not framework requirements with business justifications bolted on. They come from conversations with the business — the CEO, the CTO, the head of sales, the head of product — not from conversations with the auditor.
Once you have them, the framework becomes what it was designed to be: a structured way of addressing your objectives. ISO 27001 helps you organise your controls. NIS2 tells you what the regulator expects. SOC 2 gives your customers a standardised way to evaluate your programme. These are useful lenses. But they’re lenses you apply to your reality, not templates you force your reality into.
This is how you make the compliance-driven versus reality-driven distinction operational. The former produces formal compliance. The latter builds security that includes compliance.
The asset-first approach
Practically, starting from reality means starting from your assets — your services, your data, your infrastructure, your vendors. Not because assets are more important than risks or controls, but because assets are the thing everyone in the organisation already understands. Your CTO knows the stack. Your ops team knows the infrastructure. Your finance team knows what you’re paying for. Start from what they can tell you.
Watch the exercise play out at a SaaS platform of about 60 people. Ask the CTO to list every system the business depends on. They produce a list of twelve. Reasonable: the main application, the database, the CI/CD pipeline, the cloud accounts, the email system, the internal tools, and so on.
Then ask the head of operations to do the same. They produce a list of nineteen. Seven of them weren’t on the CTO’s list — because they’re SaaS tools that operations uses daily and engineering never set up. A recruitment platform with employee personal data. A customer support tool with access to production logs. An analytics service that ingests customer behavioural data and sends it to a third party engineering has never heard of.
Then map the data flows. The customer support tool has an integration that syncs ticket data — including customer email addresses and sometimes screenshots of their accounts — to a shared Slack channel. The analytics service is forwarding data to a subprocessor in a jurisdiction that complicates their GDPR obligations. An intern set up a project management tool six months earlier with SSO disabled, and half the company has accounts with reused passwords.
Nothing here is malicious, or even unusual — just tools, integrations, and workarounds accumulating faster than anyone tracked them. But until someone asks “what do we actually depend on?” and follows the data flows, nobody has seen the full picture. The CTO’s twelve-system model of the company is accurate for engineering. It’s dangerously incomplete for security.
This is why starting from assets matters: it reveals what no checklist would surface. A framework asks “do you manage third-party risk?” — a question you can answer with a policy. The inventory just showed you third-party risk nobody knew you had.
Here is one more reason many organisations don’t do it, or do it superficially: because asking “what would actually hurt?” requires admitting vulnerability. It requires the CTO to say “I don’t know what ops is running.” It requires the compliance manager to say “we have data flows we’ve never assessed.” It requires the business to name the things that could break, which means acknowledging that they’re breakable. Many security conversations are structured to avoid exactly that admission. The framework checklist feels safer — it asks whether you’ve done things, not whether you understand what you’re protecting. Starting from reality means sitting with the discomfort of not having the complete picture, and building it honestly from there.
From this inventory — however incomplete at first — the security programme builds naturally. Risks attach to assets; controls to risks; requirements and evidence to controls. This is the connected model that Chapter 6 builds on. But it starts here, with knowing what you have and what matters.
The same meeting, a different question
Now imagine the same meeting from the opening — the CTO, the dev team lead, the project manager who’s been in the role for three weeks — but a different opening question.
“Before we look at any framework, tell me about your business. What does your platform actually do? Who are your customers, and what do they depend on you for?”
The CTO leans forward. This they know. They talk for ten minutes about the product, the architecture, the customer base. The project manager is taking notes they understand, because it’s about the company they work for, not about a standard they’ve never read.
“Now — what data flows through that platform? Where does it come from, where does it go, who can see it?”
The team lead walks to a whiteboard. The data flows reveal two vendor dependencies nobody had thought about from a security perspective. The CTO frowns — nobody had told them customer data was being forwarded to the analytics subprocessor.
“What would hurt most if it broke? If the platform was down for a day, what happens? If customer data was exposed, who do you have to tell?”
Now they’re talking about business impact. The project manager asks about GDPR notification timelines. The CTO starts connecting the architecture to the regulatory obligations. For the first time, the security conversation is about their company.
By lunchtime, they haven’t looked at a single Annex A control. But they know what they’re protecting, what they depend on, what would hurt, and who has access to what. When they do open the framework the next day, every control maps to something they recognise. The programme is already theirs.
Start from reality, and you build controls proportionate to actual risk. Start from a framework, and you build controls to tick boxes next to its requirements list. One of these produces a working security programme for the business.
What to do Monday morning
Have the “what do we actually do?” conversation with someone outside the security team. Your CTO, your head of product, your ops lead. Not about security — about the business. What services do we provide? What do customers depend on us for? What data flows through our systems? What would hurt most if it broke? Write down the answers. You’ve just started your security programme from reality rather than from a framework.
List your top five assets by business impact, not by security category. Not “our firewall, our SIEM, our DLP” — those are security tools. “Our customer database, our payment processing service, our production platform, our client portal, our primary cloud account.” The assets that would damage the business if they were compromised or unavailable. If your current asset register doesn’t have these at the top, it’s organised around the wrong priority.
Write three security objectives in business language. Not “implement ISO 27001 Annex A controls” — that’s a method, not an objective. “Protect customer data from exposure,” “ensure we can recover critical services within four hours,” “meet the security requirements of enterprise buyers.” Show them to your CEO. If they don’t recognise the objectives as things the business cares about, rewrite them until they do.