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

Why This Matters for Security Teams

When a security culture programme stops gaining traction, the problem is usually not awareness alone. It is often a mismatch between the programme’s goals and the way people actually work, whether that means overloaded teams, unclear priorities, or messages that do not connect to operational risk. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that governance, training, and accountability need to be embedded into control design rather than treated as optional communications.

Teams tend to treat disengagement as a content problem, so they add more modules, more reminders, and more campaigns. That usually increases fatigue without improving adoption. The real issue is whether the programme is specific enough to change behaviour, visible enough to matter to managers, and measurable enough to show progress. If those conditions are missing, security culture becomes a slogan instead of an operational discipline.

In practice, many security teams discover that a programme has lost credibility only after staff start ignoring every update, not through deliberate measurement of participation or behavioural change.

How It Works in Practice

The first step is to run a retrospective that separates symptoms from causes. Low completion rates, weak workshop attendance, and poor policy recall are symptoms. The cause may be that the content is too broad, the audience is too mixed, or the programme is asking people to remember security rules that do not fit their daily decisions. A useful review asks what changed in the business, what changed in the threat environment, and what changed in the delivery model.

Security culture programmes regain traction when they become more operational and less generic. That usually means mapping messages to real workflows, assigning a clear owner, and aligning expectations with managers rather than only with end users. It also means defining what success looks like. For example, teams may track secure reporting behaviour, phishing response quality, policy exceptions, or completion of role-specific actions rather than just attendance.

• Reduce scope to the highest-risk behaviours that matter now.
• Link the programme to a business outcome such as reduced incidents or faster escalation.
• Use role-based delivery so engineering, finance, and executives each get relevant material.
• Assign operational ownership, not just communication ownership.
• Measure behaviour change with evidence, not just participation counts.

For broader governance alignment, many teams map these activities to control objectives in NIST CSF and to awareness and responsibility requirements in NIST SP 800-53 Rev 5 Security and Privacy Controls. The practical question is whether the programme helps people make better security decisions at the point of work, not whether it looks active on a calendar. These controls tend to break down when the organisation is in rapid change, because new tools, restructuring, and competing priorities make old messages feel irrelevant.

Common Variations and Edge Cases

Tighter security culture control often increases coordination overhead, requiring organisations to balance consistency against local relevance. That tradeoff matters because a single enterprise-wide message may be easier to manage, but it can fail when different teams face different risks. Current guidance suggests that blended models work better: a small set of universal principles supported by role-specific examples, manager reinforcement, and targeted interventions for high-risk groups.

There is no universal standard for how quickly a programme should be reworked, but best practice is evolving toward shorter feedback loops and more frequent adjustment. In highly regulated environments, the programme may also need to reflect formal expectations around training records, accountability, and control evidence. In identity-heavy environments, disengagement can be a sign that users are being asked to approve access, handle credentials, or follow verification steps without understanding why those actions matter.

That intersection becomes especially important when security culture touches NHI governance or agentic AI oversight, where machine accounts, secrets, and delegated access can fail for the same reason human programmes do: the control exists, but the operating model does not support it. Mature teams therefore treat culture as part of operational resilience, not a one-time awareness exercise. If the programme no longer resonates, the right response is to redesign for relevance, ownership, and measurable behaviour.

Related resources from NHI Mgmt Group

• How can security teams tell whether their identity programme is ready for zero trust?
• How should security teams build a cross-domain identity programme?
• How should security teams govern identity access in a modern GRC programme?
• How should security teams start a third party risk management programme from scratch?