DORA's Translation Requirements for ICT Risk Documentation
- 18 hours ago
- 10 min read
What does DORA require from translated ICT risk documentation? The answer is not a single standard template or a one-size-fits-all language rule. Regulation 2022/2554 creates layered, jurisdiction-specific translation obligations that many compliance officers at EU banks, insurers, and investment firms are still miscalibrating. The documents affected span ICT risk management frameworks, major incident reports, third-party ICT service agreements, and threat-led penetration testing (TLPT) reports. Each carries distinct language requirements depending on which national competent authority (NCA) supervises your entity, and translation errors in any of them carry direct regulatory consequences.
Table of Contents
Key Takeaways
Point | Details |
No uniform language rule | DORA’s translation obligations vary by NCA jurisdiction, document type, and submission format. |
Four core document categories | ICT risk frameworks, incident reports, third-party contracts, and TLPT reports each carry separate translation obligations. |
Financial entity accountability | Regulators hold the financial entity responsible for translation accuracy, regardless of who performed the translation. |
Certified standards are the baseline | ISO 17100, ISO 18587, and ISO 27001 define quality and security controls appropriate for DORA-regulated submissions. |
Version control is a compliance control | Translated documents must remain synchronized with their originals through the full document lifecycle, including annual review cycles. |
What DORA requires from translated ICT risk documentation
DORA does not contain a dedicated “translation article,” which is where the confusion starts. Instead, translation obligations emerge from cross-border reporting duties, NCA supervisory powers, and the technical standards that govern how documents are submitted. The practical scope is wider than most teams initially assume.
Four document categories carry the most direct translation exposure:
ICT risk management framework documentation. Articles 5 through 16 of DORA require financial entities to maintain a documented ICT risk management framework. When a supervisory authority requests this documentation in its working language, the entity must deliver a compliant translation. Risk frameworks must be reviewed at least annually and after significant changes, meaning translated versions must track every material update.
Incident classification and reporting templates. Major ICT-related incident reports follow a structured reporting timeline of initial notification within 4 hours, an intermediate report within 72 hours, and a final report within one month, all governed by RTS 2025/301 and ITS 2025/302. Each submission must meet the language expectations of the receiving NCA, under time pressure that leaves no room for translation delays.
Third-party ICT service agreements. Articles 28 and 30 of DORA prescribe mandatory contractual clauses for ICT third-party providers. Where those contracts govern services subject to NCA oversight, the authority may require a version in its working language. Intra-group arrangements are not automatically excluded from this scope.
Threat-led penetration testing (TLPT) reports. TLPT is mandatory for significant entities under Article 26. Reports involve sensitive technical findings that require precise terminological rendering in translation. Mistranslating scope definitions or remediation conclusions creates direct supervisory risk.
The Register of Information sits in a separate category. RoI submissions use xBRL-CSV format covering approximately 200 data fields across 15 templates defined in ITS 2024/2956. The structured data fields themselves are not subject to narrative translation requirements. However, any narrative documentation accompanying the RoI submission follows NCA language rules. This distinction between machine-readable data and narrative documentation is one that compliance teams frequently conflate.
Operational language requirements are found not in the Level 1 DORA text but in Level 2 and Level 3 documents published by the European Supervisory Authorities (ESAs) and individual NCAs. Monitoring only the regulation text leaves compliance teams without the full picture.
How to prepare compliant translated ICT risk documents
Meeting DORA’s translated ICT risk compliance obligations is a workflow problem, not just a language problem. The following sequence reflects the controls that supervisory audits will examine.
Map documents to NCA language requirements. Begin by identifying every NCA with supervisory jurisdiction over your entity. For each authority, determine its working language and any published guidance on submission language. Entities operating across multiple EU countries must manage this mapping as a living register, not a one-time exercise.
Establish version control linked to the source document. Every translated document must carry a version identifier that corresponds to the source version. When the ICT risk framework is updated following an annual review, the translated version must be updated before the next submission cycle closes.
Apply certified translation standards. ISO 17100 and ISO 18587 govern translation service quality and post-editing of machine translation output respectively. These are the standards regulators and auditors reference when assessing whether a translation process was fit for purpose. ISO 27001 controls apply to information security throughout the translation process, which matters when documents contain sensitive operational or vulnerability data.
Use an AI+HUMAN hybrid translation workflow for volume and precision. Legacy machine translation (MT) produces literal output with weak context handling. Consumer-grade neural machine translation (NMT) engines carry inconsistent terminology control and governance gaps that are incompatible with regulated submission requirements. An AI+HUMAN hybrid approach, where a subject-matter expert reviews LLM-generated output against client terminology assets, addresses both throughput and accuracy requirements.
Archive translations with audit traceability. Supervisory requests can arrive without warning. Every translated document must be retrievable with its version history, the date of translation, the translator or system credentials, and the QA record. This archive is a compliance artifact, not just an operational convenience.
Schedule legal and cross-functional review. For documents such as third-party ICT contracts and TLPT reports, translation review must include legal and technical subject-matter experts, not only linguists. Regulatory terminology in these documents carries legal weight that general translation review cannot adequately assess.
Pro Tip: Build your NCA language mapping directly into your ICT risk governance calendar. When you schedule the annual framework review required under DORA Article 6, trigger the translation update workflow at the same time. This prevents the common pattern of compliant source documents sitting alongside outdated translated versions during an audit.
Deciding what to translate under DORA
Not every document requires translation into every NCA language, and over-translating can create unnecessary version control burden. The decision framework below helps compliance officers determine where translation is required.
Document type | Translation required? | Trigger condition |
ICT risk management framework | Yes, on NCA request | NCA working language differs from document language |
Major incident reports (initial, intermediate, final) | Yes | Submission to NCA in its working language |
Third-party ICT service agreements (Article 30) | Conditional | NCA supervisory review or audit request |
TLPT reports (Article 26) | Yes | Submission to lead overseer or NCA with jurisdiction |
Register of Information (xBRL-CSV data fields) | No | Machine-readable structured format, language-neutral |
RoI narrative documentation | Yes, on NCA request | NCA requires working language submission |
Intra-group ICT contracts | Conditional | Determined by NCA jurisdiction and materiality |
The proportionality principle in Article 4 of DORA limits certain obligations for smaller or less complex financial entities. However, Article 4 does not reduce the language compliance obligation for documents you are already required to submit. If the document is in scope, the translation requirement follows from the NCA’s working language. There is no proportionality carve-out for translation quality.
English functions as a supervisory working language in some EU jurisdictions, but this is not a DORA provision. It reflects individual NCA practice. Legal responsibility for all submitted documentation, including translations, rests solely with the financial entity’s management body. Assuming English sufficiency without NCA confirmation transfers a regulatory risk that the compliance function cannot absorb.
Pro Tip: Request a written confirmation of accepted submission languages from each NCA at the start of your annual compliance planning cycle. File this as a dated reference document. If the NCA later raises a language objection, this record demonstrates good-faith due diligence and may limit enforcement exposure.
Common failures in DORA translation compliance
The pattern of translation-related compliance failures in regulatory submissions follows predictable lines. Recognizing these in advance is the most efficient form of risk mitigation.
Mismatched source and translated versions. The ICT risk framework is updated following a material change, but the translated version sent to the NCA reflects the prior version. This creates a factual discrepancy that regulators interpret as either negligence or a governance failure.
Terminology drift across document types. Incident reports, risk frameworks, and third-party contracts use overlapping technical vocabulary. Without a controlled term base, translators working on different documents independently produce different renderings of the same regulatory concept. Auditors cross-referencing documents will identify the inconsistency.
Delayed incident reports due to translation bottlenecks. The 72-hour intermediate reporting window under DORA’s incident reporting regime does not accommodate slow translation workflows. If your process routes documents through manual translation with no pre-approved terminology assets, you will miss deadlines.
Inadequate security controls on document handling. Translated TLPT reports contain sensitive vulnerability data. Routing this content through public-cloud or consumer-grade translation tools creates data exposure that violates both ISO 27001 controls and GDPR data processing requirements.
Relying on internal bilingual staff without certified QA. A bilingual compliance officer is not an equivalent substitute for a certified translation process. The accountability standard DORA enforcement applies is whether the process was fit for regulated submission, not whether someone on the team spoke the language.
Mitigation requires embedding translation compliance into the document lifecycle governance framework, not treating it as a downstream step. Every document that may be submitted to an NCA should have a translation workflow defined before it is needed, with terminology assets pre-loaded and certified QA steps documented.
Where AD VERBUM fits in DORA translation compliance
For ICT risk managers evaluating translation service options against DORA requirements, the certification baseline matters before any other capability discussion. AD VERBUM holds ISO 17100, ISO 18587, and ISO 27001 certifications, which are the quality, post-editing, and information security standards that financial sector regulators reference when auditing translation processes. These are not marketing credentials. They are the documented control framework your audit trail will need to reference.
AD VERBUM’s AI+HUMAN hybrid translation workflow is built for exactly the conditions DORA creates. The process begins with ingesting your existing Translation Memories and Term Bases so that all output is constrained by your established ICT risk terminology from the first word. The proprietary LLM-based LangOps System then generates target-language output with document-level context handling, not sentence-level processing. A certified subject-matter expert, selected from AD VERBUM’s network of 3,500+ specialist linguists, reviews for technical accuracy, regulatory compliance, and contextual nuance. QA is aligned to ISO 17100 and ISO 18587.
The infrastructure runs on private EU-hosted servers with no reliance on outsourced public cloud tooling for core processing. For TLPT reports and incident documentation containing sensitive operational data, this matters. For a regulated document translation workflow that produces audit-ready output, this is the architecture required.
Pro Tip: When evaluating any translation provider for DORA-regulated submissions, request their ISO 17100 and ISO 27001 certificates and ask specifically how they handle terminology governance across multi-document translation projects. The answer will tell you whether they can maintain consistency across your risk framework, incident reports, and third-party contracts simultaneously.
Adverbum’s compliance translation services for DORA
AD VERBUM works with financial institutions, insurers, and investment firms that cannot treat translation as an afterthought in their DORA compliance documentation cycle. If your entity operates across multiple EU jurisdictions, the multi-language submission requirements alone justify a purpose-built process rather than ad hoc arrangements.
AD VERBUM’s compliance translation services cover 150+ languages including regional variants, with turnaround 3 to 5 times faster than traditional workflows. The private EU-hosted infrastructure satisfies data sovereignty requirements for sensitive ICT risk content. If you are drafting vendor requirements for a translation provider, the guide on creating a compliance RFP provides a structured starting point aligned to regulated sector expectations.
My take on where compliance teams get this wrong
I have reviewed enough regulatory translation processes to say with confidence that the most expensive failures are not the ones where someone used the wrong language. They are the failures that result from treating translation as a production step rather than a governance control.
When your ICT risk framework is a living document reviewed annually under DORA Article 6, the translation of that document is also a living artifact. I have seen entities with excellent English-language risk documentation submit stale translated versions to NCAs because no one connected the document review trigger to the translation update workflow. The NCA receives a document that does not match the current internal framework. That is a governance gap that no amount of post-hoc explanation fully closes.
The second pattern I see repeatedly is the assumption that English is a safe default for cross-border supervision. In some jurisdictions it is. In others it is not, and the NCA will not necessarily tell you proactively that your submission is in the wrong language. They will raise it at the worst possible moment. Confirming accepted submission languages in writing, at the start of each compliance cycle, costs almost nothing and eliminates that risk entirely.
What I find genuinely underappreciated is the role of terminology governance. When incident reports, risk frameworks, and third-party contracts all go through different translators or translation tools without a shared term base, the same DORA concept ends up rendered differently across your submission portfolio. Cross-referencing is standard practice in supervisory reviews. Terminology drift is not just a quality issue. It reads as inconsistency in your compliance posture.
The practical fix is not complicated. Connect translation compliance to your document governance calendar. Certify your process to the standards auditors check. Use tooling that enforces terminology across your full document set. These are operational decisions, not technical mysteries.
— Viestarts
FAQ
What documents must be translated under DORA?
DORA requires financial entities to provide translations of ICT risk management framework documentation, major incident reports, third-party ICT service agreements, and TLPT reports when submitted to an NCA that operates in a language different from the document’s source language.
Does the DORA Register of Information require translation?
No. The Register of Information is submitted in xBRL-CSV format covering 200+ data fields, which is machine-readable and language-neutral. Narrative documentation accompanying the RoI may still require translation based on NCA requirements.
Who is legally responsible for translation accuracy under DORA?
The financial entity’s management body is solely responsible. Legal accountability rests with the entity regardless of whether translation was performed internally or by a third-party provider.
What translation standards apply to DORA-regulated submissions?
ISO 17100 governs translation service quality, ISO 18587 governs post-editing of machine translation, and ISO 27001 governs information security controls. These three standards define the certified baseline for financial sector regulatory translation.
Can English be used for all DORA submissions across EU jurisdictions?
No. English is accepted as a supervisory language in some jurisdictions based on individual NCA practice, but this is not a DORA provision. Compliance officers should confirm accepted submission languages in writing with each relevant NCA before submitting documentation.
Sources
DORA ICT third-party risk register methodology
Key aspects of the EU’s DORA regulation according to Spain’s CNMV
DORA Documents Library Guide
DORA Register of Information Guide
Our Approach | AD VERBUM
Recommended