Why does phishing simulation need to be multilingual?

An English-only phishing simulation against a workforce that operates in multiple languages produces unrepresentative results. Employees who do not read English fluently either click out of confusion (inflating click rate without measuring real risk) or treat anything in English as suspicious (deflating click rate without measuring real risk). To measure phishing susceptibility honestly, simulations must run in the language each employee actually works in.

What does GDPR or NIS2 say about employee-language training?

GDPR Article 32 requires "appropriate organisational measures" - interpreted by data protection authorities as training that employees can actually understand. Several EU national authorities have issued guidance making clear that English-only training in non-English-majority workforces does not meet the standard. NIS2 inherits the same expectation and adds explicit awareness training obligations on in-scope entities.

How many languages does a phishing simulation platform need to support?

There is no fixed number - the answer is "every language a meaningful share of your employees use day-to-day." For most multinationals that means English plus 4 to 8 others, weighted to where headcount lives. For language coverage in product, prioritize the languages that cover the largest share of your headcount and add coverage as you expand.

Should phishing emails be machine-translated or written natively?

Native is materially better for two reasons. First, machine translation often produces tells (awkward phrasing, wrong honorifics, calque-style errors) that signal the email is not genuine - which is exactly the wrong skill to teach. Second, lure conventions vary by language and culture (a phishing pretext that works in US English may not exist as a recognizable scam in Japanese or German). A serious multilingual platform localizes templates rather than translates them.

How do reports work across languages?

Reports should consolidate by metric, not by language - meaning a single global dashboard that shows click-through rate, completion rate and time-to-remediation across all language cohorts, with optional breakouts by language for executives who care. Reports rendered separately per language fragment the data and make trend analysis impossible. Tagging users with their preferred language at import is what enables this consolidation.

Does the training module also need to be multilingual?

Yes. Auto-assigned remediation training that fires the moment a user clicks a phishing simulation has to land in the user's working language, or it does not land at all. Training delivered in a language the user does not read is a check-the-box exercise - auditors and insurers can both see through it.

Multilingual Phishing for Global Teams

Multilingual Phishing Simulation: Running Campaigns Across Languages

The largest tenant on this platform runs phishing simulations against 60,000 employees across a dozen countries. Half of them do not work in English day to day. If you have ever tried to read a credible phishing report from a global program that ran a single English-only campaign across that workforce, you already know the problem: the click-through rate is meaningless. People who could not read the email confidently treated the whole thing as suspicious; people who half-read it clicked. Neither group taught you anything about how susceptible your workforce actually is.

Multilingual phishing simulation is not a feature checkbox. It is the difference between a program that produces real risk data and one that produces noise.

Why monolingual programs miss in global teams

An English-only phishing simulation against a multilingual workforce hits two failure modes simultaneously, and they cancel each other out in ways that look convincing on a slide deck.

The first failure mode: employees who do not read English fluently treat the email as suspicious by default. They are not exercising phishing-recognition skill - they are exercising language-recognition skill. They flag the email because they cannot read it, not because they spotted the lure. Under-clicking gives you a low click-through rate that looks like a healthy program; the actual security gap is invisible.

The second failure mode: bilingual employees in the middle of their day read enough English to follow the cue but not enough to spot the language tells. They click out of half-comprehension. Over-clicking gives you elevated click-through that gets blamed on the user when it should be blamed on the test.

Average those two failure modes across a workforce and the report looks plausible - somewhere in the 8-15% click-through range. It is not. It is two opposite errors averaging into a comfortable middle. The remediation training auto-assigned to clickers lands in English; users who could not read the lure cannot read the training either; nothing measurably changes; the next quarter's report shows the same number.

What "multilingual" actually means in a phishing platform

Three implementations of multilingual support exist, and they are not equivalent.

