Who is accountable for building a security culture that actually changes employee behaviour?

Accountability sits with both leadership and line managers, not the security team alone. Executives set the expectation that security is a business priority, while managers reinforce it in daily work. Security teams provide the data, coaching tools, and feedback loop. Without shared accountability, culture initiatives remain awareness exercises instead of operational risk management.

Why This Matters for Security Teams

security culture changes behaviour only when accountability is visible at the point where work happens. Executives can define priorities, but employees respond to the expectations, incentives, and follow-up they receive from their managers. That is why culture programmes fail when they are treated as a communications campaign instead of a management responsibility. NIST SP 800-53 Rev 5 Security and Privacy Controls frames security as an organisational control environment, not a standalone awareness function, which is the right lens for this question.

The practical risk is simple: if managers are not measured on security-relevant behaviour, they tend to optimise for delivery speed, convenience, or local team norms. Security teams can supply training and reporting, but they cannot substitute for daily reinforcement, exception handling, and performance management. In mature programmes, security becomes part of how teams plan, approve, and review work, not an annual training topic.

In practice, many security teams encounter culture failure only after repeated policy exceptions or preventable incidents have already become normalised.

How It Works in Practice

Accountability for culture should be assigned across three layers. Leadership owns the mandate, managers own reinforcement, and security owns enablement and measurement. That structure turns security from a message into an operating expectation. The security function should define the behaviours that matter most, such as reporting suspicious email, protecting secrets, challenging unusual access requests, and following approval paths for sensitive actions. Managers then translate those behaviours into team routines.

Operationally, the strongest programmes use measurable touchpoints rather than vague awareness goals. For example, onboarding can include role-based security expectations, quarterly reviews can include behaviour trends, and incident postmortems can feed manager coaching. If employee behaviour is the target, the feedback loop must be close to the work. NIST CSF 2.0 helps anchor this by treating governance as a first-class concern, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides control language that maps well to training, oversight, and accountability expectations.

A practical ownership model usually includes:

• Executives setting policy priorities and accepting residual risk
• Line managers reinforcing expectations in team rituals and performance discussions
• Security teams supplying metrics, scenarios, and coaching material
• HR or people operations embedding security expectations into lifecycle processes

Where identity and access are involved, managers also need to reinforce approval discipline. That includes least privilege, timely access removal, and escalation when people bypass process for convenience. In NHI-heavy environments, the same principle applies to service accounts, secrets, and automation identities, because unmanaged exceptions quickly become embedded behaviours. These controls tend to break down when a fast-growing organisation relies on informal approvals and no one is accountable for exceptions after the initial deployment.

Common Variations and Edge Cases

Tighter accountability often increases management overhead, requiring organisations to balance behavioural control against team autonomy and delivery speed. That tradeoff is real, especially in engineering, sales, or incident-response environments where urgent work creates pressure to bypass controls. Current guidance suggests the answer is not more training alone, but clearer ownership and smarter reinforcement.

There is no universal standard for how to measure culture maturity yet. Some organisations use completion rates and phishing results, but those are indirect indicators. Better practice is evolving toward behaviour-based metrics, such as access review completion, policy exception trends, reporting timeliness, and manager follow-through on repeated issues. In regulated environments, this becomes part of governance evidence as well as day-to-day control operation.

Edge cases matter. In highly distributed or contractor-heavy organisations, managers may have limited visibility into security behaviour unless systems produce clean telemetry and escalation paths. In matrixed organisations, culture ownership can blur unless one executive function is explicitly accountable. For agentic AI and NHI-heavy workflows, the same governance question extends to who approves automated actions, who reviews service identity drift, and who can override unsafe use of credentials. That intersection is still maturing, so best practice is evolving rather than fully settled.

Culture changes when accountability is reinforced in the same places where work is approved, reviewed, and corrected. In that respect, the most effective programmes treat security behaviour as an operational duty, not an optional value statement.

Related resources from NHI Mgmt Group

• How should security teams build an AI risk repository that actually changes behaviour?
• Who is accountable when an automatic model fallback changes behaviour?
• How do you know if a security awareness programme is actually changing behaviour?
• How can organisations tell whether their security culture is actually working?