In September 2017, Norwegian broadcaster NRK reported that employees at Statoil, the state oil company, had typed confidential material into the free translation tool Translate.com. Contracts, internal emails, and workforce reduction plans were later found searchable on Google.
Statoil was not alone. NRK found similar exposure from other companies, including a physician’s tax correspondence and a bank’s staff performance report.
No one set out to leak anything. Employees needed a document translated and reached for the fastest available tool. That is the whole story.
The uncomfortable question is not how Statoil got exposed. It is how many organizations are running the same workflow right now, treating translation as an administrative chore instead of a security control, with no incident report to show for it because nothing has surfaced yet.
Why Security Documentation Is Not Ordinary Documentation
A marketing brochure survives a rough translation. A security document does not, because it carries three layers of meaning at once.
The technical layer covers system names, configurations, and tool-specific terms. The security layer covers risks, controls, and the exact actions a procedure requires. The organizational layer covers who the document is for, whether that is an auditor, a system administrator, or an executive who needs a summary rather than a command sequence. A translator who gets one layer right and another wrong produces a document that reads fine and means something different.
The pattern shows up constantly in security terminology. “Least privilege” translated as “minimal permission” loses the connection to role-based access control that the original term implies. “Zero trust” is frequently rendered as something close to “no trust,” which describes a different and incoherent security model.
A standard operating procedure that says “isolate the affected host” can become “quarantine the affected host” in translation, and those two instructions trigger different actions depending on which EDR platform a team uses. None of these are exotic edge cases. They are common outputs from translators who know the source and target languages but not the domain.
Where Things Actually Break
Three situations account for most of the damage.
- Incident response in multilingual teams. Avi Pichette, a product manager at CyberArk, described the risk directly to Runtime.news: an attacker targeting a company’s German branch office has a real advantage if the reporting tool does not translate well from German to English. Response speed depends on everyone reading the same alert the same way, and that breaks down fast across languages.
The same article carries an example from Charles Givre, who at the time led AI for a cybersecurity startup. While helping a Japanese student write a SQL query at Black Hat, he could not figure out why the query failed on the student’s machine. The Japanese keyboard used a different Unicode character for the period. The character looked identical on screen. The query parser read it as something else entirely. Even characters that appear the same are not guaranteed to be the same, and that has direct consequences for anything involving code, logs, or structured data.
- Vendor and third-party documentation. SOC 2 reports, penetration test findings, and security questionnaires from foreign vendors go through the same risk. Machine translation flattens the nuance in a risk statement. An auditor reading a poorly translated control description can miss a material weakness that was clearly stated in the original language but came out vague or misleading on the other side.
- Compliance notices and breach notifications. Washington state law requires breach notices to residents to be written in plain language, and permits state agencies extra time specifically to translate the notice into the affected resident’s primary language.
The FTC’s Health Breach Notification Rule similarly requires notices to avoid unnecessary legal or technical terminology. A badly translated breach notification does not just confuse the recipient. It creates regulatory exposure on top of the reputational damage the breach already caused.
Why Machine Translation and Generic Translators Are Not Enough
Free machine translation tools present two separate problems for security content. The first is accuracy. A generic engine does not reliably distinguish “authentication” from “authorization” in context, and it has no mechanism for maintaining a consistent glossary across a document set. A generic human translator without domain background often makes the same substitutions, and adds inconsistency between documents on top of it.
The second problem is confidentiality. Free online translation tools frequently retain submitted text to improve their models, and that retention is exactly what made the Statoil exposure possible. The documents were not stolen. They were indexed because the tool treated submitted text as reusable data.
Organizations dealing with security documentation across languages typically bring in vendors who specialize in specialized technical translation services and work under NDA with controlled infrastructure, rather than consumer-facing translation platforms that log or reuse submitted content. Elmura Linguistics works with this kind of documentation directly, which is why glossary management and confidentiality handling sit at the center of the process rather than as an afterthought.
Practical Recommendations
A glossary for security terminology should exist before any document goes to translation, not after the first inconsistency gets flagged in review. Public translation tools should be off limits for any document containing system names, credentials, or network diagrams, and that restriction needs to be a written policy rather than an assumption.
Translation quality belongs inside vendor security assessments alongside the usual questions about access controls and data handling. Incident response playbooks should be written in every operating language from the start, not translated as an afterthought once the English version is finished, because a playbook that only exists correctly in one language is only useful to part of the team during an incident.
Conclusion
Translation itself is not the threat. The Statoil case happened because an entire category of confidential material moved through a tool designed for casual, disposable text, and no one along the way treated that movement as a security event.
Companies operating across multiple languages are handling a real attack surface every time a security document, incident report, or vendor assessment crosses a language boundary. The organizations that get this right are the ones that built a translation workflow for security content before they needed one, not after an NRK-style discovery forced the question.
