Most security teams communicate with the rest of the organisation only when something goes wrong or when a training deadline is due, so staff learn to skim, delete or distrust anything with "security" in the subject line. Internal security communications is the planned, everyday flow of messages from the security function to employees and leaders: newsletters, intranet pages, chat channels, leader talking points and the replies people get when they report something. Done well, it makes the reporting route obvious, explains rule changes before they bite and gives leaders words they are comfortable saying. This guide covers the communications plan, audiences, channels, message design, leader messaging, measurement and governance. It is written for security awareness leads, CISOs and internal communications partners. Incident-time messaging has its own guide, linked below, and the wider culture model is covered in the Security Culture guide.
Key takeaways
- Plan communications like a campaign, not a bulletin. Set behaviour outcomes, know each audience, pick channels on purpose and measure outcomes, following a structure such as the UK Government Communication Service OASIS model.
- Every message should ask for one action. Report it, turn it on, check it, update it: a newsletter item without a clear action is noise competing with real work.
- Publish how security will and will not contact staff. A known sender, a known format and a "we will never ask for your password" rule make fake security messages easier to spot.
- Leaders carry more weight than the security team. The NCSC board toolkit asks senior leaders to talk openly about cyber risk in town halls, internal communications and team meetings, and to follow the rules themselves.
- Measure reports, not opens. Reporting volume, time to report and action completion show behaviour; open rates show only that an email arrived.
What internal security communications covers
Internal security communications sits between awareness training and culture. Training builds knowledge on a schedule; culture is the set of norms that decide what people actually do; communications is the steady channel that keeps both alive between courses. NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program (September 2024), frames awareness as one part of an organisation-wide learning programme aimed at behaviour change, with metrics and evaluation built in. Communications is the delivery layer for much of that awareness work.
It is also a formal requirement. ISO/IEC 27001:2022 clause 7.4 asks the organisation to decide what to communicate, when, with whom and how, and clause 7.3 asks that people are aware of the policy, their contribution and the implications of not conforming. A security newsletter, a policy change notice and a "how to report" intranet page are all evidence for those clauses when they are planned and recorded.
| Activity | Purpose | Typical owner | Rhythm |
|---|---|---|---|
| Awareness training | Build baseline knowledge and role skills | Security awareness lead, L&D | Annual plus onboarding and role change |
| Internal security communications | Keep behaviours current, explain changes, signpost reporting | Security awareness lead with internal comms | Weekly to monthly, plus change-driven notices |
| Incident communications | Tell staff what to do during a live incident | Incident commander with comms lead | Fixed cadence during the incident |
| Culture programme | Shape norms, leadership behaviour and psychological safety | CISO with HR and leadership team | Multi-year |
This guide stays in the second row. For live incidents see Employee Communications During a Cyber Incident; for the training plan itself see the Security Awareness Plan Template.
Building the communications plan
The Government Communication Service OASIS framework is a practical skeleton for a security communications plan because it forces outcomes before outputs. Its five steps are Objectives, Audience insight, Strategy and ideas, Implementation, and Scoring and evaluation. Applied to security:
- Objectives: write behaviour outcomes, not outputs. "Raise suspected phishing reports from finance by 30% this half year" is an objective; "send 12 newsletters" is an output. Tie each objective to a risk in the register, for example payment fraud or credential theft.
- Audience insight: find out what each group already does and what stops them. Use help desk tickets, reported-phish data, exemption requests and short interviews. A workaround reported by three teams is a message (or a control fix) waiting to happen.
- Strategy: choose a small number of key messages for the period, the channels that reach each audience and the messengers they trust (line managers, champions, executives). Map messages to moments: joining, changing role, travelling, year-end payments.
- Implementation: build a calendar with owners, approvals and dependencies, aligned with the internal comms team's own calendar so security does not collide with pay changes or reorganisation news. Reuse national campaign material where it fits: CISA and the National Cybersecurity Alliance run Cybersecurity Awareness Month every October around four steps (strong unique passwords with a password manager, multifactor authentication, recognising and reporting phishing, and updating software). See the Cybersecurity Awareness Month Toolkit.
- Scoring: agree the metrics before launch (see Measuring whether communications work) and review them at the end of each quarter.
Pilot and roll back: trial a new format (a chat digest, a video series) with one business unit for a month, compare action rates with a control group, and drop it if it does not move behaviour. Retiring a channel is a decision, not a failure; announce where the content now lives.
Audiences and what each needs
One all-staff message cannot serve everyone. Segment by risk and by what people control, then write for the group.
| Audience | What they need from security | Best channel | Example message |
|---|---|---|---|
| All staff | How to report, what security will never ask, a few core habits | Intranet hub, short monthly newsletter, onboarding | "Use the Report button. You will never be in trouble for reporting." |
| Finance and payments | Payment change verification, fraud patterns, escalation contacts | Team briefing, targeted email before quarter end | "Any change to supplier bank details is checked by phone on a number we already hold." |
| Help desk and IT support | Caller verification steps, current impersonation tactics | Shift briefings, knowledge base banner | "Reset requests for admins need a video check with the line manager." |
| Engineers and developers | Secrets handling, dependency and token changes, where to ask | Engineering chat channel, champions, pull request templates | "Leaked a key? Rotate first, report second, no blame." |
| People managers | Talking points, what to do when a team member reports or clicks | Manager briefing pack, monthly leader note | "Thank the reporter, then tell security. Do not investigate yourself." |
| Executives and assistants | Targeting they face, verification for urgent requests, their role as messengers | One-to-one briefing, short written note | "If a request sounds like you, we will call you to confirm." |
| Frontline and deskless staff | Short, practical, device-light guidance | Team huddles, posters with QR to intranet, SMS | "Shared tablet? Sign out at the end of every shift." |
Small organisations: two segments (everyone, and the people who move money or have admin rights) are enough. Large organisations: agree segments with internal comms and HR so security uses the same distribution lists, languages and approval paths as the rest of the business.
Channels: choosing and using them
Pick channels by what the message must do, not by habit.
| Channel | Good for | Weak for | Practical rules |
|---|---|---|---|
| Security newsletter (email) | Monthly round-up, stories, recognition, one featured action | Urgent action, anything needing a reply | Three to five items, one action each, same sender and send day every time |
| Intranet security hub | The permanent "source of truth": how to report, rules, contacts, verification page | Driving new behaviour on its own | Owner and review date on every page; top task (report) above the fold |
| Chat channel (Teams, Slack) | Quick questions, champion network, short tips | Policy, anything needing a record | Moderated, named responders, pinned "how to report" message |
| Leader cascades and town halls | Why security matters, priorities, changes that affect work | Detailed instructions | Two-minute talking points, one story, one ask |
| In-product and in-tool prompts | Just-in-time nudges (external email banner, sharing warnings) | Long explanations | Few and specific; banner fatigue sets in quickly |
| Posters, screens, QR codes | Deskless sites, reminders of the reporting route | Anything that changes often | Refresh quarterly; link to the hub, not to a file |
| Reporter feedback (reply to a report) | Closing the loop, the highest-trust message security sends | Bulk messaging | Reply within one working day; say what happened and thank them |
The newsletter that gets read
- Lead with the action: the subject line and first line state what to do and why it matters this month, for example "Check your MFA app before the 1 December change".
- Use real, local stories: an anonymised, thanked report ("a colleague in accounts spotted a fake invoice and saved a five-figure payment") beats a headline about a distant breach. Get the reporter's agreement first.
- Recognise people, not clicks: name teams with high reporting rates; never name people who failed a simulation.
- Keep a fixed shape: one featured action, one story, one "ask us" answer, one reminder of how to report. Readers learn where to look.
- Make it accessible: WCAG 2.2 (a W3C Recommendation since December 2024) sets text alternatives for images (1.1.1), a 4.5:1 minimum text contrast (1.4.3) and link text that makes sense in context (2.4.4). Avoid tips locked inside images. See Neurodiversity and Awareness Training for format choices.
Writing security messages people act on
Security writing fails when it is long, frightening or full of jargon. A message works when a busy person can read the first two lines and know what to do.
- One action per message: if there are three asks, send three messages over three weeks or put them in a numbered list with the most important first.
- Plain language: write for the reader, not the auditor. The US Plain Writing Act of 2010 makes plain language a legal requirement for federal public content, and the same discipline applies internally: short sentences, everyday words, active voice ("Turn on", not "It is required that ... be enabled").
- Explain why in one sentence: "Attackers use stolen passwords first, so a second factor stops most of them" earns more compliance than "per policy IS-04".
- Frame security as enabling work: the first NCSC culture principle is to frame cyber security as an enabler that helps the organisation meet its goals. Write "this keeps payroll running" rather than "you are the weakest link".
- Avoid fear as the main lever: alarm without a clear, doable action leads to avoidance. Pair every threat description with the specific step that reduces it.
- Separate must from should: mandatory rules and advice look different on the page, matching the NCSC principle that rules and guidelines are well maintained, accessible and easy to understand.
- Never link to a sign-in page: tell staff to open the tool they already use. Security emails that contain "click here to log in" teach the exact habit phishing exploits.
Make your own messages verifiable
The NCSC phishing guidance advises that staff know the normal ways of working for key tasks so unusual requests stand out, and it suggests telling suppliers and customers that you will never ask for their password. Apply the same idea inside the organisation: publish a short "How security contacts you" page.
| Element | What to publish |
|---|---|
| Sender | The one mailbox and display name used for security messages, and the chat account that posts announcements |
| Never list | We will never ask for your password, MFA code or remote access, and never ask you to install software from an email link |
| Verification | Where to confirm any instruction: the intranet hub, or a call to the service desk on the published number |
| Reporting | The Report button, the chat channel and the phone number, each usable in under a minute |
| Format | A consistent label or banner, so a message without it is worth questioning |
The same rules support help desk defences; see the Vishing and Help Desk Social Engineering Awareness Guide.
Messaging leaders trust and repeat
The NCSC board toolkit says board members set the tone for cyber security culture, should follow security policies themselves (asking for special treatment signals that bypassing them is acceptable) and should communicate openly about cyber risks and policies through town halls, internal communications and team meetings. It also says the board should listen to people across the organisation, not only push messages down. Security communications should make that easy.
- Talking points, not slides: give leaders three sentences per topic: what is changing, why it matters to their area, what their team should do. Leaders repeat what they can say without notes.
- Personal stories: invite a senior leader to share a time they nearly fell for a scam or reported something. Admitting a near miss signals that reporting is normal.
- Business language: talk about keeping customers served, payments safe and deadlines met. Translate control names into outcomes.
- Visible compliance: when an executive enrols in a new MFA method first, say so in the newsletter. When an exemption is refused for a senior person, the story travels faster than any poster.
- Listening routes: include a leader question in each cascade ("what security step slows your team most?") and report back what changed. This turns a broadcast into a loop.
- Success metrics in leader packs: the NCSC toolkit suggests focusing on success, for example how many people reported a phishing email rather than only how many clicked. Give leaders their team's reporting numbers, not a list of names.
For formal board reporting see the Board Cyber Risk Reporting Guide; this section is about the informal voice leaders use with their own teams.
Communicating about reporting and mistakes
The single most valuable thing internal communications can do is make reporting quick, safe and rewarded. The NCSC phishing guidance asks for a reporting process that is clear, simple and quick to use, feedback to reporters so they see their contributions make a difference, and no punishment or blame culture, including for people who clicked and later realised. It notes that HR, support teams and senior management need to back that message.
- Say it often: "You will never be in trouble for reporting, even if you clicked" belongs in onboarding, every newsletter footer and the hub.
- Show outcomes: a monthly line such as "You reported 412 suspicious messages; 37 were real attacks we blocked across the company" proves reporting works.
- Close every loop: automated acknowledgement within minutes, a human or templated outcome within a working day.
- Handle simulation results with care: share aggregate results and lessons, never league tables of individuals. See the Phishing Simulation Programme Guide.
- Include non-human mistakes: a leaked API key or token pasted into a public repository needs the same blame-free, report-fast message for engineers as a phishing click does for everyone else.
Measuring whether communications work
NIST SP 800-50 Rev. 1 builds metrics and evaluation into the learning programme life cycle, and the OASIS scoring step separates outputs, outtakes and outcomes. Use the same split.
| Level | Metric | Source | What good looks like |
|---|---|---|---|
| Output | Messages sent on schedule, hub pages within review date | Comms calendar, intranet CMS | All pages reviewed within 12 months |
| Outtake | Newsletter click-through on the featured action; hub visits to the reporting page | Email and intranet analytics | Rising trend after each campaign |
| Outtake | Recall of the reporting route in a two-question pulse survey | Survey tool | Most respondents name the Report button correctly |
| Outcome | Suspected phishing reports per 100 staff, and time from delivery to first report | Report button and mail security logs | More reports, faster first report |
| Outcome | Completion of the requested action (MFA method enrolled, device updated) | Identity provider, endpoint management | Target reached by the campaign deadline |
| Outcome | Self-reported mistakes and near misses | Incident and service desk tickets | Steady or rising, a sign of trust |
Treat open rates with caution: mail privacy features and security scanners can inflate or distort them. Prefer actions you can see in system data. For indicator design see the Security Culture Measurement Guide and the Security Metrics and KPIs Programme Guide.
Governance, approvals and working with internal comms
- Partner, do not bypass: agree with the internal communications team who owns the calendar, the brand and all-staff lists. Security brings content and risk judgement; internal comms brings reach and tone.
- Fast approval path: pre-approve templates (newsletter, policy change notice, scam alert) with HR and legal so routine messages need only the security lead's sign-off. Reserve full review for policy changes and anything touching monitoring or discipline.
- Scam alerts: keep a pre-approved template for "a phishing campaign is targeting staff" with the lure description, what to do and what not to do. It must be sendable within an hour.
- Champions as amplifiers: give the security champions network early sight of messages and a short local version to share in team meetings.
- Records: keep the plan, calendar, final messages and metrics. They are audit evidence for ISO/IEC 27001 clauses 7.3 and 7.4 and for the awareness controls below.
- Privacy: analytics on who opened or clicked are personal data; agree with the privacy team what is collected, how long it is kept and that it is not used for discipline.
Framework mapping
| Framework | Reference | How communications supports it |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 | Leadership fosters a risk-aware culture; leader messaging and visible compliance |
| NIST CSF 2.0 | PR.AT-01, PR.AT-02 | Awareness for all personnel and for specialised roles; segmented messages |
| NIST SP 800-53 Rev. 5 | AT-1, AT-2, AT-2(2) | Awareness policy and procedures, literacy training and awareness, insider threat awareness content |
| NIST SP 800-53 Rev. 5 | PM-13 | Security and privacy workforce development |
| ISO/IEC 27001:2022 | Clauses 7.3, 7.4; Annex A 6.3, 6.8 | Awareness, planned communication, awareness and training control, information security event reporting |
| CIS Controls v8.1 | Control 14 (Safeguards 14.1, 14.6) | Security awareness programme; training staff to recognise and report incidents |
Common failure patterns
- Only speaking in a crisis: if the first message staff ever get from security is an urgent incident notice, they have no way to tell it from a fake. Regular, recognisable communication builds that baseline.
- Newsletters that list threats with no action: a digest of global breach headlines informs the security team, not staff. Every item needs an action relevant to the reader.
- Security emails that look like phishing: external tools, unfamiliar senders, "click to verify" buttons and urgency. Staff who are told to distrust such emails then distrust yours, or worse, learn to trust the pattern.
- Naming and shaming: publishing who failed a simulation cuts reporting. The NCSC phishing guidance warns against a punishment or blame culture.
- Executive exemptions in plain sight: messaging that "everyone must" while leaders visibly opt out undoes months of content.
- Stale intranet pages: an old reporting address or a departed contact on the hub sends reports into the void. Owner and review date on every page.
Practitioner checklist
- Write a one-page communications plan with three to five behaviour objectives tied to risks, using an OASIS-style structure.
- Agree audiences, distribution lists, calendar and approvals with internal communications and HR.
- Publish an intranet security hub with the reporting route at the top, an owner and a review date on every page.
- Publish a "How security contacts you" page with a never list and a verification route.
- Run a monthly newsletter in a fixed shape: one action, one local story, one answer, one reporting reminder.
- Give leaders quarterly talking points and their team's reporting numbers, and ask for one question back.
- Acknowledge every report automatically and give outcome feedback within one working day.
- Keep pre-approved templates for scam alerts and policy changes that can go out within an hour.
- Check messages against WCAG 2.2 basics: alt text, contrast and meaningful link text.
- Review outcome metrics (reports per 100 staff, time to first report, action completion) each quarter and retire formats that do not move them.
Standards and references
- NCSC: Cyber security culture principles
- NCSC: Board toolkit, developing a positive cyber security culture
- NCSC: Phishing attacks, defending your organisation
- NIST: SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program
- Government Communication Service: Guide to campaign planning, OASIS
- CISA: Cybersecurity Awareness Month
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2
- Digital.gov: Plain language guide
Related NHI Mgmt Group resources: Security Culture · Security Champions Programme Guide · Security Awareness Plan Template · Employee Communications During a Cyber Incident · Human Risk and Security Culture Executive Briefing