Security culture programs fail when training content stops feeling relevant

At a glance

What this is: This recap argues that security culture programmes work best when they are tailored to audience, maturity, and workflow rather than delivered as generic awareness content.

Why it matters: For IAM and security teams, the same principle applies to identity, NHI, and broader governance programmes: people only follow controls they understand, can use, and can defend to leadership.

👉 Read Escape's recap of security culture programmes, metrics, and rebooting failed training

Context

Security culture fails when teams confuse completion metrics with actual behavioural change. In identity and access programmes, the same gap appears when governance processes are designed for audit coverage but do not fit how developers, employees, or security champions actually work.

The article focuses on how to structure programs so they match the audience, the operating model, and the maturity of the organisation. That matters for IAM, PAM, and NHI governance because controls only become durable when the surrounding culture makes them usable rather than purely compliant.

Key questions

Q: How should security teams design culture programmes that people actually use?

A: Start by mapping each initiative to a specific audience and workflow. Employee awareness, developer practices, and tactical reporting all require different content, cadence, and measures of success. Programs that ignore this usually produce participation fatigue rather than behaviour change, because users experience them as generic overhead instead of operational support.

Q: Why do completion rates fail as audit evidence for security awareness programmes?

A: Completion rates measure participation, not security outcome. A workforce can finish every course and still click malicious links, share data unsafely, or ignore policy. Auditors increasingly want evidence that the control reduced real risk, which means behavioural indicators matter more than attendance records.

Q: How can organisations tell whether their security culture is actually working?

A: Look for practical signals such as quick self-reporting, low blame in incident follow-up, strong participation in drills, and consistent use of verification steps. A healthy culture shows up when people raise issues early and teams recover quickly. If mistakes are hidden or repeated, the culture is weakening control effectiveness.

Q: What should teams do when a security culture programme stops gaining traction?

A: Run a retrospective and ask why the programme failed to resonate before adding more content. The likely fixes are narrower scope, a clearer business case, stronger ownership, or a better delivery model. Restarting without understanding the reason for disengagement usually repeats the same problem.

Technical breakdown

Why security culture programs need a quadrant model

A useful security culture framework separates two dimensions: the audience and the operational goal. Programs aimed at all employees, such as awareness and response, differ from programs aimed at developers, where the work is closer to application security and product design. A quadrant model helps teams avoid forcing the same content into every workflow. It also makes it easier to classify which activities are educational, which are operational, and which are participatory. In practice, the structure matters because maturity comes from fit, not volume.

Practical implication: segment security culture initiatives by audience and workflow before scaling training or champion activity.

Why mature programs depend on dedicated program ownership

The article makes a strong point that security culture does not mature simply because an organisation grows. Larger organisations often add complexity, onboarding friction, and programme sprawl, which can reduce consistency if no one owns the operating model. Dedicated technical program managers or security product engineers provide continuity, coordination, and the ability to translate security intent into something teams will actually use. Their value is less about technical depth alone and more about sustained cross-functional execution. That makes ownership the difference between a campaign and a programme.

Practical implication: assign a dedicated owner with cross-functional access and leadership reach, not an ad hoc volunteer model.

How metrics should connect behaviour, process, and technology

Effective measurement in security culture requires more than training completion counts. The article points to a three-part view: people metrics that show participation, process metrics that show workflow completion, and technology metrics that show whether the supporting tools are being used. This is the same logic identity programmes need when measuring access reviews, entitlement workflows, or NHI governance. A metric only matters when it tells a leadership story about behaviour and operational control, not just activity. Without that, dashboards measure motion rather than security.

Practical implication: build metrics that show whether the control is being completed, used, and understood, not just whether it exists.

NHI Mgmt Group analysis

Security culture is an access-control problem in disguise: if people cannot see why a workflow matters, they will route around it. That same failure mode appears in IAM, PAM, and NHI governance when approval steps, reviews, or training feel detached from operational reality. The control may exist, but the human system around it does not reinforce use. Practitioners should treat relevance as a control requirement, not a communication nice-to-have.

