DORA is in force. NIS2 transposition is underway. Regulators now ask about terminology governance — and a shared Excel file is no longer a passing answer.
Last verified: 2026-04-17 · Primary sources: DORA (Regulation (EU) 2022/2554), NIS2 (Directive (EU) 2022/2555), MiFID II (Directive 2014/65/EU), AICPA SOC 2 TSC.
The Digital Operational Resilience Act (DORA) has applied to EU financial entities since 17 January 2025. The NIS2 Directive is being transposed into national law across member states. Financial regulators — BaFin, FCA, AMF, DNB — are actively examining how organizations govern their operational resilience documentation.
One area that catches teams off guard: terminology governance.
Compliance teams at banks, payment providers, and investment firms typically manage regulatory definitions in spreadsheets, Word documents, or unstructured Confluence pages. These definitions — “ICT incident,” “critical or important function,” “threat-led penetration testing” — drive incident reporting, risk assessments, and regulatory filings. When they are inconsistent, downstream documents inherit the inconsistency.
This is not a theoretical concern. DORA explicitly requires financial entities to establish governance frameworks for ICT risk management (Article 5) and to maintain comprehensive ICT documentation (Article 9). Terminology that drifts between documents undermines both requirements.
“Terminology governance” is not a regulatory term of art. But the underlying requirements — documented definitions, change control, approval workflows, evidence of review — appear across every framework that FinTech and banking compliance teams operate under.
Financial entities must have an internal governance and control framework that ensures effective and prudent management of ICT risk. The management body defines, approves, oversees, and is responsible for the implementation of the ICT risk management framework. In practice: if your ICT risk framework references terms that lack formal definitions, version control, or approval records, the governance requirement is not fully met.
Financial entities must document all ICT-supported business functions, information assets, and ICT assets. This documentation must be kept up to date and available to competent authorities on request. Terms used in that documentation must be defined consistently — an auditor reviewing your asset register and your incident classification taxonomy will compare definitions.
Essential and important entities must adopt governance measures for cybersecurity risk management, including policies on risk analysis, incident handling, business continuity, and supply chain security. Each of these policies uses terms that must be defined, agreed upon, and applied consistently across the organization.
CC6.1 requires logical access controls with clearly defined roles. CC7.2 requires monitoring for anomalies. Both depend on precisely defined terms — what constitutes an “anomaly,” who is an “authorized user,” what qualifies as “sensitive information.” Auditors reviewing your SOC 2 Type II report will verify that these definitions are consistent and governed.
Article 9(6) requires investment firms to have at least two persons effectively directing the business — the four-eyes principle. This dual-control requirement extends to critical documentation: definitions that govern regulatory reporting should not be created and approved by the same person.
Compliance Glossary is a Confluence app that replaces spreadsheet-based terminology management with governed, auditable workflows. Every capability maps directly to what regulators examine.
The person who creates or edits a term cannot approve it. The system enforces this server-side — the approve button is only available to a different authorized user. Every approval records who submitted, who approved, the timestamp, and the reason. Supports dual-control evidence under MiFID II Art. 16 (organisational requirements) and aligns with DORA Art. 5 (Governance and organisation) by providing audit-ready terminology evidence. Learn more in our four-eyes principle guide.
Every change to every term is recorded with a full diff, the user who made the change, and the timestamp. When a regulatory technical standard (RTS) updates a definition, you update it once in the glossary, and the version history shows exactly what changed, when, and who approved the new version. This is the documentation audit trail that DORA Article 9 requires.
Scan your Confluence pages to find regulatory terms that are used but not defined in your glossary. When an auditor asks “how do you ensure consistent terminology across documentation?” the answer is: automated scanning identifies undefined terms, and the governance workflow ensures each definition goes through dual-control approval before it takes effect.
Export your complete glossary — definitions, approval history, version diffs — in a format ready for regulatory review. When BaFin, FCA, or your external auditor requests evidence of terminology governance, you produce it in one click rather than reconstructing it from email threads and spreadsheet timestamps.
Each Compliance Glossary feature maps to specific regulatory requirements that FinTech and banking compliance teams must satisfy.
| Feature | DORA Art. 5 | DORA Art. 9 | NIS2 Art. 21 | SOC 2 CC6.1 | MiFID II Art. 9(6) |
|---|---|---|---|---|---|
| Four-eyes approval | Governance & control framework requires dual oversight of ICT risk decisions | — | Governance measures must include approval processes | Logical access controls with role separation | Two persons directing the business; dual control of critical actions |
| Version history | Management body must oversee implementation; changes must be tracked | ICT documentation must be kept up to date and available on request | Policies must be maintained and updated | Change management evidence for auditors | — |
| Compliance scanning | Effective management of ICT risk includes identifying gaps | Documentation of all ICT-supported functions and assets | Risk analysis and information system security policies | Monitoring for anomalies (CC7.2) | — |
| Audit export | Framework must be available to competent authorities | Documentation available to competent authorities on request | Evidence of governance measures for supervisory authorities | Audit evidence for Type II report | — |
| Role-based access | Clear lines of accountability and decision-making authority | — | Access control and asset management policies | Restricts logical access to authorized users | Segregation of functions |
DORA Chapter V imposes detailed requirements for managing ICT third-party risk. Every new vendor in your technology stack triggers due diligence: data processing agreements, security assessments, exit strategies, concentration risk analysis. For compliance teams already stretched thin, adding another SaaS vendor creates work.
Compliance Glossary runs on Atlassian Forge — Atlassian’s serverless compute platform. This has specific implications for vendor risk:
external:fetch:backend permission). DailyMind LTD, the app publisher, has no runtime access to tenant data.For a detailed technical breakdown, see our security policy.
DORA is not coming — it is here. Your terminology governance process is either producing audit evidence or creating audit findings. There is no middle ground.
Evaluate in Confluence View Security WhitepaperCompliance for Confluence — approved terms, page scanning, and audit evidence for regulated teams in Confluence
DORA Regulation Terminology — ICT resilience starter terms for banks, insurers, and investment firms
NIS2 Directive Terminology — cybersecurity starter terms for essential and important entities
SOC 2 Terminology Management — 40 Trust Services Criteria terms for InfoSec and GRC teams
Four-Eyes Principle in Documentation — how dual-control approval works and which regulations mandate it
Security Whitepaper — how Forge protects your data within the Atlassian platform