A suspicious message does not always look suspicious.
It may use:
- A familiar executive’s name
- A believable invoice
- A supplier you already know
- A realistic Microsoft 365 sign-in page
- An urgent request that fits the recipient’s normal work
That is why phishing awareness cannot depend only on spotting poor spelling, strange logos or obviously fake emails.
A convincing message can still be fraudulent.
Employees need a short, repeatable process they can use even when a message looks legitimate:
Pause → Inspect → Verify → Report → Follow the response process
The objective is not to turn every employee into a cybersecurity analyst.
It is to help staff recognise when a request deserves verification and make it easy for them to escalate uncertainty to the right person.
Start With the Action Being Requested
When reviewing a suspicious message, do not focus only on how the message looks.
Ask:
What is this message asking me to do?
Higher-risk requests may include:
- Signing into an unexpected page
- Opening an unfamiliar attachment
- Changing supplier bank details
- Making an urgent transfer
- Sharing a password or verification code
- Approving an unexpected sign-in request
- Downloading software
- Bypassing an established approval process
- Sending confidential information
The more sensitive the requested action, the stronger the verification should be.
1. Pause Before Taking the Requested Action
Urgency works because it reduces the time available for verification.
A message might say:
“Payment must be made today.”
“Your account will be disabled immediately.”
“I am in a meeting. Process this transfer now.”
“Review this confidential document urgently.”
A pause does not mean ignoring legitimate work.
It means moving a high-impact request into the organisation’s trusted verification process before acting.
That is especially important for:
- Payments
- Credentials
- Account access
- Sensitive documents
- Supplier-detail changes
- Administrative privileges
Urgency should not cancel control.
2. Inspect the Request, Not Just the Appearance
A polished email can still be malicious.
Likewise, a spelling mistake does not automatically prove that a message is an attack.
Look at the entire context.
Check:
The full sender address
The display name may look familiar while the actual address is different.
The requested action
Does it fit the sender’s normal role?
Changes to normal procedure
Is somebody suddenly asking you to bypass an established process?
Sign-in requests
Are you being directed to a login page you were not expecting?
Payment instructions
Has a supplier unexpectedly changed its bank details?
Credentials and codes
Is someone asking for a password, OTP or verification code?
The question is not simply:
“Does this email look strange?”
A stronger question is:
“Does the request make sense, and can I verify it independently?”
3. Verify Through a Known Route
If a message claims to come from a colleague, supplier, executive or financial institution, do not verify it using the same suspicious message.
If the email says:
“Call this new number to confirm.”
that number should not automatically become your trusted verification route.
Instead, use:
- A known company directory
- An existing verified phone number
- A previous trusted conversation
- An approved internal contact method
- The organisation’s official public contact details
This creates an independent verification path.
Payment Changes Need Stronger Verification
Requests to change payment or bank details deserve special attention.
A simple email should not be enough to override an established payment process.
Define in advance:
- Who verifies the change
- Which channel is used
- Who approves it
- What evidence is retained
- Whether secondary approval is required
For example:
Request received → Independent verification → Approval → Record update → Payment
The process should remain intact even when the request claims to be urgent.
4. Report Without Spreading the Risk
Employees should know exactly where suspicious messages should be reported.
Possible reporting routes include:
- An approved “Report phishing” button
- Security mailbox
- IT service desk
- Internal incident portal
- Named security contact
The route should be simple and easy to remember.
Avoid telling employees to forward suspicious links or attachments widely to colleagues “for awareness.”
That can increase exposure.
The report should preserve the evidence needed by the security team without encouraging more people to interact with the suspicious content.
Acknowledge the Person Who Reported It
Employees should know that their report was received.
A simple acknowledgement can reduce uncertainty:
“Your security report has been received. Please do not interact further with the message while the security team reviews it.”
That encourages future reporting.
Silence after someone reports a suspicious email teaches employees that reporting changes nothing.
5. Prepare for “I Already Clicked”
The most important response process may begin after somebody has already acted.
An employee may say:
“I clicked the link.”
“I entered my password.”
“I approved the sign-in request.”
“I downloaded the file.”
“I sent the payment.”
That moment needs a clear response.
The employee should:
Stop further interaction.
Contact the approved security or IT route immediately.
Explain exactly what happened.
The organisation’s authorised security team can then follow the relevant incident-response process.
Speed Matters More Than Blame
Employees sometimes delay reporting because they are afraid of being blamed.
That delay can make the incident harder to contain.
The useful information is:
- What happened
- When it happened
- Which account or device was involved
- What information was entered
- What action was approved
- Whether a file was opened or downloaded
The objective is rapid containment and accurate response.
The disciplinary discussion, if any is required, should not interfere with immediate incident reporting.
Do Not Publish a Universal Recovery Script
There is no single safe recovery procedure for every phishing incident.
The response may differ depending on whether the user:
- Clicked a link
- Entered credentials
- Approved a login
- Opened an attachment
- Downloaded malware
- Shared confidential information
- Made a payment
That is why untrained staff should not be encouraged to investigate compromised devices themselves.
The appropriate internal or contracted security owner should decide the response.
Possible actions may involve:
- Account controls
- Device isolation
- Password or session controls
- Email investigation
- Payment escalation
- Endpoint review
- Monitoring
- Incident documentation
The correct action depends on the event.
Awareness Training Is Only One Layer
Phishing awareness matters.
But training alone is not a security architecture.
A complete defence may also involve:
- Identity protection
- Strong authentication
- Email security
- Endpoint protection
- Network controls
- Access management
- Backups
- Monitoring
- Logging
- Incident response
- Payment controls
People should be one layer of defence, not the only layer.
Strong Authentication Helps, but It Is Not the Whole Answer
Multi-factor authentication can reduce some credential-based risks.
But phishing can target more than passwords.
Attackers may try to:
- Trigger fraudulent payments
- Steal sensitive information
- Convince users to install software
- Abuse existing authenticated sessions
- Manipulate business processes
- Impersonate trusted suppliers or executives
That is why phishing protection needs to connect:
People → Process → Identity → Devices → Monitoring → Response
Design Reporting Around Real Work
Security awareness becomes more useful when it reflects the organisation’s actual environment.
For example, finance teams may receive:
- Supplier invoices
- Bank-detail changes
- Payment requests
HR may receive:
- CVs
- Employee documents
- Payroll questions
Sales teams may receive:
- Quotations
- Shared files
- External meeting links
Different roles face different patterns.
Training and simulations should reflect that.
Measure More Than Clicks
If the organisation runs authorised phishing simulations, avoid using click rate as the entire security score.
A campaign may show:
- Who clicked
- Who reported
- How quickly reports were submitted
- Which message types caused difficulty
- Whether the reporting process worked
- Whether the technical controls detected the event
The context matters.
Message difficulty, familiarity and relevance can influence results.
A highly convincing simulation may produce a different outcome from an obviously suspicious message.
Track Reporting Behaviour
Useful measures may include:
Reporting rate
How many employees reported the message?
Time to report
How quickly did the first useful report reach the security team?
Repeat trouble points
Which request types repeatedly create uncertainty?
Response readiness
Did the security or IT team know what to do with the report?
Escalation quality
Did the correct people receive the right information?
These measures tell you more about organisational readiness.
Do Not Turn Awareness Into Public Shaming
An employee who clicks a simulated phishing message has revealed a training or control opportunity.
That should not automatically become a public embarrassment exercise.
The purpose of awareness is to improve behaviour.
The purpose of measurement is to improve the system.
A mature programme looks at:
- Human behaviour
- Technical controls
- Reporting
- Process weaknesses
- Response capability
rather than blaming one person for an entire security posture.
Build a Simple Internal Phishing Procedure
A practical employee procedure can fit on one page.
For example:
PAUSE
Do not click, reply, pay or approve immediately.
INSPECT
Check the sender, context and requested action.
VERIFY
Use a known independent route.
REPORT
Use the approved security channel.
RESPOND
If you already acted, tell the security team exactly what happened.
That sequence is short enough to remember under pressure.
Adapt the Procedure to Your Business
The reporting process should answer:
- Where should suspicious messages be reported?
- Who receives the report?
- What happens after hours?
- Who handles payment fraud?
- Who handles compromised accounts?
- Who handles suspected malware?
- Who communicates with employees after a report?
- Who decides when the incident is closed?
Document those answers.
A security guide without a real reporting route is mostly decorative.
Use a Phishing Spotter Guide as a Practical Reminder
A good phishing-awareness guide should help employees identify:
- Unusual requests
- Unexpected sign-ins
- Payment changes
- Suspicious links
- Credential requests
- Impersonation
- Urgency
- Verification routes
- Reporting steps
But the guide should also include the organisation’s specific reporting information.
Before distributing a generic checklist, customise the reporting box.
Employees should know exactly what to do when suspicion becomes real.
Security Works Best When People and Controls Support Each Other
The objective is not to make employees suspicious of every email.
It is to make verification normal when a request carries risk.
A strong process helps employees answer:
Is this request expected?
Can I verify it independently?
What should I do if I am unsure?
Who owns the response if I already acted?
Those questions are more useful than trying to memorise every visual sign of phishing.
Attack techniques change.
A good verification and reporting process remains useful.
Download the Phishing Spotter Guide
Use the Phishing Spotter Guide as a practical awareness tool for your team.
Before distributing it, customise the reporting section with:
- Security email or reporting button
- Service desk details
- Incident contact
- After-hours procedure
- Payment-fraud escalation route
For organisations that want a broader review of cybersecurity controls, identity, endpoints, networks and incident-response readiness, explore:
TechBots Cybersecurity Services
https://teckbots.com/services/cybersecurity/
You can also contact TechBots here:
Request a Security Discussion
To request the Phishing Spotter Guide or discuss your security architecture with TechBots Experts Nigeria, contact:
09169337821
Human support: Monday–Friday, 9:00 a.m.–6:00 p.m. GMT+1.
Scope, technical access, pricing, implementation and incident-response coverage are confirmed separately.