Programme maturity depends on operational ownership, not organisational size: large companies often accumulate more training content, more stakeholders, and more inconsistency rather than more maturity. The real differentiator is a dedicated owner with enough authority to coordinate across teams and enough credibility to make the programme useful. For identity programmes, that means governance must be run like an operating model, not a campaign.

People, process, and technology metrics need to be reported together: completion rates alone do not tell leadership whether security culture is changing behaviour. A stronger model ties participation, workflow completion, and tool usage into one narrative that shows whether controls are actually adopted. In identity governance terms, that is the difference between audit evidence and operational control.

Named concept: relevance fatigue: when security content no longer feels connected to the work people do, participation drops and the programme loses force. This concept explains why technically sound controls can still fail socially. Teams should design controls and enablement around the user’s context, or expect passive resistance.

Security culture only works when the story is credible: the article’s core insight is that motivation cannot be manufactured with generic messaging. People accept security work when the why is believable, the effort is proportional, and the workflow fits their role. For practitioners, that means policy, training, and identity governance must be explained as enablement, not interruption.

What this signals

Security culture work is increasingly converging with identity governance because both depend on adoption, not just policy existence. Teams that already struggle to get employees to complete or respect security workflows will face the same friction in access reviews, champion programmes, and NHI governance unless they design for usability first.

Relevance fatigue: this is the governance gap that appears when security teams ask for behaviour change without giving people a credible reason to care. The practical response is to simplify workflows, align messaging to real risk, and measure whether the control changes behaviour, not just whether it was delivered.

For practitioners

• Segment programmes by audience and workflow Separate employee awareness, developer security practices, and tactical response activities into different programme lanes so the content matches the job being done. Use the quadrant model to decide whether an initiative belongs in learning, participation, or operational workflow.
• Assign a dedicated programme owner Name one accountable owner for security culture who can coordinate across security, product, and business teams, and make sure that person can reach leadership without bottlenecks. Ownership should include cadence, messaging, and follow-through.
• Measure behaviour, not just attendance Track whether training is completed, whether workflows are closed on time, and whether the supporting tools are actually used. Tie those metrics to leadership reporting so the programme is judged on operational change, not activity volume.
• Retire content that fails the relevance test Review phishing and awareness content for whether it maps to real employee risk and daily tasks. If the programme cannot explain why the work matters in a believable way, reduce the scope or redesign the message before asking for more participation.

Key takeaways

• Security culture programmes fail when they are too generic to feel relevant to the people asked to use them.
• Dedicated ownership and behaviour-based metrics matter more than programme size or training volume.
• Identity and security governance both improve when controls are designed as enablement, not interruption.

Key terms

• Security Culture: Security culture is the shared set of behaviours, norms, and expectations that shape how people report issues, handle pressure, and use controls. Strong culture makes it easier to surface mistakes early, while weak culture hides errors until they become incidents or access problems.
• Security Champion: A security champion is a team member inside a delivery group who helps translate security requirements into day-to-day engineering practice. The role reduces bottlenecks by giving teams a trusted local guide, while central security keeps policy, standards, and escalation paths consistent.
• Behaviour-Based Measurement: Behaviour-based measurement tracks what people actually do, rather than whether they attended training or completed a module. In practice, this means using signals such as phishing reports, exception rates, and secure workflow adoption to show whether controls are reducing risk.

What's in the full article

Escape's full recap covers the conversational detail this post intentionally leaves for the source:

• The original podcast discussion with Marisa Fagan on security champions and programme ownership.
• Direct examples of how the quadrant model maps to different culture programme types.
• The five-whys approach to rebooting a failed programme and why relevance matters.
• Additional commentary on zero trust messaging and employee adoption.

👉 Escape's full recap includes Marisa Fagan's examples on champions, metrics, and culture programme design.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners building durable identity controls. It helps security and identity teams connect governance intent to operational execution across modern environments.