English-only with auto-translation - the platform stores templates in English and machine-translates at send time. This is the worst pattern. Machine translation produces awkward phrasing, wrong honorifics, calque-style errors and the wrong cultural register. Those are the same tells that distinguish bad phishing emails from good ones - meaning the simulation teaches users to recognize machine-translated text, not phishing. Real attackers writing for non-English markets do not use machine translation; they hire native speakers or use AI fine-tuned for native output.
User-selectable language - each user picks a preferred language at sign-up. Better, but two failure modes still apply: users who never set a preference get the default (usually English); and language preference is a user opt-in, not a workforce reality.
Profile-driven language with native-localized templates - the platform stores the user's working language as a profile field (set during import or pulled from HRIS), templates are written natively per language (not translated) and reporting consolidates across languages with optional breakouts. This is the only pattern that produces honest risk data.

Native localization is the harder lift. It means the phishing template library has to grow per language - a 5-category × 3-difficulty matrix in five languages is 75 distinct templates instead of 15. Operators who get it right amortize the lift by writing once per language and reusing across thousands of customers.

What regulators expect

The compliance angle on multilingual training is firmer than people think. GDPR Article 32 requires "appropriate technical and organisational measures" for personal data security, and several EU data protection authorities have published guidance reading "appropriate" as "training the employee can actually understand." The CNIL in France and the AEPD in Spain have both gestured at this in enforcement actions involving multinationals where security awareness was delivered only in English to French- or Spanish-majority offices.

NIS2, in force across EU member states from 2024, makes this more explicit. The directive's Article 21 obligations include "basic cyber hygiene practices and cybersecurity training" for in-scope entities. Read against the same "appropriate" standard, training in a language a meaningful share of employees do not understand will not survive a serious audit. For more on how NIS2 obligations map to a phishing program, see our NIS2 Directive: EU Phishing Training Requirements walkthrough.

The same logic applies under more general regimes - ISO 27001 Annex A.6.3 ("Information security awareness, education and training") does not specify language but is interpreted by certification auditors against the same "fit for purpose" rule. If your workforce operates in five languages, training in one language is not fit for purpose.

What to evaluate when picking a multilingual platform

Reasonable buyer questions to put on the platform shortlist:

How many languages does the template library cover natively (not via machine translation)?
For each supported language, how many templates are available across the difficulty tiers (easy, regular, hard)?
Does training content (the post-click remediation module) exist in each supported language, or only the lure email?
How is a user's language assigned - manual selection, CSV import field, HRIS pull or system locale?
Does reporting consolidate across languages with breakouts, or fragment per language?
Are the localized templates updated when source-language templates are updated, or do localized versions drift?
For SMS phishing (smishing) and voice phishing (vishing), does language coverage extend to those channels - or is it email-only?

The last question separates serious multilingual platforms from email-only ones. SMS and voice attacks against a global workforce hit even harder because mobile devices auto-detect language and hide the cue that something is foreign - a Spanish-language SMS sent to an English-only office gets dismissed as spam; the same SMS to a bilingual employee gets read in Spanish and clicked through. For the broader case on multi-channel coverage, see our piece on auto-assigned phishing training.

Reporting across languages without losing the signal

The single biggest failure mode in multilingual reporting is fragmenting metrics by language. A program that reports "English: 4.2% click rate, Spanish: 7.1%, German: 3.8%, Japanese: 9.3%" gives an executive no way to talk about the program as a whole - and worse, invites the wrong follow-up question ("why is Japanese so bad?") that often has nothing to do with security and everything to do with which Japanese-speaking team got the test.

The right reporting pattern: a single consolidated metric (organization-wide click-through rate, organization-wide completion rate, organization-wide time-to-remediation) with the language axis available as a drill-down for the cases where it matters. Most of the time it does not - phishing susceptibility correlates with role, tenure and template difficulty far more strongly than with language. Treat language as a tag, not a partition. For more on what executive reporting should actually contain, see phishing simulation metrics that actually matter to executives.

Where Bait & Phish fits

Bait & Phish supports multilingual templates and language-tagged users out of the box, with reporting that consolidates across language cohorts. The platform was built for global programs from the start - not retrofitted later - which is why language is a first-class field in the user profile rather than a metadata afterthought. If you are running a global phishing program and your current platform is forcing a language choice, contact us and we will walk through how the language model maps to your workforce. Or start a free trial up to 25 users in the language of your pilot cohort.

Related program operations and how-to guides

15oct