5 Best Practices for Your Cybersecurity Safety Moment in the Workplace

A cybersecurity safety moment is a short, repeatable discussion that helps a team practice one useful behavior before an incident happens. It should be specific enough to use in a meeting, brief enough to repeat, and safe enough that employees can ask questions or report mistakes without being blamed.

Use the five practices below as a five-minute routine. They complement your organization’s security policies and incident-response process; they do not replace instructions from your IT or security team. The goal is to turn general awareness into actions people can remember when a message, login prompt, device, or file request feels wrong.

Key takeaways

• Pause before acting on unexpected requests, and verify them through a separate, known channel.
• Use unique passwords and the strongest multi-factor authentication available.
• Keep approved devices and apps current, locked, and under your organization’s controls.
• Handle company data only through approved storage, sharing, and network paths.
• Report suspicious activity and mistakes quickly, with a process designed for learning rather than blame.

How to run a five-minute cybersecurity safety moment

Choose one practice for each meeting. Start with a realistic prompt, ask the team what they would do, then confirm the organization’s approved action and reporting route. End with one behavior to use that week. Short, repeated sessions are easier to apply than a long annual list of warnings. NIST’s current learning-program guidance treats awareness, practical exercises, and role-based training as parts of a program intended to encourage behavior change and build a security culture.

Keep the discussion close to the team’s work. Finance may practice verifying a changed payment request. Customer support may review how to handle an identity document. A remote team may rehearse what to do when a device is lost. The example should make the correct next step obvious.

1. Pause and verify unexpected requests

Phishing can arrive by email, chat, text message, social media, or a phone call. Attackers may impersonate a manager, supplier, colleague, or familiar service. Poor grammar can be a warning sign, but polished and personalized messages can be malicious too. Treat the request itself as the evidence: unexpected urgency, a new payment destination, an unfamiliar attachment, a request for credentials or an MFA code, or pressure to bypass a normal process.

When a request could expose money, credentials, company data, or access:

• Stop before opening the attachment, following the link, replying, or approving the request.
• Verify the person or organization through a separate channel you already trust. Use a saved number, an official website, or an internal directory rather than contact details in the message.
• Report the message through your organization’s approved route. Preserve the details the security team needs, then follow its instructions about deleting or isolating the message.

CISA’s phishing guidance emphasizes recognizing suspicious requests, verifying independently, reporting the attempt, and deleting it. The useful habit is not “spot every fake.” It is “pause and verify before the request can do harm.”

2. Use unique passwords and stronger MFA

Each work account should have a unique password or passphrase. A reputable password manager can generate and store long, unique credentials, which removes the need to invent predictable variations. Do not teach arbitrary password rotation or a required mix of uppercase letters, numbers, and symbols as the main defense. Current NIST password guidance tells verifiers to allow length, block common or compromised values, avoid composition rules, and require a password change when there is evidence of compromise rather than on a fixed schedule.

Turn on multi-factor authentication wherever your organization supports it. MFA makes account takeover harder, but it is not a guarantee. Never approve a login prompt you did not initiate, and never share a one-time code. Prefer phishing-resistant methods such as security keys or FIDO/WebAuthn when available. CISA’s MFA hierarchy places authenticator apps with number matching above one-time codes, and recommends text or email codes only when stronger choices are unavailable.

If you entered a password on a suspicious site, approved an unexpected prompt, reused a compromised password, or sent a code to someone else, report it immediately. Fast reporting gives the security team a chance to reset credentials, revoke sessions, and check for misuse.

3. Keep approved devices and apps current

Use devices, operating systems, browsers, extensions, and apps that your organization approves. An official app store or familiar vendor name reduces some risk, but it cannot guarantee that software is safe. Follow your organization’s approved-app catalogue or mobile-device-management rules, remove software you no longer need, and let managed security controls do their job.

• Install security updates promptly or enable the organization’s managed update process.
• Use a screen lock and keep the device physically controlled.
• Do not disable endpoint protection, encryption, or management settings to make a task easier.
• Report a lost, stolen, or unexpectedly behaving device as soon as possible.

