CyberPlay editorial team · Published · Updated · 8 min read
Guide and exercises in English
Cybersecurity training for banks should connect security decisions to the authority of each role. A branch colleague handling a customer request, an operations team changing payment instructions, and a management body reviewing resilience risks need different practice. Their actions also depend on well-designed controls and escalation routes.
This guide explains the training context of DORA as checked on 13 September 2026 and provides original exercises for programme owners. The scenarios are discussion materials that must be adapted to the bank’s approved procedures. They do not constitute a bank-specific certification or replace specialist, regulatory, fraud-prevention or operational-resilience training.
What you’ll take away
- Make awareness and resilience training relevant to each role’s responsibilities.
- Teach independent payment verification and approved identity checks.
- Rehearse reporting and escalation after an uncertain or mistaken action.
- Keep participation evidence separate from assessed competence and operational outcomes.
Understand the DORA training context
DORA Article 13(6) requires compulsory ICT security awareness and digital operational resilience training for employees and senior management, with complexity appropriate to their functions. Relevant ICT third-party providers are included where appropriate. This is broader than a single phishing module.
EIOPA’s final Q&A 250–3380 explains that frequency and updates should reflect proportionality, role profiles, incident lessons and relevant threat intelligence. It does not provide one universal interval for every employee. Use the regulation and applicable supervisory guidance to approve your programme, then document why the chosen activities and schedule fit the bank’s risks.
Section sources: Regulation (EU) 2022/2554, Article 13(6) · DORA Q&A 250–3380: training frequency and updates
Start with the authority attached to each role
List the actions each group can take and the mistakes that could follow from an unverified instruction. Branch staff may handle identity questions and unusual customer communications. Payment operations may change records or initiate transfers. Service desks may support account access. Managers may approve exceptions or resource decisions.
An employee does not need to become an incident investigator to report concern. Equally, a specialist who can change privileged access needs more than a general awareness exercise. State the boundary in each objective: recognise, verify, hold, report, approve, or carry out an authorised technical procedure. This prevents a broad training label from hiding very different responsibilities.
| Role | Example objective | Suggested practice |
|---|---|---|
| Branch and customer service | Use approved identity and escalation checks | Fictional customer request with incomplete evidence |
| Payment operations | Verify a consequential instruction before changing records | Bank-detail change decision exercise |
| Service desk | Handle an urgent access request through approved identity controls | Support-call role play |
| Management | Assess resilience decisions and unresolved risks | Facilitated service-disruption discussion |
| ICT specialists | Execute assigned operational procedures correctly | Controlled technical training and assessment |
Make payment verification a rehearsed action
The FBI’s business email compromise guidance advises independent verification of payment changes. In a bank programme, translate that principle into the bank’s approved process: identify the instruction, verify through the required channel, apply the appropriate authorisation, and record the decision.
Avoid inventing a universal callback rule for every transaction. Different products, customers and channels may have different controls. The learning exercise should use a procedure approved by the process owner. What matters is that the learner does not treat a persuasive message, familiar name or accurate background detail as permission to bypass that procedure.
Expand image · Game screenshot · English interface
- Find the existing directory
Use the organisation's established helpdesk directory to find a trusted contact before continuing a sensitive request.
- Do not reuse supplied numbers
A number supplied by the caller is part of the request and cannot independently verify it.
Section sources: Business Email Compromise
Use this original payment-change exercise
Give participants a fictional request and a simplified version of the approved workflow. Let them identify the next authorised action before revealing the answer. Ask a process owner to join the debrief so questions about exceptions receive a practical answer.
Practise identity questions without using real customer data
A customer-service scenario can involve a caller who knows several accurate facts but cannot complete the approved identity process. The learner must maintain a helpful tone while explaining the available safe route. The exercise should reward a clear next step, not a hostile refusal or a guess about whether the caller sounds suspicious.
Use entirely fictional customer records and account details. Do not ask staff to bring real cases containing personal data into a group session. If an incident inspires a scenario, remove identifying details and have the relevant owner approve the adaptation. The objective is to practise the process, so realistic pressure and incomplete evidence are more useful than real customer identifiers.
Include the moment after a mistake
Many exercises stop before the harmful action. Add a second stage: the employee has entered information on an unexpected page, approved an unfamiliar prompt, or sent a document to the wrong recipient. Ask them to report promptly, describe the action accurately and follow the authorised response route.
Make it clear who takes over and what the employee should preserve. Do not encourage personal investigation, deletion of evidence, or attempts to negotiate with a suspected attacker. A useful debrief asks whether fear, ambiguity or an unavailable contact might delay reporting. That discussion can expose a process problem that another quiz would miss.
Expand image · Game screenshot · English interface
- Reject an uninitiated request
Deny a sign-in approval you did not initiate, even if another message urges you to accept.
- Report through official support
Contact the established helpdesk or security team and explain when the unexpected approval requests appeared.
Give resilience training a team dimension
Awareness concerns individual decisions, while resilience also involves coordinated work when services are disrupted. Run a separate discussion in which a customer-facing service becomes unavailable and information is incomplete. Ask branch operations, ICT, communications and management to identify their responsibilities and approved communication paths.
Keep the exercise inside its agreed scope. Participants can state decisions and information needs without touching production systems or sending real customer notices. Record assumptions, unresolved dependencies and action owners. A general game can prepare people to recognise and report a suspicious event, but it should not be presented as the bank’s complete resilience-testing programme.
Expand image · Game screenshot · English interface
- Include time and device
Report the observed symptoms, when they appeared, and the affected device through the organisation's approved reporting route.
- Distinguish observation from diagnosis
Separate direct observations from suspected causes so responders can investigate without treating an early guess as fact.
Fit delivery to working conditions
Schedule short, focused practice where it can be completed without competing with customer service. A branch team may need several small sessions; an operations group may need a facilitated scenario involving two approval roles. Verify that the chosen language, device and input controls work for the audience. Offer an equivalent accessible format when they do not.
Use a manager briefing before a sensitive exercise. Explain the learning purpose and what data will be collected. Avoid public individual rankings that encourage people to hide uncertainty. A professional programme can be engaging while treating mistakes as information for coaching and process improvement, with accountability handled through established management arrangements.
Collect evidence with a precise meaning
Retain the programme version, role coverage, assigned learning objectives, participation and the assessment method. Record whether a result came from a knowledge question, an observed discussion, an in-game action or a delayed scenario. These are different kinds of evidence and should not be collapsed into a single claim of “human risk reduced”.
NIST’s Phish Scale provides context for the human difficulty of phishing messages. If the bank compares simulation results, keep challenge difficulty and recipient context in view. Also examine reporting quality and whether employees choose the approved verification route. A person can avoid a click yet still mishandle a payment request through another channel.
Section sources: Phishing With a Net: The NIST Phish Scale and Cybersecurity Awareness
Run a focused pilot before scaling
Select one high-consequence decision and a representative group. Agree the correct process with its owner, observe the activity, and ask participants to explain their next action. Then introduce a changed scenario after a suitable interval. Record both learning gaps and operational obstacles, with named owners for follow-up.
CyberPlay’s general security games can provide a practice component for suitable awareness objectives. Choose a relevant topic and connect the experience to the bank’s procedures. Confirm specific languages, access conditions, reporting needs and technical requirements before wider use. No bank-specific module, certification, deployment model or platform integration should be assumed from a topic label alone.
Put the decision into practice
Explore the relevant CyberPlay games, choose a suitable challenge, and discuss how its decisions connect to your own workplace procedures.
Explore practice gamesSources and further reading
- Regulation (EU) 2022/2554, Article 13(6) — EUR-Lex. Accessed 2026-09-13
- DORA Q&A 250–3380: training frequency and updates — EIOPA. Accessed 2026-09-13
- Business Email Compromise — FBI. Accessed 2026-09-13
- Phishing With a Net: The NIST Phish Scale and Cybersecurity Awareness — NIST. Accessed 2026-09-13
Keep exploring
- Social engineering training exercises: rehearse impersonation and payment checks
Run practical social engineering exercises for fake IT support, supplier payment changes and voice impersonation, with dialogue cards, verification steps and debriefs.
EN · 8 min read - Security awareness training metrics: measure more than completion
Measure security awareness with a practical metric dictionary covering participation, decisions, retention and reporting, plus fair comparisons and clear limits.
EN · 8 min read - Ransomware tabletop exercise for non-technical teams: a facilitator guide
Run a ransomware tabletop for non-technical teams with fictional injects, clear roles, escalation decisions, continuity questions and a downloadable facilitator pack.
EN · 8 min read - Invoice fraud: how to verify a supplier’s bank-account change
Prevent invoice fraud with an independent supplier callback, bank-detail comparison and approval record. Includes a practical finance worksheet and game exercise.
EN · 8 min read - Security awareness for manufacturing: training for shifts and shared devices
Build manufacturing security awareness around shifts, shared terminals, suppliers and escalation. Includes a workforce matrix and a safe discussion exercise.
EN · 8 min read - Security awareness games for employees: how to choose and use them
Choose security awareness games that teach useful workplace decisions. Compare formats, run a sample session, and use a practical evaluation checklist.
EN · 8 min read