Data Classification Under DORA: From Public to Restricted and the Evidence Trail
Classification Is Not a Label — It Is a Governance Decision
When DORA Article 9(2) requires financial entities to develop and implement "policies for the classification of information assets and ICT assets," it is not asking for a taxonomy exercise. It is requiring a governance framework where every piece of data — from a public marketing brochure to a client's transaction history — has a protection level that determines who can access it, how it must be stored, how it must be transmitted, how long it must be retained, and what happens when it is compromised.
The distinction matters because supervisors do not assess classification by looking at a policy document. They assess it by examining whether the classification scheme is actually implemented — whether systems enforce the declared protection levels, whether evidence proves that data handling follows the classification, and whether the entire chain from creation to destruction is traceable.
This is where data classification intersects with DORA's evidence management requirements. Evidence itself is data. It has a classification. And the classification of the evidence must be consistent with the classification of the data it documents. This recursive relationship is what makes data classification under DORA fundamentally different from a simple labeling exercise.
DORA's Data Classification Requirements
DORA does not prescribe a specific classification taxonomy, but it establishes the characteristics that any scheme must have. Art. 9 addresses protection and prevention, Art. 10 addresses detection, and Art. 12 addresses backup, restoration, and recovery. Together, they define the data lifecycle from a resilience perspective.
| DORA article | Classification requirement | Practical implication |
|---|---|---|
| Art. 9(2) | Classify information assets based on criticality | Tiered protection controls per classification level |
| Art. 9(3)(b) | Implement network security management | Data-in-transit protection calibrated to classification |
| Art. 9(4)(c) | Strong authentication for access to critical data | Access control enforcement per tier |
| Art. 10(1) | Detect anomalous activities including data access | Monitoring intensity calibrated to classification |
| Art. 12(1) | Backup policies for data supporting critical functions | Backup frequency and recovery testing per tier |
| Art. 13(1) | Communication plans for data-related incidents | Disclosure obligations calibrated to classification |
The EBA's guidelines on ICT and security risk management provide additional granularity, recommending that classification schemes consider at minimum: confidentiality, integrity, availability, and the regulatory requirements applicable to specific data categories.
The Four-Tier Classification Model
While DORA does not mandate specific tier names, industry practice has converged on a four-tier model that aligns with both DORA's proportionality principle and existing enterprise data governance frameworks:
| Classification tier | Definition | DORA-relevant examples | Minimum protection controls |
|---|---|---|---|
| PUBLIC | Data intended for or acceptable for public disclosure | Marketing materials, published financial statements, press releases | Integrity verification only |
| INTERNAL | Data for internal use that is not sensitive but not public | Internal procedures, staff directories, non-critical operational data | Access control, encryption in transit |
| CONFIDENTIAL | Data whose unauthorized disclosure would cause significant harm | Client PII, transaction data, risk assessments, incident reports, audit findings | Encryption at rest (AES-256), encryption in transit (TLS 1.3), role-based access, audit-logged access, retention management |
| RESTRICTED | Data whose unauthorized disclosure would cause severe harm | Cryptographic keys, authentication credentials, critical infrastructure configs, regulatory examination results, penetration test findings | Hardware-protected key management, MFA for all access, continuous monitoring, segregated storage, dual-control access |
Mapping Classification to ICT Asset Criticality
Classification must be consistent with the institution's ICT asset criticality assessment under Art. 8. Data hosted on or processed by critical assets should be classified CONFIDENTIAL or RESTRICTED by default. The ICT asset register should record the highest classification level of data associated with each asset.
| Asset criticality | Default minimum data classification | Rationale |
|---|---|---|
| CRITICAL | RESTRICTED | Assets supporting critical functions handle regulated data |
| HIGH | CONFIDENTIAL | Assets supporting important functions handle sensitive data |
| MEDIUM | INTERNAL | Non-critical operational assets with internal data |
| LOW | PUBLIC or INTERNAL | Minimal risk assets |
Evidence Classification and Handling
Evidence collected during resilience testing, incident management, and compliance assessment is itself data that must be classified. This creates a layered classification challenge:
The critical insight is that evidence classification must be at least as high as the most sensitive data it references. A test report that reveals a vulnerability in the core banking system — including the exploit path, the affected components, and the remediation timeline — must be classified RESTRICTED, regardless of the test's outcome. An incident report that includes client names, account numbers, or transaction values is CONFIDENTIAL at minimum.
Chain-of-Custody Requirements
For evidence to have evidentiary value in a regulatory context — whether during a supervisory examination, an internal audit, or a dispute — the chain of custody must be unbroken and verifiable:
- Collection: Who collected the evidence, when, from what source, using what method. This metadata is immutable once recorded.
- Integrity: SHA-256 hash computed at collection time, verified at every access point. Any hash mismatch invalidates the evidence.
- Storage: Evidence stored in a system with access controls consistent with the classification level. For CONFIDENTIAL and RESTRICTED evidence, encryption at rest is mandatory.
- Access logging: Every access — read, download, share, export — is logged with actor, timestamp, purpose, and classification level. Access logs are themselves CONFIDENTIAL and append-only.
- Retention: Evidence retained for the regulatory minimum period (typically 10 years under Art. 11(1) and national transposition). Retention clocks start at the later of collection date or the closure of the associated compliance cycle.
- Disposal: At retention expiry, evidence is destroyed using classification-appropriate methods. Destruction is itself an audited event.
GDPR Intersection
Data classification under DORA does not replace GDPR obligations — it must incorporate them. Where evidence contains personal data (client identifiers, employee information, incident details involving individuals), the institution must satisfy both DORA's resilience requirements and GDPR's data protection principles.
The practical conflicts arise in several areas:
Retention. DORA requires long retention periods for audit evidence (10 years). GDPR requires data minimization and purpose limitation. The reconciliation: personal data embedded in regulatory evidence is retained for the regulatory minimum period under the legal obligation basis (GDPR Art. 6(1)(c)), but this must be documented in the institution's data protection impact assessment.
Access rights. GDPR grants data subjects the right to access their personal data. If a client's data appears in an incident report classified as RESTRICTED, the institution must balance the client's access right against the security classification. The solution: provide access to the relevant personal data extract, not to the full classified document.
Purpose limitation. Evidence collected for resilience testing cannot be repurposed for marketing, credit scoring, or other non-regulatory purposes. Classification controls must enforce purpose limitation at the access control level.
Implementing Classification in Practice
Step 1: Inventory and Baseline
Map all data categories across the institution's ICT asset register. For each category, record:
- Current classification (if any)
- Regulatory requirements applicable to the data
- Systems that process or store the data
- Access roles authorized for the data
- Existing protection controls
This inventory is a substantial effort for large institutions but is foundational. The Art. 8 asset register should already contain the system inventory; the data classification layer adds the data-to-system mapping.
Step 2: Classification Governance
Establish a data classification governance structure:
| Governance element | Responsibility | Frequency |
|---|---|---|
| Classification policy approval | Management body (via CRO) | Annual review |
| Classification decisions for new data categories | Data owners with CISO validation | As needed |
| Classification reviews for existing data | Data stewards | Annual minimum |
| Classification exception management | CISO + DPO joint decision | As needed, with expiry |
| Classification incident response | SOC + DPO | Per incident |
Step 3: Technical Enforcement
Classification must be enforced technically, not just procedurally. This means:
- Access controls configured to enforce classification-based restrictions in all systems
- Encryption applied at rest and in transit according to classification level
- Data loss prevention rules calibrated to prevent classified data from leaving controlled environments
- Monitoring and alerting tuned to the classification level — RESTRICTED data access triggers real-time alerts; INTERNAL data access is logged for retrospective review
Step 4: Evidence Trail
Every classification decision, every access event, and every protection control outcome must produce an evidence trail. This trail is the institution's proof that classification is operational, not aspirational. The trail feeds into Art. 14 board reporting as evidence that the ICT risk management framework includes functioning data governance.
Use the DORA readiness assessment to evaluate your data classification maturity, and consult the glossary for DORA's specific terminology around information assets and ICT assets. The RTS/ITS reference provides additional detail on the technical standards that inform classification requirements.
Common Classification Failures
Classifying everything as CONFIDENTIAL. Over-classification dilutes the scheme's effectiveness. If 90% of data is CONFIDENTIAL, people develop workarounds to deal with the friction — and those workarounds bypass the controls that matter for genuinely sensitive data.
Classifying at the document level, not the data level. A document may contain PUBLIC summary information alongside RESTRICTED vulnerability details. The classification must apply to the highest-level data element, but the institution should consider redaction capabilities for sharing lower-classification extracts.
No reclassification process. Data classification changes over time. Vulnerability details are RESTRICTED during the remediation window but may become INTERNAL after the vulnerability is patched and validated. Without a formal reclassification process, data accumulates at its peak classification forever.
Ignoring derived data. Aggregated, anonymized, or derived data may have a different classification than its source. But if the derivation is reversible (e.g., pseudonymized data that can be re-identified), the classification of the derived data must match the source.
Conclusion
Data classification under DORA is not an administrative formality. It is the mechanism that determines which data receives which protection, which access is monitored at which intensity, and which evidence trails are maintained at which level of rigor. The classification scheme is what connects the institution's abstract risk appetite to its concrete technical controls.
The institutions that implement classification effectively treat it as a living governance process — with clear ownership, regular review, technical enforcement, and an evidence trail that proves the scheme is operational. The institutions that treat it as a one-time labeling exercise will discover the gap during their first supervisory examination.
Resume en francais
Les articles 9, 10 et 12 de DORA exigent un schema de classification des donnees qui determine les controles de protection, de detection et de recuperation. Cet article presente le modele de classification a quatre niveaux (PUBLIC, INTERNE, CONFIDENTIEL, RESTREINT) et son application pratique dans les institutions financieres. Il couvre le lien entre la classification des donnees et la criticite des actifs TIC (Art. 8), la classification specifique des preuves collectees lors des tests de resilience et de la gestion des incidents, les exigences de chaine de traçabilite pour la valeur probante, l'intersection avec le RGPD concernant la retention et les droits d'acces, et les quatre etapes de mise en oeuvre (inventaire, gouvernance, application technique et piste de preuves). L'article identifie egalement les erreurs courantes de classification, notamment la sur-classification, la classification au niveau du document plutot que des donnees, l'absence de processus de reclassification et l'oubli des donnees derivees.