Most organisations try to fix security behaviour with more training and stricter rules, then find people still share passwords, approve unexpected prompts and stay quiet about mistakes. Behaviour follows culture: the shared beliefs, unwritten norms and everyday signals from leaders that tell people what really matters. This guide explains how to build a security culture deliberately, using the UK National Cyber Security Centre (NCSC) cyber security culture principles published in June 2025, leadership behaviours, just culture and psychological safety, reporting routes, social norms and rules people can follow. It is written for CISOs, security awareness and culture leads, and the executives whose behaviour sets the tone. How to measure culture once you are building it is covered in the Security Culture Measurement Guide.
Key takeaways
- Culture is built by conditions, not campaigns. Awareness content tells people what to do; culture decides whether they do it when it is inconvenient, which depends on leaders, norms, friction and how mistakes are treated.
- The NCSC gives a usable model. Its six cyber security culture principles cover shared purpose, openness, change, social norms, leadership and rules, and each comes with what good looks like and suggested actions.
- Psychological safety is the foundation. People report mistakes, suspicious requests and leaked credentials only when they believe they will not be punished or humiliated for speaking up.
- Leaders go first. Leaders who follow the same controls, share their own security mistakes and fix unworkable policies change behaviour faster than any training module.
- Workarounds are data. When people bypass a control, treat it as evidence that the control conflicts with how work gets done or with a positive norm such as politeness, and redesign it.
What security culture is, and what it is not
Security culture is the set of values, assumptions and social norms that shape how people think and act about security when nobody is checking. The NCSC illustrates it as an iceberg: the security behaviours you can observe sit above the waterline, and the principles, traits and attitudes that produce them sit below it. Changing what is above the line without working on what is below rarely lasts.
| Element | Awareness programme | Security culture |
|---|---|---|
| Main goal | People know the risks and the rules | Secure behaviour is the normal, expected way of working |
| Typical activity | Annual training, phishing simulations, posters | Leadership behaviour, reporting routes, control design, incentives, how incidents are handled |
| Who owns it | Security awareness team | Leadership at every level, with security as facilitator |
| How failure is treated | More training for the person who clicked | Ask why the behaviour made sense to them and fix the conditions |
| Evidence of success | Completion rates, click rates | Reporting rates, speed of reporting, fewer workarounds, leaders modelling controls |
Awareness is still needed, and NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program (September 2024), frames a learning programme as a way to drive behaviour change and a security and privacy culture. The programme detail is in the Security Awareness and Human Risk Management Guide. This guide focuses on the conditions that make awareness stick.
The six NCSC cyber security culture principles
The NCSC published its cyber security culture principles on 4 June 2025. Each principle comes with what good looks like and suggested actions. The table condenses them into first steps.
| NCSC principle | What good looks like | First actions |
|---|---|---|
| 1. Frame cyber security as an enabler, supporting the organisation to achieve its goals | Staff see policies as supporting their work; control designers understand and minimise impact on daily work | Define a shared purpose, explain security activity in terms of it, have senior leaders champion it, align formal and informal rewards |
| 2. Build the safety, trust and processes to encourage openness around security | People feel willing and able to ask, report and admit mistakes; incidents investigated to learn, not to blame | Review reporting routes, thank reporters and tell them what happened, run fair and transparent investigations, share lessons |
| 3. Embrace change to manage new threats and use new opportunities to improve resilience | Change seen as a way to improve; changes made when needed, limiting change fatigue | Routine mechanisms to spot emerging risks, bring stakeholders together early, make risk decisions at the right level quickly |
| 4. The organisation's social norms promote secure behaviours | Desirable and undesirable norms identified; norms support rather than conflict with policy | Ask staff which practices do not work and why; offer controls that fit positive norms; use incentives and role models against negative ones |
| 5. Leaders take responsibility for the impact they have on security culture | Leaders at all levels share a purpose, role model secure behaviour and build psychological safety | Keep leaders informed of policy; have leaders go first by sharing their own security mistakes and how they fixed them |
| 6. Provide well-maintained cyber security rules and guidelines, which are accessible and easy to understand | Rules tested for security value and usability; people know mandatory rules from advisory guidance | Review existing rules, form a cross-organisation stakeholder group, add feedback loops, archive outdated material |
The principles are not a maturity scale and can be worked on in any order. Most organisations get the fastest return from principles 2 and 5, because reporting and leadership behaviour change what people see every day.
Leadership behaviours that shape culture
The NCSC is direct that leaders who ignore their influence can hinder culture change, because people copy what they see. Leadership here means every manager, not only the board.
- Follow the controls visibly: leaders who ask for exemptions from MFA, device policy or access reviews teach everyone that controls are for other people. In the NCSC's own scenarios, leaders follow access policies and push to fix policies that are unworkable, rather than bypassing them.
- Go first on mistakes: the NCSC suggests leaders share their own past security mistakes and how they fixed them. A director describing the time they nearly paid a fake invoice does more for reporting than a policy statement.
- Connect security to the team's goals: explain how a control protects what the team delivers, such as customer trust, uptime or a contract requirement.
- Check incentives: remove incentives that reward speed over safety, for example targets that make engineers skip review or sales staff share accounts, and recognise secure behaviour in reviews and team meetings.
- Respond well to bad news: the first reaction a leader gives to a reported mistake is remembered longer than any training. Thank the person, fix the issue, then ask what made the mistake easy.
Executives are also high-value targets. See the Security Awareness for Executives and Assistants Guide for the behaviours that matter most at that level.
Psychological safety, just culture and reporting
The NCSC uses Professor Amy C. Edmondson's definition of psychological safety: the belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes. Without it, the NCSC warns, people fall back on self-preserving behaviours: hiding mistakes, not challenging colleagues who break rules and keeping quiet about improvements.
A just culture, a concept that security borrowed from aviation and healthcare safety, puts this into practice: people are not punished for honest mistakes, while reckless or malicious behaviour is still dealt with. The NCSC's principle 2 states the same idea: incidents are investigated to learn and improve, not to blame, and people involved are treated fairly, with no punishment for innocent mistakes.
| Behaviour | Example | Fair response |
|---|---|---|
| Honest error | Clicked a convincing phishing link and reported it straight away | Thank, contain, no sanction; review why the email got through |
| At-risk behaviour | Shared a password with a colleague to meet a deadline because access requests take a week | Coach the person and fix the access process that made the shortcut attractive |
| Reckless behaviour | Disabled endpoint protection after being told why it mattered | Formal process under the disciplinary policy, applied consistently at every level |
| Malicious behaviour | Deliberately exfiltrated data | Insider incident response and legal process |
Reporting routes that people actually use
- Make it quick: one button in the mail client, one chat channel and one phone number, each reachable in under a minute. The NCSC calls for quick, easy and accessible routes and testing them in practice to remove friction.
- Close the loop: thank every reporter and tell them what happened. The NCSC describes this as creating a positive feedback loop that encourages more reporting.
- Accept reports of your own mistakes: say explicitly that self-reporting a mistake within a stated time, for example one hour, is treated as a positive act.
- Accept near misses: a request that felt wrong but was refused is valuable intelligence. Reward the refusal.
- Protect the reporter: never share a reporter's name in an incident write-up without consent, and never use a self-report as the basis of a performance rating.
Social norms and designing for secure behaviour
The NCSC describes social norms as unwritten rules people learn by watching others, and notes that telling people to stop following a norm rarely works, especially when policy does not fit how work is done. Many insecure behaviours come from positive norms: being helpful, polite or efficient.
| Positive norm behind the risk | Insecure behaviour it produces | Control that fits the norm |
|---|---|---|
| Politeness to visitors | Letting guests use the corporate Wi-Fi or tailgate through doors | A separate guest access route so saying no is not impolite (an NCSC scenario) |
| Helpfulness to colleagues | Help desk resets a password for a caller who sounds senior and urgent | Mandatory call-back to a number on record, framed as protecting the colleague |
| Speed and delivery | Engineers paste API keys into chat or code to unblock a build | A secrets manager that is faster than the workaround, and pre-commit secret scanning |
| Respect for hierarchy | Finance pays an urgent request from the CEO without checking | Out-of-band verification required for every payment change, endorsed publicly by the CEO |
| Team loyalty | Not challenging a colleague who shares accounts | Named accounts made easy to request, and leaders who ask about shared accounts without blame |
- Reduce friction first: every minute a secure path costs over the insecure one is a reason to bypass it. Passkeys, single sign-on and self-service access requests remove reasons for workarounds.
- Use secure defaults: configure tools so the easiest path is the secure one, such as external sharing off by default and automatic screen lock.
- Find and use role models: respected engineers, sales leads and assistants shape norms more than the security team. A champions programme gives them a formal role: see the Security Champions Programme Guide.
Rules people can follow
The NCSC's principle 6 warns that rules which are too prescriptive will eventually be detrimental to security, and that vague guidance leaves people exposed. Practical rules for rule writing:
- Separate must from should: label mandatory rules clearly and keep them few; put advice in guidance. People should be able to tell which is which at a glance.
- Test every rule: ask whether it reduces a real risk, whether people can follow it in their actual workflow, and whether it fits the organisation's purpose. Retire rules that fail.
- Write with the people affected: a cross-organisation stakeholder group, as the NCSC suggests, finds the workflow conflicts before rollout.
- Build rules into onboarding and tools: a rule enforced by configuration needs no memorising.
- Archive old versions: make clear when new content replaces old, and remove superseded documents from intranets.
- Give a route to an expert: where a rule does not fit a situation, people need a fast way to ask, not a reason to guess.
Building a culture programme: a phased approach
- Diagnose (months 1 to 2): run a baseline culture survey and interviews, review incident reports for blame language, list known workarounds and exemption requests, and map which norms help and hurt. Use the methods in the Security Culture Measurement Guide.
- Agree purpose and leadership commitments (month 2): write a one-paragraph shared purpose for security in business terms; get each executive to commit to two visible behaviours, such as using passkeys and sharing one security mistake at a team meeting.
- Fix reporting first (months 2 to 4): simplify reporting routes, publish a just culture statement approved by HR and legal, start thanking reporters within one working day, and pilot with two departments.
- Remove top workarounds (months 3 to 6): pick the three most common workarounds from the diagnosis and redesign the controls behind them with the teams affected.
- Recruit champions (months 4 to 8): appoint security champions in each major function and give them time, a channel and early sight of changes.
- Review rules (months 6 to 9): run every security policy through the must and should test, retire or merge, and publish a short version people can read in five minutes.
- Measure and adjust (from month 9, then yearly): repeat the survey, compare reporting rates and exemption requests, and report results to the board alongside technical risk.
Testing and rollback: pilot every change, such as a new reporting button or a simplified rule, with one team before rolling out, and keep the old route working until the new one shows higher use. If a change increases friction or confusion in the pilot, revert and redesign rather than enforce.
Decision guidance by organisation size
| Factor | Small organisation (under 250 staff) | Large organisation |
|---|---|---|
| Who leads | The owner or managing director, with an IT lead or provider | A culture or awareness lead under the CISO, with HR and communications |
| Diagnosis | Conversations with every team and a short survey | Survey with statistical analysis, focus groups, incident data review |
| Reporting route | One named person and one shared mailbox or chat channel | Mail client report button, portal, SOC triage and automated feedback |
| Champions | Not usually needed; leaders are the champions | One champion per function or site |
| Main risk | Informality means no one owns security behaviour | Local subcultures and inconsistent treatment of mistakes |
Where identity fits
Many of the most damaging behaviours involve credentials, and increasingly machine credentials. A healthy culture shows in whether people approve unexpected MFA prompts or report them, whether help desk staff feel able to refuse an urgent reset for a caller claiming to be senior, and whether an engineer who commits an API key to a public repository reports it within minutes or quietly deletes the commit and hopes. Rotating a leaked key in the first hour is easy; finding it weeks later after abuse is not. Make leaked secret reporting explicitly blame-free and fast, and link it to the revocation process in the Secrets Management Guide.
Measuring progress
Pick a small set of indicators that track behaviour rather than knowledge. Definitions and survey design are in the measurement guide; the indicators that best show culture building is working are:
- Reporting rate and speed: the share of simulated and real phishing emails reported, and the median time from delivery to first report.
- Self-reported mistakes: the number of people reporting their own errors, which should rise as safety grows.
- Exemption requests: the number of open policy exemptions, especially from senior staff.
- Known workarounds: the count of documented workarounds still in use.
- Survey items on safety: agreement with statements such as "I would report a security mistake I made without fear of being blamed".
Framework mapping
| Culture building activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Leadership accountability for a risk-aware culture | GV.RR-01 | PM-13 Security and Privacy Workforce | 5.4 Management responsibilities | Control 14 |
| Shared purpose linked to mission | GV.OC-01 | PL-4 Rules of Behavior | 5.4 Management responsibilities | Control 14 |
| Awareness and role-based learning | PR.AT-01, PR.AT-02 | AT-2 Literacy Training and Awareness, AT-3 Role-based Training | 6.3 Information security awareness, education and training | Safeguard 14.1 |
| Easy reporting of incidents and mistakes | RS.MA | IR-6 Incident Reporting | 6.8 Information security event reporting | Safeguard 14.6 |
| Fair, consistent handling of rule breaches | GV.RR-02 | PS-8 Personnel Sanctions | 6.4 Disciplinary process | Control 14 |
| Learning from incidents | ID.IM-03 | IR-4 Incident Handling (lessons learned) | 5.27 Learning from information security incidents | Safeguard 17.8 |
Common failure patterns
- Naming and shaming clickers: publishing simulation failures or sending repeat clickers to compulsory remedial training teaches people to hide real clicks. See the Phishing Simulation Programme Guide.
- Executive exemptions: senior staff excused from MFA or device controls signal that security is optional for anyone important enough.
- Claiming a just culture and acting otherwise: a just culture statement means nothing if the first person who self-reports is disciplined. One case undoes years of messaging.
- Treating workarounds as discipline issues: punishing a workaround without fixing the control behind it moves the workaround out of sight.
- Policy sprawl: dozens of overlapping policies nobody reads, with mandatory and advisory content mixed together.
- Culture as a campaign: a launch month with posters and no change to reporting routes, controls or leadership behaviour, followed by silence.
Lessons from incidents
- Doubt needs a route: in the Arup Deepfake Fraud 2024, a finance employee first suspected the request was phishing, then made 15 transfers totalling HK$200 million after a video call in which every other participant was a deepfake. The fraud surfaced only when he contacted head office about a week later. A culture where checking with head office before acting is expected and praised, backed by out-of-band verification, turns that first instinct into a stopped payment.
- Unexpected prompts should be reported, not approved: in the Cisco Breach 2022, an employee targeted with voice phishing calls and repeated MFA push requests eventually approved one, giving the attacker VPN access. Technical fixes such as number matching come first, but a norm that repeated unexpected prompts are reported to security immediately, without embarrassment, gives defenders an early signal.
Practitioner checklist
- Write a one-paragraph shared purpose for security in business terms and get the executive team to endorse it.
- Publish a just culture statement, agreed with HR and legal, that protects honest mistakes and self-reports.
- Make reporting possible in under a minute through the mail client, chat and phone, and thank every reporter within one working day.
- Ask each executive to commit to two visible secure behaviours and to share one security mistake with their team.
- Remove senior exemptions from core controls such as MFA and device management.
- List the top three workarounds and redesign the controls behind them with the teams affected.
- Separate mandatory rules from advisory guidance and archive superseded policies.
- Make leaked secret and API key reporting explicitly blame-free and tied to fast revocation.
- Appoint security champions in each major function in larger organisations.
- Track reporting rate, time to report, self-reported mistakes and open exemptions, and review them yearly.
Standards and references
- NCSC: Cyber security culture principles
- NCSC: Principle 2, Build the safety, trust and processes to encourage openness around security
- NCSC: Principle 5, Leaders take responsibility for the impact they have on security culture
- NCSC: Principle 4, Social norms promote secure behaviours
- NCSC: The cyber security culture iceberg
- NIST: SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Security Culture Measurement Guide · Security Awareness and Human Risk Management Guide · Security Champions Programme Guide · Top 10 Security Awareness Programme Mistakes