NIST’s mobile-device guidance recommends controls that match the organization’s device and BYOD model. Signing a policy is not the control by itself; supported-device rules, approved apps, timely updates, access controls, monitoring, and a clear loss-reporting process are what make the policy useful.

When a device leaves service, follow the organization’s approved media-sanitization and disposal process. A generic factory reset is not a universal promise that every kind of storage has been cleared. NIST SP 800-88 Rev. 2 ties the sanitization method and its validation to the media, the sensitivity of the information, and the organization’s requirements.

4. Handle company data through approved paths

Before storing, sending, or sharing a file, check its sensitivity, the people who need access, the required region, and the approved tool. Use the least access necessary, review recipients before sending, and remove access when the work is finished. If your team is still choosing a service, use a structured process for selecting an approved cloud storage provider rather than moving work into a personal account.

Encryption is one control, not a guarantee against every breach. Outcomes also depend on identity controls, permissions, endpoint security, sharing settings, recovery, and the threat path. For Hivenet storage workloads specifically, the current Hivenet Trust page states that files are encrypted before storage, split into fragments, and distributed across nodes inside the selected region. That architecture should not be generalized to every Hivenet product or treated as immunity from misuse or compromise.

Use your organization’s managed VPN or network path when its policy requires one. A VPN can encrypt traffic between the device and the VPN endpoint, including potentially clear-text traffic on a public network, as described in the NIST Mobile Threat Catalogue. It does not make a user anonymous, prove that a site is trustworthy, or prevent phishing, malware, unsafe sharing, or a compromised device.

HTTPS protects the connection between a browser and a domain. It does not prove that the business behind the domain is legitimate. Check the full domain, reach sensitive services through a trusted bookmark or internal portal, and verify unusual payment or identity requests separately.

5. Report quickly and without blame

Employees often see the first sign of an incident: an unexpected login alert, a suspicious MFA prompt, a misdirected file, a lost phone, a message sent to the wrong recipient, or a device behaving unusually. Reporting that signal quickly can reduce the impact. Make the route easy to find, explain what details to include, and tell people what will happen next.

A useful report includes:

• what happened and when;
• which account, device, file, or message was involved;
• what the employee clicked, entered, approved, sent, or observed; and
• any immediate action already taken.

Do not ask employees to investigate beyond their role or hide a mistake while they try to fix it alone. Preserve relevant evidence, follow the organization’s instructions, and let the incident team decide the next technical steps. NIST’s learning-program guidance treats practical exercises and phishing campaigns as opportunities to develop behavior and improve the program. Public blame and shame discourage the fast reporting the organization needs.

Facilitator checklist

1. Choose one of the five practices and one example that matches the team’s work.
2. Ask, “What would you do first?” before giving the answer.
3. Confirm the approved tool, policy, or reporting route.
4. Correct one misconception without turning the session into a test.
5. End with one behavior the team can use immediately.

Repeat the routine with new examples. A good cybersecurity safety moment makes the safest action easier to remember and easier to report.

Frequently asked questions

What is a cybersecurity safety moment?

It is a brief workplace discussion or exercise focused on one cybersecurity behavior. It connects the organization’s policy to a realistic decision an employee may face.

How often should a team run one?

Choose a cadence the team can sustain and repeat. A short monthly or meeting-based routine can be more useful than a long list delivered once, especially when examples reflect current work and reporting routes.

Are HTTPS and a VPN enough to make online work safe?

No. HTTPS protects a connection to a domain, and a VPN can protect traffic to its endpoint. Neither proves that a request is legitimate or prevents phishing, malware, unsafe permissions, or a compromised device.

What should an employee report?

Report suspected phishing, unexpected MFA prompts, exposed or misdirected data, lost devices, unusual account activity, credentials entered on a suspicious page, or anything else covered by the organization’s incident procedure. When in doubt, use the approved reporting route and let the security team assess it.