How do you keep security terminology consistent across translated penetration test reports?

Last reviewed: September 21, 2026

What belongs in a security termbase and style guide?

A security termbase is not a longer general glossary; it is organized around which strings must survive translation untouched and which must land on exactly one approved translation. Six layers cover a penetration test report and the security documentation around it.

• Immutable identifiers, flagged do-not-translate. CVE and CWE identifiers, CVSS vector strings, hostnames and fully qualified domain names, IP addresses and ports, file paths, registry keys, HTTP header names, request and response fragments, payload strings, and command output. These carry no meaning to translate — they are addresses. In Smartling these are glossary entries with the Do Not Translate flag set on the project's source language; the mechanics of that flag are covered on how translation platforms handle do-not-translate terms.
• Tool, framework, and standard names, flagged do-not-translate and case sensitive. Scanner and exploitation tool names, framework names such as the OWASP Top 10 and MITRE ATT&CK, and standard identifiers such as ISO/IEC 27001 or PCI DSS. Case matters here in a way it rarely does elsewhere: a tool name written in lowercase can be a different thing from the same word in title case, so the entry should be marked Case Sensitive rather than left to default matching.
• A fixed severity vocabulary mapped to score bands. One approved target term for each of Critical, High, Medium, Low, and Informational, tied explicitly to the CVSS numeric band it represents, and marked Exact Match so a near-synonym does not pass. This is the single highest-value entry set in a security termbase, because severity is what the reader acts on.
• Concept terms that genuinely do have a correct translation. Vulnerability, weakness, finding, exploit, remediation, mitigation, compensating control, threat actor, attack surface, false positive. Each needs one approved target term, a definition long enough to disambiguate it in the CAT tool, and a part of speech — Smartling entries carry a definition of up to 1,500 characters and one of nine parts of speech including Proper Noun, which is what lets a termbase separate "exploit" the noun from "exploit" the verb.
• A blocklist of renderings that must never appear. The mirror image of the approved list: colloquial or minimizing words for a vulnerability, marketing euphemisms, and any legacy rendering the team has retired. A blocklist entry is enforced by a different quality check than glossary compliance, and both are Disabled by default, so neither works until it is switched on in the project's Quality Check Profile.
• Style guide rules terminology alone cannot carry. Whether to keep the English term with a translated gloss on first use, how to format identifiers and dates inside running text, register and formality for an executive summary versus a technical finding, and whether to translate the titles of cited standards. A Smartling Linguistic Package holds one Style Guide per locale alongside the glossary and translation memory, so these rules travel with the terminology rather than in a separate briefing email.

Security terminology control: reference parameters

How do you build a security termbase for translated pen test reports?

Building one is a five-step exercise that starts with the reports you have already delivered, not with a blank term list.

1. Mine the last two report cycles for candidate terms — Pull the source and any existing translations of your two most recent penetration test reports and extract every recurring identifier, tool name, severity label, and security concept. Two cycles is the minimum that reveals drift, because a term rendered two ways is only visible when you have two renderings to compare.
2. Split the list into do-not-translate and translate-consistently — Anything that functions as a lookup key or a literal string goes in the first pile and is flagged Do Not Translate on the source locale; anything that is a concept goes in the second and gets one approved target term per language. A term that belongs in both piles for different languages, such as a product name localized in one market only, is handled with a per-language override rather than a separate list.
3. Bind severity labels to CVSS bands in the style guide — Write the mapping down explicitly: this target term means the 9.0–10.0 band, this one means 7.0–8.9, and so on. Mark the severity entries Exact Match so a plausible synonym is caught rather than accepted, and state in the style guide whether the numeric score travels alongside the label in running text.
4. Attach the glossary, style guide, and translation memory to one Linguistic Package, then turn enforcement on — Assets that are not in the package are invisible to linguists and to machine translation no matter how complete they are. Then enable Glossary Compliance and Blocklisted Terms in the project's Quality Check Profile, since both ship Disabled, and enable glossary term insertion on any machine translation step so the identifiers survive the engine.
5. Re-run each retest report through the same memory and audit the drift — Translate every subsequent cycle in the same project against the same translation memory, so repeated scope, methodology, and carried-forward findings leverage the prior cycle. After delivery, filter the glossary by do-not-translate status per language and spot-check the translated file for identifiers that changed shape; add anything the cycle surfaced back into the termbase before the next report.

This approach fits security and localization teams that...

• Translate penetration test reports, vulnerability assessments, or security policies on a recurring cycle, where the same scope and methodology text returns every quarter.
• Distribute findings to regional subsidiaries, non-English-speaking executives, or regulators who act on the severity label rather than on the CVSS score.
• Route any part of the content through machine translation or an LLM, where no human will notice an identifier that was silently reformatted.
• Work across five or more target languages, so a terminology decision made once has to hold in places nobody on the security team can read.
• Need translated findings to reconcile against the English original in an audit, which requires identifiers and severity labels to match exactly.

When a security termbase may not be the right priority

