Security Culture & Organisational Change¶
What you'll be able to do in this chapter
- Explain why governance on paper fails without a supporting culture.
- Name the main levers a CISO has to shift behaviour and bring people with them.
- Plan a realistic culture and change effort for the autonomous, resistant Site Beta.
Everything right on paper, nothing changed in practice¶
You have done the whole Module. There is a strategy, a mandate, a clear role, a policy architecture, a committee, owners, and an honest reporting pack. Six months later you visit Site Beta and find it running exactly as before. The plant manager nods politely in every committee meeting and changes nothing on the floor. The contractor still logs in the old way. The standards exist but not the behaviour. This illustrates an important limitation of governance: formal structures do not automatically change behaviour. The gap between them is culture, and closing it is the work of this Lesson.
What security culture is¶
Security culture is the set of shared habits and attitudes that decide what people actually do when no one is watching and no auditor is in the building. It is not the policy; it is whether the policy is lived. You can mandate behaviour (the standard says access must be logged), but you cannot mandate belief (that logging it matters). Where belief is absent, behaviour reverts the moment attention moves elsewhere, which is precisely what happened at Beta. Culture is the mechanism by which a written policy becomes a real practice, and without it the rest of this Module is an elegant set of documents that govern nothing.
Why change is genuinely hard here¶
It helps to name the specific resistances, because they are not stubbornness for its own sake:
- Entrenched autonomy. Site Beta has run itself for fifteen years. "We have always done it this way, and the line keeps shipping" is a powerful argument, and from the floor it looks true.
- Security seen as interference. To the plant manager, a head-office security function is an outsider adding risk to his uptime for benefits he cannot see. If security is framed as a threat to production, he will resist it to protect production, which is his job.
- Fear and blame. In a culture where admitting a problem gets you blamed, people hide problems. That is fatal for security, where you depend on incidents and weaknesses being surfaced early.
A CISO who treats these as obstacles to be overruled with the mandate will win the argument but lose their cooperation. The mandate gives you the authority to require, but the culture is how you get genuine cooperation, and only cooperation scales.
The levers that actually move culture¶
You change a culture with a small number of deliberate levers, not with posters:
- Tone from the top. When the board and executives visibly treat security as real (ask about it, fund it, attend the committee), it stops being head-office noise.
- Make the secure way the easy way. People follow the path of least resistance. When the secure option is easier than the insecure one, people tend to choose it without needing to be forced.
- Involve the owners in setting the standard. A standard the Beta operations director helped write is one he defends; a standard imposed on him is one he tolerates until you look away. Participation converts compliance into ownership.
- A no-blame reporting culture. Reward surfacing a problem, never punish the messenger, so weaknesses come to you early instead of hiding until they become incidents.
- Small wins and local champions. One respected engineer at Beta who adopts the new way moves more than any policy. Visible early wins build belief.
- Frame security as safety and continuity. In OT, a safety-first culture already exists. Tie security to it: segmenting the network protects the line, controlling the contractor protects uptime. You are not fighting the existing culture; you are extending it.
- Measure it. Culture is not unmeasurable: incident-reporting rates, exception honesty, and how owners behave between audits are all signals (Chapter 2.5).
Bringing Site Beta along
A realistic approach to the plant manager and his team:
- Go in person, and lead with his goal: keeping the line running. Frame every security move as protecting uptime and safety, not constraining them.
- Have him help write the access standard for his own systems, so it is partly his.
- Find one respected engineer to pilot the logged-and-reviewed contractor process, and make that first success visible.
- Never blame the team for the state you inherited; the unsupported SCADA and the unmonitored contractor were nobody present's decision. Blame can make people less willing to report weaknesses.
None of this weakens the standard. It is how the standard actually gets lived on a floor that has never answered to security.
Application: a culture plan for Beta¶
On paper, write three specific moves to shift Site Beta from compliance-on-paper to real change. For each, name the lever it uses (from the list above), the action in concrete terms, and how you would know it worked (the signal you would watch). Avoid anything vague ("raise awareness"); each move should be something you could actually do next month and later point to.
Model answer (open after you've drafted yours)
Three concrete moves, each with its lever, action and signal:
- Involve the owners. Action: run a 90-minute session where the Beta operations director and lead engineer co-write the remote-access standard for their own systems. Signal: they refer to "our standard" unprompted, and exception requests start coming to you rather than breaches being found by you.
- Frame security as safety and continuity. Action: present network segmentation to the Beta team as protection for uptime and tooling, in their own safety language, not as a compliance demand. Signal: the operations director raises a segmentation gap himself, as a risk to the line.
- Small wins and local champions. Action: pilot the logged-and-reviewed contractor process with one respected engineer, and make that first success visible at the committee. Signal: a second team asks to adopt it without being told to.
Each is something you could do next month and later point to. Yours passes if every move names a real lever, a concrete action, and an observable signal. At this stage, do not "raise awareness".
Key takeaway
Governance on paper is not governance in practice, and the gap between them is culture: the shared habits that decide what people do when no one is watching. You can mandate behaviour but not belief, so where belief is absent, behaviour reverts. The resistances at Beta (entrenched autonomy, security seen as interference, fear and blame) are reasons, not mere stubbornness, and the mandate alone cannot overcome them. Move culture with deliberate levers (tone from the top, making the secure way easy, involving owners, no-blame reporting, small wins, and framing security as safety), and remember you are extending Beta's existing safety culture, not fighting it. This is what makes everything built in Module 2 finally take hold, and the ground on which the Compliance and Risk Modules will stand.