Third-party risk management in regulated entities often stops at static vendor contracts and ICT service registers. While a vendor register tracks contractual relationships, it offers zero technical visibility into the actual files transferred to third parties—such as cloud migration exports, forensics incident reports, or vendor analytics models.
Both DORA (Digital Operational Resilience Act) and NIS2 reach directly into the file layer. They require financial institutions, essential entities, and their ICT providers to prove that shared data remains protected, access is strictly controlled, and potential breaches can be scoped within hours.
Moving beyond static vendor attestation requires continuous file-layer controls that travel with sensitive data across third-party boundaries.
DORA vs. NIS2: Regulatory Scope and Applicability
The two regulations overlap, and both are in force.
DORA (Regulation (EU) 2022/2554) sets operational resilience requirements for financial entities, such as banks, insurers, investment firms, and payment institutions, and for the ICT third-party providers that serve them. It has applied since January 17, 2025.
NIS2 (Directive (EU) 2022/2555) sets cybersecurity risk-management requirements for entities in sectors it designates as essential or important, such as energy, transport, health, digital infrastructure, and others. Member states transpose it into national law, so details vary by country.
If you are outside the EU but serve EU customers, supply EU financial entities, or operate there, you may be pulled in as a provider or as an entity in scope. That is a question for counsel. This post assumes you have already established that one or both apply.
Map Your Third-Party Data Exposure in Minutes
Connect Theodosian to your cloud storage with zero data migration. Continuously discover sensitive data shared across external folders, evaluate vendor access exposure, and map risks against DORA and NIS2 requirements.
Key Data Security Mandates in DORA and NIS2
Neither regulation is about files specifically. Both are about risk management, and both reach files through their requirements on security measures and suppliers. The relevant provisions are these.
DORA, ICT risk management (Article 9): Financial entities must protect and prevent: limit logical access to what is needed for legitimate, approved functions; manage access rights; and apply policies on strong authentication and cryptographic key protection, with data encrypted according to approved data classification and the ICT risk assessment (DORA, Article 9).
That last clause links directly to discovery and classification. You cannot encrypt "according to data classification" if you do not know what you hold and how it is classified.
DORA, third-party risk (Article 28): Entities must manage ICT third-party risk and maintain a register of information on all contractual arrangements for ICT services, covering the entity, sub-consolidated, and consolidated levels. Supervisors expect the register to be submitted and kept current (EUR-Lex).
NIS2, risk-management measures (Article 21): Entities must take appropriate measures across ten areas, including supply chain security, policies on the use of cryptography and, where appropriate, encryption, and security in relationships with direct suppliers and service providers.
NIS2, incident reporting (Article 23): Significant incidents must be reported in stages: an early warning within 24 hours, a notification within 72 hours, and a final report within one month. Confirm exact triggers in your national law.
Read together, the themes are consistent. Know your data. Protect it in proportion to its classification. Control access. Manage what your suppliers hold. And be able to say, quickly, what was affected.
The Security Risks of External Third-Party File Sharing
Internal controls are comparatively tractable. You own the systems, the identities, and the policies. Files you have sent to a provider are different.
The file leaves your controls: Once a provider has a copy, your access policies do not apply to it. Their policies do.
The copies multiply: A provider shares with a subcontractor. An analyst saves a file locally. A backup keeps an old version. Your register has one line. The data has many locations.
Offboarding is slow: When a contract ends, the provider is supposed to delete your data. You usually have an attestation, not evidence.
Scoping an incident is guesswork: If a provider is breached, you need to know which of your files they held and which were readable. That takes days with the usual tools. NIS2's 24-hour early warning leaves very little room for it.
Container security ends at your environment’s boundary, but in a regulated enterprise, sensitive files leave that boundary every day through third-party contracts.
Regulatory Evidence: What Auditors Expect for Shared Files
Supervisors and auditors will ask versions of the same questions. Here is what a defensible answer looks like at the file level.
| What you will be asked | What you need to be able to show |
|---|---|
| Where is the data you share with ICT providers, and how is it classified? | An inventory of files by class and location, kept current as data changes |
| How is it protected in proportion to that classification? | Controls tied to the label, with the strongest protection on the most sensitive files |
| Who can access it, including at the provider? | A record of identities that can reach each file, and of each access attempt |
| Can you control it after it leaves? | Access that can be restricted or revoked after sharing |
| If a provider is breached, what was affected? | A per-file record, and a clear view of which files were readable to an attacker |
| How do you know the evidence is reliable? | Logs that can be verified as unaltered when exported |
None of this replaces your ICT register, your contracts, your due diligence, or your exit plans. It supplies the data-layer evidence those programs often lack.
Implementing File-Level Protection for DORA and NIS2 Compliance
Theodosian covers three parts of this picture.
Discover and classify: Theodosian connects to your cloud data stores, such as SharePoint and Google Drive, and continuously scans, inventories, and labels files with tags such as personal data, payment data, health data, and trade secrets. You see where your sensitive data lives and which people and AI agents can reach it, with no manual data-mapping project. That is the inventory Article 9's classification language assumes you have.
Protect and control: You decide which data classes matter. Everyday files stay shareable, which for a financial entity might be client records, deal files, or incident reports, and they get per-file, FIPS 140-3 validated encryption with a key of its own and access controls that check identity, device, location, and network. When a provider receives a protected file, it arrives encrypted, and opening it requires an access decision against your policy. You can revoke access remotely. A protected file is useless to a recipient who should not have it. Not even Theodosian can read it, and a stolen copy is useless.
Govern and audit: Every file action is recorded: who and what touched it, when, from where, and on what device. When your compliance team exports the logs, auditors and regulators can cryptographically verify that the export has not been altered or tampered with. Theodosian implements many of the controls these frameworks call for, from FIPS 140-3 validated encryption and contextual access control to AI governance and continuous audit logging, and the record shows they ran.
The scoping question changes too. If a provider is breached and the files they held were protected, you can say which files were reached and which were unreadable. That is a very different 24-hour conversation than "we are checking."
Governance and Operational Responsibilities That Cannot Be Automated
Tools produce evidence. They do not make the regulatory decisions.
You still need to decide whether and how DORA and NIS2 apply to you, and that is legal work. You still need your ICT third-party register, due diligence, contract terms, and exit strategies. You still need an incident process that decides what is significant and who reports to whom. And you still need testing and governance that DORA expects at board level.
Treat file-level controls as the evidence layer under those programs, not as a substitute for them.
A 60-Day Implementation Roadmap for Third-Party Data Governance
Days 1 to 15: Map the third-party data. For each provider on your register, list the categories of data and files it holds, and where those files sit in your storage.
Days 16 to 30: Inventory and classify. Run discovery over the stores involved. Identify which files held by providers are in your highest classes.
Days 31 to 45: Protect the top tier. Apply per-file protection to the highest-risk files you share with providers. Test it: send a protected file to a test recipient, then restrict access and confirm what they see.
Days 46 to 60: Rehearse an incident. Pick a provider and ask: if they were breached tomorrow, which of our files did they hold, and which were readable? Time the answer. Fix what slows it.
Achieving Continuous Resilience Across External Data Pipelines
The regulations are about resilience, and resilience depends on knowing where your data is and who holds it. Contracts and registers describe relationships. Controls on the data describe what those relationships can actually reach.
You can write the provider into the register, but the file is what the provider holds. Give the file a key of its own, a policy of its own, and a record of its own. That is control that travels with the data, and it is what lets you answer the supervisor's question without a week of searching.
Automate Third-Party File Evidence for DORA & NIS2
Stop relying on passive vendor attestations. Wrap your most sensitive shared assets in FIPS 140-3 validated encryption, enforce remote access revocation, and generate tamper-verifiable audit logs automatically.
FAQs: DORA and NIS2 Third-Party File Protection
Does Theodosian make us compliant with DORA or NIS2?
No product does that by itself, and we do not claim it. Theodosian implements many of the controls these frameworks call for, including FIPS 140-3 validated encryption, contextual access control, AI governance, and continuous audit logging, and it produces the record that shows they ran. You still need your ICT third-party register, due diligence, incident process, and legal analysis of what applies to you. In the two-week proof, you see which evidence questions the record answers on your own files.
Can we protect files we share with ICT providers?
Yes. A protected file arrives encrypted with its own key, and opening it requires an access decision against your policy: who is asking, from which device, from where, and on what network. You can revoke access remotely after the file has been shared. For a recipient who should not have the file, a protected file is useless. In the proof, you test this with a recipient you choose.
How does Theodosian help with the 24-hour early warning under NIS2?
It helps with scoping. Every file action is recorded, including who and what touched it, when, from where, and on what device. If a provider is breached, you can look up which of your protected files they could reach and which attempts were refused, instead of reconstructing it from several systems. Reporting decisions remain with your incident team.
Do the logs stand up to an auditor or supervisor?
When your compliance team exports the logs, auditors and regulators can cryptographically verify that the export has not been altered or tampered with. What the logs prove is that specific file actions occurred. They support your evidence and do not by themselves satisfy any framework.
Where can the data live, and can it be self-hosted?
Theodosian deploys with UK, EU, or US data residency, including a US region on FedRAMP Moderate infrastructure, or self-hosted. Residency questions are often part of DORA and NIS2 conversations, and we can cover your specific requirements in a technical walkthrough.
Related Reading:
Compliance Automation for Data Security: One File Event, Five Frameworks of Evidence
How to Protect Your Data Against Third-Party Breaches
Audit Logs for File Access: What Insurers, Auditors, and Boards Expect You to Prove