What NIS2 and DORA mean for how your organisation shares documents and communicates externally
Most organisations share files the same way they always have. A document is ready. A link is generated. An email is sent. The recipient clicks.
Under NIS2 and DORA, that process is no longer compliant.
Not because the regulators have taken against email or file sharing specifically. Because the requirements those directives impose — know who has access to sensitive data, be able to prove it, be able to revoke it — are requirements that anonymous share links and unencrypted email are structurally incapable of meeting. The tools haven’t changed. The legal standard for using them has.
For many organisations, particularly those in sectors covered by both directives, this is a more significant operational challenge than it first appears. The gap between current practice and what the regulations now require is not a policy gap. It is an architectural one.
What NIS2 Actually Requires
The Network and Information Security Directive 2 — NIS2 — came into force across EU member states in October 2024. It significantly expands the scope of the original NIS directive, bringing a much wider range of organisations into its remit and substantially raising the requirements for cybersecurity risk management, incident reporting, and supply chain security.
For the purposes of how organisations share information externally, three requirements stand out.
First, access control. NIS2 requires that access to sensitive systems and data be managed through appropriate, verifiable controls. Anonymous access — where a link grants entry to anyone who possesses it, regardless of identity — does not meet this standard. Every access event must be tied to an authenticated individual.
Second, auditability. Organisations must be able to demonstrate, to regulators and in the event of an incident, who had access to what information and when. A shared link that has been forwarded through three inboxes and clicked by an unknown number of people produces no usable audit trail. The requirement is for a complete, accurate, and retrievable record of every access event.
Third, revocation. Access must be revocable. A link that has been sent cannot be unilaterally revoked — it exists in inboxes, archives, and forwarded threads beyond the sender’s control. The ability to withdraw access from a specific individual, immediately and completely, is a requirement that the link model cannot fulfil.
Taken together, these requirements effectively render the standard file-sharing workflow — generate link, send email, track nothing — non-compliant for any organisation within NIS2’s scope.
What DORA Adds for Financial Services
The Digital Operational Resilience Act — DORA — applies specifically to financial entities and their critical ICT service providers. It came into full effect in January 2025 and imposes detailed requirements around ICT risk management, third-party oversight, incident classification and reporting, and digital operational resilience testing.
For financial organisations, DORA compounds the NIS2 requirements with additional obligations. Third-party relationships — including how data is shared with external advisors, counterparts, and service providers — must be subject to documented risk assessments. The security of those data-sharing channels is not assumed; it must be demonstrated.
DORA also imposes strict incident reporting timelines. An organisation that suffers a data exposure incident must be able to reconstruct precisely what happened: which data was accessed, by whom, through which channel, and when. An audit trail that exists in fragmented email threads and expired link logs — or that does not exist at all — makes this reconstruction impossible within the timelines regulators expect.
For financial services firms already navigating GDPR, MiFID II, and sector-specific regulatory obligations, DORA does not introduce an entirely new compliance burden so much as it raises the floor on what “adequate” information security looks like — and raises it significantly.
The Gap Between Current Practice and Compliance
The honest assessment for most organisations is that current file-sharing and external communication practices fall short of what both directives require. Not through negligence, but because the tools that became standard — email, shared links, consumer file-sharing platforms — were adopted before these regulatory requirements existed and were not designed with them in mind.
The gap is specific and identifiable:
- Anonymous links — Any file shared via a URL that does not require authenticated sign-in fails the access control requirement. The link does not know who clicked it.
- Unencrypted email — Email in transit and at rest on standard mail servers does not meet the encryption standards NIS2 expects for sensitive data. Attachments sent by email are outside the sender’s control the moment they leave the outbox.
- No audit trail — Standard file-sharing platforms log that a link was clicked, not who clicked it. Without identity-tied access logs, the auditability requirement cannot be met.
- Irrevocable access — Once a link is sent, it cannot be reliably recalled. Even if the link is deactivated on the platform, it may have been downloaded, forwarded, or cached in ways the sender cannot control.
- Fragmented records — When documents and conversations about them exist in separate systems — a file on one platform, the discussion in email, the approval in a third tool — producing a coherent incident record becomes a manual, time-consuming, and often incomplete exercise.
What Compliant External Sharing Actually Looks Like
Meeting the requirements of NIS2 and DORA for external file sharing and communication is not a matter of adding compliance features to existing tools. It requires a different architectural approach — one where identity, auditability, and revocation are built into the sharing mechanism itself, not added as an afterthought.
Identity-based access, not link-based access
Every external access event must be tied to a verified individual. This means replacing anonymous URLs with authenticated access — where external parties sign in using a verified identity before they can view or interact with any shared content. Authentication through established identity providers — Microsoft 365, Google, Apple ID — or through secure credential systems provides the verification layer that anonymous links cannot. The access is not granted to a URL. It is granted to a person.
Peer-to-peer sharing with no links at all
The strongest compliance posture eliminates the link entirely. In a direct peer-to-peer model, two verified parties are connected through a closed, authenticated channel — a dashboard-to-dashboard connection where both sides are identified and the data moves directly between them. There is no URL to intercept, no link to forward, and no anonymous access point. The sharing event is, by design, identity-tied from end to end. This is not just compliant with NIS2’s access control requirements — it makes non-compliant access structurally impossible.
Real-time audit trails tied to verified identities
Compliance requires not just that access is controlled, but that it is recorded. Every view, download, comment, and interaction must be logged in real time, tied to the authenticated identity of the person who performed it, and retrievable in a form that regulators can review. This is categorically different from a link click log. It is a forensic record of who did what, when, through a verified identity — the kind of record that makes incident reporting under DORA’s tight timelines achievable rather than a frantic manual reconstruction.
Immediate, complete revocation
When a relationship ends, a project closes, or a security concern arises, access must be revocable instantly and completely. In an identity-based system, revoking access means removing a person’s authentication — after which they cannot access the channel regardless of what links or references they may have retained. There is nothing to chase down, no forwarded links to worry about, no cached access to expire. The revocation is immediate and architectural, not hopeful.
Channel-level encryption with HSM-backed keys
NIS2 requires that appropriate encryption be applied to sensitive data. But as with access control, the standard is not just that encryption exists — it is that it is implemented in a way that can be demonstrated to regulators. Channel-level encryption, where each collaboration environment holds a unique encryption key stored in a Hardware Security Module or key vault, provides that demonstrability. Each channel is independently encrypted. A breach, if it occurred, would be contained to a single channel — not a platform-wide exposure. And the encryption architecture can be documented and presented to regulators as evidence of appropriate technical controls, not just asserted.
The Incident Reporting Advantage
Both NIS2 and DORA impose incident reporting obligations with specific timelines — NIS2 requires an early warning within 24 hours of a significant incident, with a full report within 72 hours. DORA’s timelines for major ICT-related incidents are similarly tight.
Meeting these timelines requires that the information needed for the report already exists in a retrievable form. Which data was affected. Who had access. Through which channel. What actions were taken. When.
Organisations whose external sharing happens through email and anonymous links will find this reconstruction extremely difficult within 24 hours. The information they need is fragmented across platforms, inboxes, and access logs that were never designed to be consolidated into a regulatory report.
Organisations whose external sharing happens through an authenticated, audited, identity-based system will find that the incident report largely writes itself — the log already contains everything regulators need, in a format that is retrievable, accurate, and defensible.
The compliance value of a proper audit trail is not just that it satisfies a checkbox. It is that it transforms a regulatory crisis into a manageable reporting exercise.
Who This Applies To
NIS2 covers a significantly broader range of organisations than its predecessor. Essential entities — including energy, transport, health, digital infrastructure, and public administration — face the most stringent requirements. Important entities — a category that includes many professional services firms, digital service providers, and manufacturing organisations — face requirements that are demanding but proportionate.
DORA applies to financial entities including banks, investment firms, insurance companies, payment institutions, and crypto-asset service providers, as well as the ICT service providers that support them.
For organisations in scope for both — a financial services firm operating critical digital infrastructure, for example — the combined requirements represent a significant and non-negotiable uplift in how external data sharing and communication must be managed.
For organisations in scope for either, the practical implication is the same: the link-based, email-centric file sharing model that most have operated for the past decade is no longer adequate. The question is not whether to change the approach, but how quickly and how comprehensively.
Moving Forward
NIS2 and DORA are not theoretical future obligations. They are in force. Regulators are building enforcement capacity. The organisations that will navigate this environment most confidently are not those scrambling to retrofit compliance onto tools that were never designed for it — they are the ones that have replaced the link-based sharing model with an architecture where identity, auditability, encryption, and revocation are built in from the start.
The good news is that compliance and usability are not opposites here. An identity-based, audited sharing environment is not harder to use than sending a link in an email. For external parties, signing in with an existing Microsoft or Google identity adds seconds, not friction. For the organisation, the audit trail, the revocation capability, and the encryption architecture require no manual effort — they are simply how the system works.
Compliance is easiest when the secure way and the easy way are the same thing. That is what the right architecture makes possible.
