Written by: Agata Wojtas, Chief Commercial Officer, Digital Colliers
Berlin is reviewing 5.79TB of files leaked by the Rhysida ransomware group after refusing to pay. State officials confirmed the data includes national defense documents and threat response plans. The breach is large, but the real problem is harder to see. When a mid-market bank gets hit, the CISO cannot walk into the board meeting and say which customer data got exposed, which systems touched PII, or which regulators need to be notified within 72 hours. The classification schema exists on paper, but it does not survive contact with a breach.
Classification schemas that work on paper but not under pressure
Most banks classify data once during onboarding or when a new system goes live. The schema lives in a policy document. It does not live in the database metadata, the file headers, or the access logs. When ransomware locks the network, you cannot query what got encrypted. You cannot generate a list of affected customer records. You are running discovery forensics in parallel with regulatory clock countdown.
DORA has been in force since 17 January 2025. GDPR fines reach up to €20 million or 4 percent of global turnover. The window to notify regulators is 72 hours from discovery. If you cannot scope the breach in that window, you file a worst-case notice or you miss the deadline. Both options cost you.
The pattern I keep seeing is banks that run automated credit scoring or AML transaction monitoring but cannot reverse-map which customer records fed which model output. AML false-positive rates run 85 to 95 percent at typical mid-market banks. When a breach hits, you cannot tell which alerts were live customer data and which were test noise. The board wants to know customer exposure. You are still running queries.
The model that works during a breach
A classification schema that survives a breach has three parts. First, data classification lives in the database itself. Every table, every bucket, every file store has metadata tags for sensitivity tier, retention policy, and regulatory scope. The tags propagate when data moves between systems. They do not rely on a human remembering to update a spreadsheet.
Second, the breach scope map is pre-built. You document which systems touch PII, which touch payment card data, which touch special category data under GDPR. You map dependencies so that when system A gets breached, you know systems B and C are downstream. You do not discover this during the incident. You know it before the breach.
Third, the regulatory-filing trigger is automated. When the scope map flags affected systems, the schema tells you which regulators need notification. GDPR for EU customer data. PCI DSS for payment card exposure. NIS2 or DORA for critical infrastructure. The playbook is decision-tree logic, not a checklist someone reads under pressure.
Why most banks skip this until after the breach
Classifying data before a breach feels like overhead. The databases are already running. The access controls are already in place. Adding metadata tags and scope maps looks like compliance theater until you need them. Only about 3 to 5 percent of security vulnerabilities disclosed publicly are patched within 30 days. The industry treats prevention as an infinite time horizon. Breach response gets the same treatment.
The cost of inaction is regulatory exposure you cannot quantify. Berlin can take months to review 5.79 terabytes because it is a state actor with no GDPR customer notification clock. A mid-market bank has 72 hours to notify and 30 days to file a full report. If you spend the first week figuring out what got exposed, you miss the window. If you file worst-case assumptions, you amplify reputational damage and regulatory scrutiny.
Classify before the breach, not after
The move is to treat data classification as part of the schema, not a separate compliance layer. When you spin up a new database, the sensitivity tier goes into the metadata before the first record lands. When you build a new ETL pipeline, the scope map updates automatically. When you onboard a new SaaS vendor, the contract includes breach-notification reciprocity and the scope map reflects the new dependency.
This is not a six-month consulting engagement. Start with one system. Tag the tables. Map the dependencies. Document the regulatory triggers. Then expand to the next system. The work compounds. After three systems, you have a pattern. After ten, you have a framework that works under pressure.
Berlin will eventually finish reviewing the Rhysida leak. The damage is already done. The question for your bank is whether you can answer the board's question in the first 72 hours. If the answer is no, start classifying now.