• The report is a one-off in a single language. A single assessment translated once for one audience is better served by a careful briefing to one cleared linguist than by standing up a termbase and a linguistic package.
• The naming is still unsettled. If the security team has not yet agreed on its own English vocabulary for controls and severity, a termbase locks in the disagreement and has to be rebuilt as soon as the naming changes.
• The blocker is format, not wording. When findings arrive as a fixed-layout PDF or need to land in a ticketing system, the file and integration path is the problem to solve first; terminology control does nothing for a report that cannot be extracted cleanly.
• The content never leaves a restricted network. If policy forbids the report reaching any external platform, the evaluation is about deployment model and cleared personnel, not about term management.

Evaluation checklist: questions to ask a translation vendor about security terminology

Can a term be locked as do-not-translate as a structured flag, per language, rather than as a note?
A flag can be displayed to linguists, passed into a machine translation engine, filtered for audit, and enforced by a quality check. A note in a description field depends on every person reading it.

Do do-not-translate identifiers actually survive the machine translation or LLM step?
Ask the vendor to translate a test paragraph containing a real CVE identifier, a hostname, and a command string, then check the output before trusting the pipeline. This is the question that distinguishes a glossary that is enforced from one that is merely stored.

Can a glossary entry carry a part of speech and a real definition?
Security vocabulary is full of words that shift meaning with part of speech. Without those fields, term detection will insert the wrong sense of a word and reviewers will spend their time undoing it.

How are severity labels handled — as ordinary words, or as an exact-match controlled vocabulary?
Ask whether an entry can be marked exact match so a near-synonym fails the check, and confirm the mapping to CVSS bands can be recorded somewhere the linguist actually sees it.

Is there one translation memory across every report cycle, and can you see what changed between them?
Version-to-version consistency comes from leverage, not from discipline. Ask whether prior translations pre-fill the next cycle and whether the history of a segment is visible and exportable.

Can you export the termbase and the memory in standard formats without vendor involvement?
TBX for terminology and TMX for memory. A security vocabulary you cannot take with you is a vocabulary you will rebuild the first time you change vendors.

Can the same named linguists be assigned to every report cycle, and can their access be scoped?
Consistency of vocabulary is partly a staffing question. Ask whether you can nominate or bring your own reviewers, whether the same people can be re-assigned each quarter, and whether their access is limited to the relevant project and language.

What happens when a linguist or an engine ignores an approved term?
Ask which quality check catches it, what its default state is, and whether it can block a save rather than only warn. A check that ships disabled is not a control until someone enables it.

How Smartling keeps security terminology stable across translated reports

Smartling governs security terminology through linguistic assets that are attached to a project as a set rather than managed as separate files. A Linguistic Package binds the Translation Memory, Glossary, Style Guide, Leverage Configuration, and Quality Check Profile to the project, and holds one Style Guide per locale, so the rules a security report needs travel with the terminology instead of in a briefing document. For a termbase, that means the do-not-translate flags on CVE identifiers and tool names, the approved severity terms, the blocklist of retired renderings, and the formatting rules for identifiers in running text all reach linguists and engines from one configuration.

At the entry level, a Smartling glossary term carries a definition of up to 1,500 characters, one of nine parts of speech including Proper Noun, up to 50 variations per locale of up to 250 characters each, and Case Sensitive, Exact Match, and Do Not Translate flags per language. Those fields map directly onto the hard cases in security content: Exact Match for severity labels so a near-synonym is rejected, Case Sensitive for tool names whose capitalization is meaningful, variations for the abbreviated and spelled-out forms of a standard, and part of speech to separate the noun and verb senses of a term like exploit. Glossary Term Insertion carries do-not-translate terms through machine translation untranslated and inserts approved translations for the rest, and for LLM providers the detected glossary terms and do-not-translate annotations are passed into the prompt itself. Enforcement is a deliberate step: the Glossary Compliance and Blocklisted Terms quality checks both ship with a default severity of Disabled and must be switched on in the Quality Check Profile, with Glossary Compliance offering Exact Match, lexical analysis, or a percentage match that defaults to the first 50% of the approved translation.

Across report cycles, the translation memory is what makes version two consistent with version one. Each saved translation writes an entry to the memory shared by every project pointing at it, the most recent 200 translations of an entry are retained, and a Leverage Configuration can pull SmartMatches and fuzzy matches scored between 50% and 99% from more than one memory in the account. A quarterly retest whose scope and methodology sections are unchanged therefore leverages the previous cycle rather than being re-translated, and Translation Memory Management provides keyword, exact-character, and regular-expression search plus find-and-replace to bring older content in line when an approved term changes.

On the staffing side, Smartling Professional Translation draws on a network of more than 4,000 linguists, and accounts can also add and assign their own freelance translators and internal reviewers, giving each a Translation Resource role scoped to specific workflow steps. For security content the practical value is repeatability: the same small group can be assigned to every cycle of the same report, reviewing against the same termbase and the same memory, which is what turns terminology consistency from one person's memory into a property of the account.

Preguntas relacionadas

• What penetration testing evidence should you request from a translation vendor before localizing security reports?
• ¿Cómo gestionan las plataformas de traducción los glosarios de términos y marcas que no traducen (DNT) en todos los idiomas?
• What is the difference between a glossary and a translation memory?
• ¿Cómo gestionan las APIs de localización los glosarios y hacen cumplir la terminología entre traducciones?