People First
Design alone isn’t enough. The best method in the world fails if the people inside it don’t adopt it. Adoption isn’t about training or motivation. It’s about making the work meaningful and intuitive.
You’ve built the connected model. Established the cadence. Right-sized the programme for your actual risks. And on paper, it all works beautifully.
Then you assign the first access review to someone in operations, and they ignore it for two weeks.
You send a policy review to a department head, and they change the date on the cover page and send it back with no comments.
You ask the development team to analyse vulnerabilities using the new process, and they continue doing it the way they’ve always done it — in an ephemeral Slack thread, with no evidence trail.
The method is sound. The people aren’t broken. But the adoption is failing. The reason is the method was designed for the programme, not for the people inside it.
Chapter 3 made the case that individual security failures are usually structural failures. If you’ve read this far, I’ll assume you accept that. This chapter is about what a meaningful structure looks like from the perspective of the person being asked to do the work.
What ownership really means
Every security programme assigns ownership. Controls have owners. Risks have owners too. So do assets. The RACI matrix is populated. Names are on spreadsheets. At many organisations, that’s where ownership stops — a name on a spreadsheet.
The problem isn’t that ownership is unassigned. It’s that ownership is unresourced. There are three things that turn a name on a spreadsheet into actual ownership, and many programmes miss one, and sometimes all of them.
Time. If someone owns a control but has no time allocated to maintain it, they don’t own it — they’re just the person who’ll be chased. Ownership without time is liability, not responsibility.
This doesn’t just mean that people need to use calendars to schedule what they need to complete, though for some time-critical tasks that’s not unreasonable. It means the organisation needs to acknowledge that security work takes time, and that time has to come from somewhere. If you assign a quarterly access review to a team lead, their manager needs to know about it. Their workload needs to accommodate it. It can’t be a secret obligation that exists only between the security team and the individual.
Tools. If someone owns a control but has no way to see its current state — when it was last reviewed, what evidence exists, what has changed — they’re managing by memory or, worse, imagination — neither is a good proxy for reality. This is especially true for less frequent tasks — quarterly reviews, for example. The person needs to be able to see, at a glance, what’s expected of them and whether they’re current.
Context. If someone owns a control but doesn’t understand why it matters or how it connects to the broader programme, they’ll treat it as a checkbox. Not because they’re disengaged, but because you haven’t given them a reason to engage. “You own the access review for the CRM” is an assignment. “You own the access review for the CRM because it holds customer financial data, the review satisfies our ISO 27001 and SOC 2 obligations, and incorrect access is a high risk” is ownership with context and meaning.
Time, tools, and context. That’s it. Not yearly awareness training, not culture talks. You need to give someone those three things and they will almost always do the work, because the work makes sense. Withhold any one of them and you’ll get compliance-shaped activity that might not mean compliance in reality.
Making security feel like the job, not an interruption
Part One described how security tasks feel to the people receiving them: separate from their job, opaque in language, with deadlines that feel arbitrary, and invisible in result. The fix is making the tasks less foreign.
Take a quarterly access review for a production database. The security team sends it as an email: “Please complete the Q2 UAR for prod-db. Evidence required by June 30.” It goes to the engineering team manager. They might guess what a UAR is, and where to find the current access list. Harder to decide what criteria to apply, or how to document their findings. They ask the security team, who are too busy to reply for three days. Eventually they do something — pull a list of users from the database, scan it, reply “looks fine.” The security team accepts it because the deadline is tomorrow. The evidence is a forwarded email that nobody will find next year.
Now, same task, but better delivery. The task is opened in the ticketing system where the engineering team already works, not in an email they’d archive. It’s titled “Review who has access to the production database”, it’s scoped to be completable in one sitting, and its description carries the context: who has access, what to confirm, why the database matters.
Team lead does it in 20 minutes. Finds and flags two people who shouldn’t have access anymore. When the task is marked complete, the evidence record generates itself. A notification comes back: “Access review complete — two changes actioned, control current for Q2, evidence logged.” From receiving the task to closing it: same day.
The difference is where the task arrives, the language it speaks, and the feedback that closes it. The person goes from interrupted compliance to willing participation — not because their attitude changed, but because the task and its delivery did.
Making it accessible
We covered knowledge concentration problem — one person holding the programme together in their head. Making it accessible isn’t about documenting everything. Nobody needs another 50-page manual that describes how the security programme works. These manuals are written once, read never, and outdated within months.
The goal is making the knowledge that lives in one person’s head a property of the programme itself, so that it’s available to anyone, when and in the context where they need it.
Here’s the difference. Documentation says: “Access reviews are conducted quarterly for all critical systems. The review is performed by the system owner. Results are recorded in the evidence register.” That’s accurate but not very useful. When a new person takes over, they know reviews happen quarterly but not which systems are critical, who the system owners are, where the evidence register is, what format to use, or what to do if they find a problem.
Making it obvious means the programme itself holds that knowledge: which systems are critical, who owns each review, when the last one happened and when the next is due, what the task should contain when it lands. When the sales ops lead leaves and someone new takes over, the programme doesn’t skip a beat — the knowledge wasn’t in the person’s head. It was in the connections.
Not documents that describe the programme, but a programme that describes itself. The new person doesn’t need handover documents. They need access to the system, and the system tells them what’s expected, when, and why.
I won’t pretend this is automatic. Building the connections takes effort, but once they exist, the knowledge persists independently of any individual. People can leave, change roles, go on holiday, get sick — and the programme continues, because it doesn’t depend on anyone’s memory.
This is the structural answer to Chapter 2’s problem. Not better documentation. Better architecture, built to provide insight and do the remembering.
Learning that sticks
I’ve been on the receiving and the delivering end of security awareness training.
Too often it’s the same two-year-old content delivered to the whole company: generic, trying to scratch the entire landscape of cybersecurity threats, undifferentiated for everyone. Training like that is optimised for compliance evidence, not behaviour change. For behaviour to change, the content needs context people can relate to. The design question is: what does this specific person, in this specific role, with this specific access, handling this specific data, need to know to do their job securely? That’s a different principle than “what does everyone need to know about security?”, and it produces different training — shorter, more relevant, more effective, with better outcomes.
Relevant content is half of the answer. Format is the other half: reflection instead of instruction. A starting point that outperforms another slide deck is asking people to reflect on how security principles apply to their own job — where they handle internal versus public information, who they would tell first if something looked wrong, what would be exposed if their laptop went missing this afternoon. It’s harder to zone out of questions about your own work. The connected programme sharpens the questions: when a person can see which assets they touch, which controls they own, and which risks sit on their role, universal principles stop being abstract — they attach to specific things on their own desk.
Even better: when people who work together reflect as a group, the understanding is shared and reinforced. A team that talks through “what would hurt us most, and who does what in the first hour?” once a quarter learns more than any e-learning module can teach, and surfaces gaps that awareness training wouldn’t find. These are the habits of successful systems that assume human error. Institutionalised reflection — debriefs, reviews, learning from adverse events. Timely, disciplined, and about real work.
Timing follows the same logic. The calendar is the worst trigger for learning. The moments that teach are when someone joins, when their role changes, and just after something happened — a near miss, an incident, a surprising audit finding. At those moments the person is already asking the question the training answers.
This is more effective, and more respectful. People can tell when you’re wasting their time. A generic two-hour session says “we need to prove you were trained.” Thirty minutes of reflection on their own role says “we value your time enough to make this useful.” That distinction matters more for your security culture than any number of posters and Slack reminders.
The adoption curve
I will be honest with you — this takes patience. Changes don’t happen overnight, and these transitions have predictable shapes.
Week one: scepticism. People have seen new processes before. They’ve been through the last three “improvements” that made things more complicated, not less. They will be politely uncooperative. This is normal.
Month one: cautious engagement. Someone completes an access review using the new approach and says “that was actually easier.” Someone else sees their task and, for the first time, understands why they’re being asked to do it. These moments are small but significant. They’re the cracks in the scepticism.
Month three: organic adoption. People start asking whether other tasks can work this way. Someone suggests a tweak based on their experience. You’re no longer pushing — people are starting to pull.
Month six: the new normal. Tasks arrive on schedule. Evidence accumulates. Someone new joins the team and is productive within a week or two, because the programme describes itself. The security lead goes on holiday for three weeks and nothing breaks.
The curve depends on two things. First, the quality of the first experiences — which is why Chapter 9 emphasised picking your most painful area. If the first cycle is clunky, scepticism hardens.
Second, sustained recognition of the unglamorous. Chapter 3 named the invisibility problem — prevented incidents don’t get celebrated. If you want people to sustain the operational discipline this book has been building toward, you need to make the steady work visible. Not with gamification — with acknowledgement. “The operations team completed all six access reviews on schedule, identifying four access changes. Third consecutive quarter of full compliance.” That’s a sentence in a management report that makes someone’s work visible. “The vendor assessment you completed last month caught a subprocessor change that triggered a GDPR update. Good catch.” That’s feedback that makes someone’s effort feel worthwhile.
Security culture — the real kind, not the blame-shifting variety from part one of this book — is built from these small moments. From the steady message that operational work matters, that someone notices when it’s done well, and that the absence of drama is the whole point. After month three, the programme sustains itself. Before month three, it needs caring nurturing: someone who provides the message consistently.
What to do Monday morning
Audit one control for time, tools, and context. Pick a control that someone outside the security team owns. Ask them three questions: do you have time allocated for this? Can you see its current state without asking anyone? Do you know why it matters? Any “no” is a gap between named ownership and real ownership. Fix the gap before the next review cycle.
Make one secret obligation public. Pick a security task owned by someone outside the security team and confirm their manager knows it exists and that it’s in their workload. If the manager doesn’t know, the ownership was never real — you’ve just found the gap between a name on a spreadsheet and time to do the work.
Send one piece of feedback for a completed security task this week. Find someone who recently completed a review, assessment, or questionnaire. Tell them what their work produced — what it caught, what it satisfied, what it updated. One sentence. Then ask one question back: what would you change about the task? Their answer is reflection working — and your next template improvement. You’ve just done more for your security culture than your last awareness training programme.
The best security programme in the world is the one people actually use. Not the most comprehensive, not the most auditable, not the most documented — the one where the people inside it understand what they’re doing and why. Everything else follows from that.