Recognising phishing without blaming your team

Make checking normal, not personal

A busy office needs people to open messages, answer questions and pay suppliers. Asking those same people to distrust every email is not a workable security plan. For an East Kootenay business, the better goal is a routine that makes unusual requests easy to check and possible mistakes easy to report.

Phishing messages try to look legitimate. The Canadian Centre for Cyber Security notes that they can include convincing logos, relevant subjects and familiar-looking content.[1] Recognising one is not a test of intelligence. Give staff permission to pause, confirm and ask for help, including when a request appears to come from the owner.

Look at the request, not just the spelling

Good spelling does not make a message safe. CISA warns that phishing can have perfect grammar and spelling.[2] Look for a request that does not fit the work you expected to do:

• Pressure: an urgent deadline, threatened account closure or demand for personal or financial information. These are recognised warning signs.[2]
• An unexpected detour: a familiar task suddenly requires a new sign-in page, attachment or payment process. Unexpected messages and mismatched links deserve checking.[3]
• A security exception: instructions to install an application, change security settings or enable document macros. Microsoft identifies these as warning signs.[3]

Expand the sender details rather than relying on the display name. Even a message from someone you know needs context before you open its links or attachments.[1]

Verify through a contact you already trust

If a request feels unusual, do not use its reply button, phone number or link to verify it. CISA recommends reaching the person another way, using known contact details or contact information from a verified website.[2]

For business payments, use the supplier number already held in your approved records. Ask whether they requested the change and confirm the details. A number printed on the new invoice is not an independent check. If you cannot reach the right person, hold the change rather than letting the deadline decide.

For an account warning, open the service through your saved bookmark or type its known address yourself instead of using the message link.[1] Ask IT if the warning still needs checking.

A hypothetical invoice change

This example is hypothetical, not a customer story. An office manager at a Cranbrook business receives an invoice from a regular supplier. The amount looks right. A note says the supplier has changed banks and needs payment today.

The office manager leaves the payment pending and calls the number in the existing supplier record. The supplier says no change was requested. The manager reports the message to IT and alerts the person responsible for payments through the usual internal channel.

The useful habit was checking the changed instruction, not spotting a typo. Microsoft notes that attackers use compromised mailboxes to send messages inside and outside an organisation.[4] A familiar sender alone is not enough to approve new banking details.

Give staff a reporting checklist

Choose one reporting route and a backup phone contact. The Cyber Centre recommends reporting suspicious work messages to IT and following their instructions, without forwarding the email to coworkers.[1] Put this checklist somewhere staff can find it without opening the suspect message again:

• Stop interacting. Do not reply, open attachments or follow more links.
• Use the approved reporting button or contact IT through the known help channel.
• Say when it arrived, who it appeared to come from and which account or device was involved.
• Explain what happened: viewed only, clicked, downloaded, entered a password, approved a sign-in or sent payment.
• Keep the original message and note the approximate time. Ask IT how to preserve or submit it safely.
• Do not send passwords, verification codes or suspect attachments through ordinary chat or email.

Managers can respond with: “Thanks for telling us. What happened next?” Do not require proof of an attack before accepting a report.

After a click, respond to what happened

If you clicked only: stop interacting with the page and tell IT promptly. Explain whether anything downloaded or opened. A click, an opened file and a submitted password are different events. Let IT assess the next step rather than trying to diagnose it yourself.

If you entered credentials or approved an unexpected sign-in: contact IT immediately through a trusted channel. Use a different, trusted device to change the affected password through the real service, with IT guidance.[1] Tell IT if that password was reused elsewhere, without sharing it.

A password change is not the whole response. Microsoft’s administrator guidance also covers revoking active sessions, checking sign-in methods and removing suspicious mail forwarding.[4] Leave those checks to the administrator.

If a file ran: stop using the affected device, contact IT and follow their isolation instructions. If payment went out: alert finance and contact the bank promptly about suspected fraud.[3] Do not wipe the device, clear browser history or delete messages while the incident is being assessed. Preserve the information responders need.

Build a workflow that supports people

Training helps people recognise requests worth questioning. It cannot replace safeguards around email, accounts and payments. Microsoft describes layered email filtering and protection against unsafe links and attachments; the Cyber Centre also recommends secure client portals for routine document collection.[3][1]

Start with a few manageable improvements:

• Require a trusted callback and a second approval for supplier banking changes.
• Keep supplier contacts current and name a backup approver.
• Ask IT to review email filtering and multifactor authentication, which adds a check beyond the password.[2]
• Practise reporting with short examples from everyday tasks, without naming or shaming staff.
• Review near misses for process changes, not a person to blame.

The practical goal is shared responsibility: people can pause, managers respect the pause, and technical controls support both.