Employee cybersecurity training in Cairo: practise before the urgent message arrives

1. Prepare a 28-minute workshop around real work

Consider a fictional Cairo office-supplies business. Purchasing works at its office, dispatch at a separate stockroom, and the owner sometimes works remotely. Messages help coordinate deliveries, but staff cannot always confirm a request face to face. This exercise tests that gap without sending deceptive messages to employees.

Choose one facilitator, a named reporting contact and a backup. Bring printed cards or accessible text, with no working links, attachments or real customer details. Offer Arabic or English discussion and a written response option. Write the actual internal contact route before starting.

• Minutes 0–4: explain the goal and reporting contacts.
• 4–8: demonstrate the verification steps.
• 8–17: discuss three cards, three minutes each.
• 17–22: compare the answer key and role actions.
• 22–26: complete one report.
• 26–28: agree one improvement and its owner.

2. Rehearse pause, independent verification and reporting

NIST's phishing guidance recommends verifying urgent requests using contact information obtained independently of the message and teaching staff how to report concerns. Turn that principle into a repeatable routine:

1. Pause the requested action. Do not open the proposed file, transfer money, share a code or send a customer list while the request remains unverified.
2. Identify the decision. Ask what would change: a payment destination, access to information or an account sign-in?
3. Use a trusted route. Call a number already held in the approved supplier record, use the internal directory, or open a service through a saved trusted address. Do not use the replacement number supplied by the questionable message.
4. Check authority and record the result. Confirm who requested the action and who may approve it. If either remains unclear, report and keep the action paused.

A familiar name or conversation history is not sufficient verification. If the normal contact cannot be reached, use the named backup; urgency does not create new authority.

3. Read three fictional message cards

For each card, write: requested action; what needs checking; trusted contact route; and who receives the report. These are discussion prompts, not messages to send to staff.

Card A: the supplier changes bank details

“Our bank details changed today. Pay this order to the new account before the delivery slot closes. Call the number below if you need confirmation.”

Card B: the manager needs an urgent file

“I'm between meetings. Open the attached revised dispatch sheet, then send today's full customer list to the address inside. Please do this before I call.”

Card C: support asks for a one-time code

“Your account needs a quick check. Send me the login code that just arrived so I can finish fixing the problem.”

No attachment, account number or login code is included in the exercise. Participants should explain a safe next action rather than try to prove who wrote the message.

4. Compare the answer key

1. Card A: leave the payment details unchanged. Purchasing contacts the supplier using its existing approved record. Finance follows the established approval process for any confirmed change before payment. Calling the new number would let the same message supply both the claim and its supposed proof.
2. Card B: do not open the attachment or export the list. Reach the manager through the internal directory and ask what task requires which information. Even a genuine request needs the appropriate approval and minimum necessary data. An approved shared workspace may already contain the dispatch information.
3. Card C: do not disclose the code or approve an unexpected login. Contact support through the service's established route. Enter a login code only in the legitimate sign-in flow you deliberately initiated, never in a message to a caller.

None of these cards proves that a real sender is malicious. They show why the requested action needs checking. The authentication and authorization guide explains why identifying an account and permitting an action are separate decisions.

5. Give each role an action it can actually take

Have the stockroom participant explain the same route without relying on someone sitting beside them. If a phone directory or reporting channel is unavailable there, record that as a process defect. Use the customer data protection guide when deciding which records may be shared.

6. Complete a reusable reporting worksheet

Copy these fields into your existing private reporting channel. The exercise uses invented details only.

• Observed: date, time and channel.
• Request: the action requested, in one sentence.
• Concern: what remains unverified.
• Actions already taken: for example, opened a file, clicked a link, shared information, or none.
• Verification: trusted contact attempted and result.
• Owner: reporting contact, acknowledgment and next step.

Example: “10:10, supplier message; requested new payment destination; change unverified; no transfer made; existing supplier number called, no answer; finance backup informed.” Do not include passwords, codes, tokens or full customer records. Preserve any real suspicious message for the designated reviewer through the approved process; do not circulate it to colleagues.

7. Measure the process without shaming people

At the end, count how many groups identified an independent contact route, avoided sharing a code, and named the reporting backup. Record missing process information, not a public ranking of employees. Repeat one fictional card at the next team meeting and check whether the agreed improvement works.

Set one concrete action, such as “operations owner makes the approved supplier directory available to dispatch before the next workshop.” A rise in reports can mean people feel safer speaking up; it does not by itself show that security has worsened.

Gammal Tech offers hosted website functions, including login. Choosing those tools is separate from arranging staff training and maintaining this reporting routine.

Common questions

What if someone already clicked?

Ask them to report promptly and describe what happened without blame. The designated technical contact handles assessment; employees should not investigate the message themselves.

Does correct spelling make a message safe?

No. Practise checking the requested action and verifying through an independent route, even when the wording looks professional.

Does this require simulated phishing software?

No. The complete workshop uses visible fictional cards, discussion and a private worksheet. It collects no credentials and sends no live phishing messages.