Have you ever been in a team meeting where a senior leader declares that cybersecurity was "everyone's responsibility!"?
You know the meeting. Someone writes it on the whiteboard. There are nods. And then everyone files out and goes back to their desks and nothing changes, because "everyone is responsible" is just a polite way of saying no one is.
That often sticks its head out when someone needs to take responsibility for something, but everyone is pointing to everyone else to take that responsibility.

This is where the Three Lines of Defence model comes in to play. If you've been in GRC for a while you've probably heard it. If you haven't, stick with me, because it's one of those things that once it clicks, you start seeing it everywhere.
The idea is simple enough to explain:
The First Line is the business. The people actually doing the work. The developer pushing code, the HR manager onboarding someone new, the finance team processing invoices. They own the risk because they're the ones generating it. Every decision they make, every system they touch, every process they run, that's where risk either gets managed or it doesn't. It starts with them.
The Second Line is the oversight function. Risk Management, Compliance, and yes, Information Security sits here too. The second line doesn't do the business activity. Their job is to set the standards, watch whether those standards are being followed, and say something when they're not. They're not the ones playing the game. They're watching the game and keeping score.
The Third Line is Internal Audit. Independent of the other two. They come in periodically and ask a very simple question: is any of this actually working? Not "do we have policies" or "do we have controls." Are those controls real? Is the second line genuinely providing oversight or just generating paper?
Three layers. Each one distinct. Each one necessary.
Here's where it goes sideways for most security teams, and I've seen this in so many organisations it almost feels like a rite of passage.
The security team ends up doing first line work. Managing the firewall. Applying the patches. Babysitting the endpoint tools. They're operational.
They're embedded in the machine.
And somewhere along the way, they've stopped being the people watching the machine and become just another part of it.
And then who's watching them?
It's not a gotcha question. It's a real one. If the security team writes the policy, and then configures the controls to meet the policy, and then checks whether the controls are working, there's no independent eye on any of it. That's not oversight, that's just a very busy team auditing their own homework.
The goalkeeper can't also be the referee. It might hold together when things are going well. The moment there's any real pressure, it collapses.
What the second line version of Information Security actually looks like: you define the standards, you assess whether the business is meeting them, and you report on the organisation's risk posture to leadership.
The first line, meaning the business units and the IT operations teams who own the systems, they implement and run the controls. They own them. That separation isn't bureaucratic pedantry. It's what makes accountability real.
If you work within ISO 27001, this structure is baked into the standard, even if it never uses the words "Three Lines of Defence."
The requirement for management to demonstrate leadership and take ownership of information security? That's the first line. The ISMS itself, the policies, the risk assessments, the monitoring? That's second line governance. The internal audit requirement? Third line, right there in clause 9.2.
The standard was designed assuming these roles are separated. When they're not, you usually end up with an ISMS that looks fine on paper and falls apart the first time someone actually stress-tests it. Which is exactly what Internal Audit is there to do, and exactly why they need to be independent.
The most functional setups I've seen have a clear split: business units own and operate the controls day to day (first line), the Information Security team sets the standards and does the monitoring (second line), and Internal Audit independently validates whether the whole thing is working (third line). Everybody knows what they're responsible for and who's checking their work.
The most dysfunctional ones have the security team managing the cloud infrastructure, writing the policies, doing risk assessments, and somehow also expected to provide independent reporting on how well they themselves are doing. Those teams are always tired.
And when something goes wrong, you spend more time figuring out who was responsible than fixing the actual problem.
So here's something worth sitting with. Think about the last security incident at your organisation, or the last near-miss. Ask yourself honestly: who spotted it, who was supposed to be stopping it from happening, and who had been checking that the prevention was actually in place?
If the answer to all three is the same team, that's worth a conversation.
