Everything Connects
Security parts don’t exist in isolation. When you build a programme that understands the connections between them, the impossible becomes manageable.
It’s 9:15 on a Tuesday morning and you’ve just seen the news. One of your cloud providers has disclosed a data breach. Customer data may have been exposed. Details are still emerging, but the news mentions “unauthorised access to customer account metadata.”
Your CEO wants to know if you’re affected. Your biggest client’s security team has sent an email asking for a statement. Your DPO wants to know if this triggers a GDPR notification obligation.
You need to answer three questions, fast:
- Which of our systems run on this provider?
- What data do those systems process?
- What are our contractual and regulatory obligations if that data was exposed?
At many organisations, answering these questions takes hours. Sometimes days. You open the asset register — a spreadsheet last updated seven months ago. You check the vendor list — a different spreadsheet, maintained by someone in procurement who’s on holiday. You dig through contracts for the data processing agreement. You scan the risk register for anything related to this vendor. You email three people who might know which systems actually run there versus which ones were migrated off last quarter.
While you’re doing this, the CEO is in a meeting telling the board “we’re investigating.” Your client’s security team is waiting. The clock on your GDPR 72-hour notification window is ticking — assuming this even qualifies, which you can’t determine until you know what data is involved, which you can’t determine until you know which systems are affected, which you can’t determine because the information is scattered across six disconnected documents maintained by four different people.
This is what a disconnected security programme feels like when it matters.
Now imagine something different. You have a system — could be a specialised tool, could be a well-maintained internal wiki, could be an internal database someone built — where your assets are linked to the vendors that host them, linked to the data they process, linked to the controls that protect them, linked to the requirements those controls satisfy, linked to the contracts that govern the vendor relationship.
You look up the vendor. In seconds, you can see: three systems hosted there. Two process personal data. One is covered by your ISO 27001 scope. The data processing agreement requires notification within 48 hours. Two client contracts reference this service specifically. The controls affected are access management and encryption at rest — both have current evidence from last month’s review.
You know exactly where you stand. Not because you’re smarter or better prepared in some abstract sense. But because the information was connected. The relationships between things were maintained alongside the things themselves.
The building blocks
Every security programme deals with the same set of entities: assets, risks, controls, requirements, evidence, vendors, people, tasks — plus incidents, vulnerabilities, threats, policies, audits, and plans. You know what these are. You work with them daily.
Two of them deserve a closer look, though, because many programmes treat them as second-class citizens when they shouldn’t be.
People — not as a headcount or an org chart, but as first-class entities in the programme. The specific individuals who own controls, perform tasks, manage risks, and bear accountability. When you can trace from a control to the person who owns it, and from that person to everything else they’re responsible for, you can answer questions like “what’s at risk if this person leaves?” or “who’s overloaded?” Many programmes track people informally — in someone’s head, or in the assignment column of a spreadsheet. That’s not the same as treating them as connected entities.
Tasks — not action items on a to-do list, but the operational layer where the programme meets reality. A control exists in theory. A task is what makes it exist in practice — the specific access review, the specific risk reassessment, performed by a specific person at a specific time. When tasks are connected to the controls they maintain, the evidence they produce, and the people who perform them, the programme becomes operational rather than formal. Many programmes track tasks loosely if at all. Chapter 7 goes deeper on this.
Organisations do track most of these entities. Many track them well. The problem is they track them separately.
The spreadsheet maze
I have a name for this pattern: the spreadsheet maze. A maze of disconnected documents, each containing useful information, none connected to the others.
The asset register lives in one spreadsheet. The risk register in another. Controls are documented in a policy document or a GRC tool. Requirements are in yet another spreadsheet, or possibly several — one per framework. Evidence is scattered across shared drives, email threads, and internal tools. Vendor information lives in procurement’s system, which the security team can barely access. People and their responsibilities exist partly in HR’s system, partly in the security team’s head, and partly in work-in-progress procedures.
Each document is maintained by a different person, updated on a different schedule, and structured in a different way. The risk register references assets by name — but the names don’t always match the asset register, because they were created at different times by different people. The control descriptions reference requirements, but by a shorthand that only the person who wrote them understands. Evidence files are named with dates and cryptic abbreviations that made sense to whoever uploaded them six months ago.
This is a natural result of building a programme incrementally, one compliance requirement at a time, using whatever tool was available at the moment. It’s how programme after programme gets built, because nobody planned to have a connected programme. Instead, they planned to pass the next audit.
The spreadsheet maze works, sort of, most of the time. You can find the information if you know where to look and who to ask. It gets you through audits, with enough scrambling. It satisfies the letter of most requirements.
But it breaks — spectacularly — the moment you need to think across the connections. Like on that Tuesday morning when a vendor announces a breach and you need to trace from vendor to asset to data to obligation in minutes, not days.
Why relationships are your most valuable data
The entities in your security programme are important. But the relationships between them are more important.
Knowing you have 200 controls is a number. It tells you almost nothing useful. Knowing that Control 47 (quarterly access review of production database) protects Asset 12 (customer data store) against Risk 8 (unauthorised data access), satisfies Requirement A.5.18 (ISO 27001) and CC6.1 (SOC 2), is owned by your infrastructure lead, was last evidenced three weeks ago, and is currently up to date — that’s knowledge you can act on.
This knowledge enables you to act in any direction. You can start from the control and see what it protects and which requirements it satisfies. You can start from a person and see what they own, which risks that covers, and whether one of those risks just became more likely because a newly disclosed vulnerability touches the asset it lives on.
I think you see what I mean by everything connects. The difference is the difference between a map and a filing cabinet. A filing cabinet stores information. A map shows you where things are in relation to each other. When you’re trying to navigate — which is what managing a security programme is — you need the map. So when a critical vulnerability lands in a library your web framework uses, you trace it: affected technology → assets running it → data those assets process → risks tied to those assets → controls that should be mitigating — and the people who own them and need to act. Minutes rather than hours or days to understand the blast radius, because the connections already existed.
The antidote to overwhelm
Chapter 2 described the overwhelm that comes from trying to hold an entire security programme in your head — hundreds of assets, dozens of risks, hundreds of controls, hundreds of requirements across multiple frameworks. Most human brains aren’t built to work that way — a brain is not a graph database, and it doesn’t need to be. When the connections exist, you don’t need to remember them. You only need to be able to get reliable answers quickly.
“Are we ready for the ISO 27001 surveillance audit?” In a disconnected programme, answering that requires weeks of preparation and a lot of anxiety — cross-referencing spreadsheets, chasing evidence, hoping nothing was missed. In a connected programme, it’s a question you can just ask: requirements linked to controls, controls linked to evidence, evidence with dates and status. The answer is there, because the connections are there. Chapter 11 goes deeper on how you tell that story to different audiences — the auditor, the board, the customer — but the precondition is the same: the data has to be connected before it can be queried.
The same holds when something new is asked of you. A new regulation comes into force. In a disconnected programme, mapping it feels like building from scratch: months of requirement-by-requirement investigation. In a connected programme, its requirements land on controls you already run, each carrying its evidence. The mapping is a lookup, and the real gap — the work you genuinely need to do — is a fraction of what the regulation text implies. If you already hold ISO 27001, a surprising amount of NIS2 is covered; you just couldn’t see it before.
The job is still complex. But the complexity becomes navigable, because you have a map. The overwhelm shrinks, and the headspace comes back — for work more important, and more fun, than chores.
Building connections in practice
I should be honest: building a connected programme isn’t easy. If it were, everyone would already have one. The spreadsheet maze is the path of least resistance — each spreadsheet solves an immediate problem, and by the time you realise the maze is the problem, you’re deep in it.
The practical question — where to start, what to connect first, how to run alongside your existing programme without burning it down — is what Chapter 9 addresses in detail. But first you need a shift in how you look at things: decide that relationships are data, not overhead. Stop treating “which control satisfies which requirement” as something you answer during audit prep; treat it as something you maintain continuously. That shift — from reactive mapping to continuous maintenance — is where the spreadsheet maze starts to become a connected programme.
The imaginary friend
Imagine you had a colleague who knew your entire security programme. Not just the documents — the relationships. They knew which assets depended on which vendors, which controls protected which assets, which requirements were satisfied and which had gaps, who owned what, and when things were last reviewed. You could ask them anything — “are we ready for the audit?” “what’s affected by this vulnerability?” “where are our biggest gaps?” — and get a specific, contextual answer in seconds.
Here’s what that colleague would have told you at 9:15 on that Tuesday morning:
“A vendor you depend on just announced a data breach. Three of your services run on their infrastructure. Two process personal data. One falls within your ISO 27001 scope. Your data processing agreement requires notification within 48 hours. Two client contracts are affected. The relevant controls were last reviewed three weeks ago. Here’s who needs to be notified, here’s the regulatory timeline, and here’s the evidence package for your existing controls.”
The programmes that can answer these questions in minutes are the programmes that sleep well at night. The ones that take days to trace a single vendor dependency are the ones where people burn out, where audits are stressful, and where incidents cause unnecessary chaos.
The foundation
The connecting is the work. The connections are the value.
The next time you add anything to your security programme — an asset, a control, a risk, a requirement — don’t just record it. Connect it. Ask what it relates to. Link it to the things it affects and the things that affect it. That connection is more valuable than the record itself.
This chapter is the pivot point of the book. Part I named what’s broken — not because people are incompetent, but because the data model underlying many programmes doesn’t preserve the relationships that make the programme manageable. Everything that follows depends on fixing that.
Connections give you clarity — you can see what protects what, what satisfies what, where the gaps are. Clarity is the precondition for feedback (did the control work? did the review find anything?) and feedback is the precondition for proportionality (where should we invest more? where are we over-investing?). That loop — clarity, feedback, proportionality — is the structural argument of the rest of this book. None of it works without the connections. This is where it starts.
What to do Monday morning
Pick your most critical asset and trace its connections by hand. Your main production system, your customer database, whatever keeps you up at night. On a whiteboard or a blank document, map: what risks does it face? What controls protect it? What requirements do those controls satisfy? Who owns them? When was the last evidence collected? If you can complete this in under 30 minutes, your programme is more connected than most. If you can’t — if you hit dead ends, missing information, people you need to ask — you’ve just identified exactly where your connections are broken.
Audit one connection chain for your next audit. Pick three requirements your auditor will ask about. For each one, trace backward: requirement → control → evidence. Is the chain complete? Is the evidence current? Can you produce it without asking someone? Do this for three requirements and you’ll learn more about your audit readiness than a month of preparation theatre.
Link the newest thing you added. Find the most recent vendor, system, or control in your programme — this month’s addition. Create its connections now: what it provides or protects, which assets depend on it, which requirements it satisfies, who owns it. Ten minutes. Then make that step part of intake — nothing new enters without its links. The map gets built one connection at a time, starting with this one.