Compliance

What EU Data Protection Compliance Actually Requires Beyond GDPR

What EU Data Protection Compliance Actually Requires Beyond GDPR ?

If you've spent the past year treating GDPR as the finish line for selling into the EU, it's worth stopping to ask a harder question: is GDPR still the only rule that applies to you? For a growing number of SaaS companies, the answer is no. EU data protection compliance for SaaS startups now sits inside a wider set of rules that cover cybersecurity, operational resilience and how you move data across borders and several of these can apply to a company that has never heard of them.

This isn't a GDPR primer. If you've already built a privacy program, run a data processing agreement past your first enterprise customer and have some sense of what a DPO does, you're the right reader for this. What follows is an orientation to the wider EU compliance landscape for startups: the rules that sit next to GDPR, who they actually catch and how to figure out your own exposure without guessing.

GDPR still governs anything involving personal data: collection, storage, processing, deletion, the works. It's the baseline every company handling EU personal data has to clear. But it was never designed to cover cybersecurity risk management, financial-sector IT resilience or the mechanics of connected devices sharing data. The EU built separate laws for those and several of them now apply well outside the industries you'd assume.

A founder who's GDPR-compliant can still be non-compliant with a second, unrelated EU law and not know it. That gap is usually where surprises show up during due diligence or a large customer's security review. Getting a real GDPR NIS2 DORA compliance overview in front of you early is mostly a matter of knowing which of the three even has a reason to look at your business.

NIS2: the cybersecurity law that reaches further than most founders think

NIS2 (Directive 2022/2555) is an EU cybersecurity directive not a data protection law and that distinction is exactly why founders miss it. It's not enforced by data protection authorities, it doesn't ask about consent or lawful basis and it doesn't show up when you search "GDPR compliance checklist." It's about how well you manage cyber risk and how fast you tell someone when something goes wrong.

Member states were supposed to transpose NIS2 into national law by October 2024. In practice, adoption has been uneven. Some countries had implementing legislation ready on time, others are still finalizing it well into 2026. That inconsistency matters if you operate across several EU countries, because your actual obligations depend on the national law that applies to you, not just the directive itself.

Who NIS2 actually covers - The directive splits 18 sectors into two annexes. Annex I covers sectors eligible to be classed as "essential entities": energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, public administration, space and digital infrastructure, which includes cloud computing service providers, data centre operators, content delivery networks, DNS providers, trust service providers and managed service or managed security service providers. Annex II covers "important entities": postal and courier services, waste management, chemicals, food, manufacturing, research and digital providers such as online marketplaces, search engines and social networking platforms. Size matters too. Broadly, medium-sized and larger companies are in scope. The usual cutoffs are around 50 or more employees or €10 million or more in annual turnover, with a higher bar for the "important entity" category. Micro and small companies are generally exempt, though member states have discretion to pull in smaller entities anyway if they're a sole provider of a critical service, which is how some very small DNS registries and trust service providers end up in scope despite their size.
The part that catches SaaS founders off guard - Most SaaS companies aren't a cloud computing provider, an online marketplace or a social network, so on a strict reading, they're not directly in scope. But NIS2 requires in-scope organizations to manage risk in their own supply chains, which means an essential or important entity has to vet the security of the vendors it depends on. If your customer is a hospital network, a regional bank or a telecom operator, that customer's NIS2 obligations flow downhill to you as their vendor, even though you were never the directive's target. In practice, this shows up as tougher security questionnaires, contractual security clauses and incident-notification requirements written into your master service agreement rather than as a letter from a regulator.
What's changing - In January 2026, the European Commission proposed amendments to NIS2 as part of a broader simplification package. The proposal would create a new "small mid-cap" category (companies under 750 employees and under €150 million in turnover) that would be treated as important entities under lighter, after-the-fact oversight rather than upfront audits. It would also narrow some sector definitions (DNS providers, for instance, would no longer be automatically in scope) and introduce "cyber-posture certificates" meant to let companies avoid duplicate security audits across member states. None of this is law yet. It still has to go through negotiation, and the Commission's own proposal includes a 12-month transposition window after adoption. Treat the current rules as what applies today and keep an eye on this proposal rather than assuming it already changes anything.

DORA, in one paragraph

Selling to EU banks, insurers, investment firms or payment institutions brings the Digital Operational Resilience Act into the picture too. DORA applies directly to those regulated financial entities but it also reaches their "critical" ICT third-party providers, which can include a SaaS or cloud vendor that a bank depends on for something operationally important. When that's your customer base, DORA-driven contract terms and resilience requirements are worth understanding on their own terms. We've covered DORA in more depth elsewhere on this blog, so we won't duplicate that here. Just know it exists as a third lane alongside GDPR and NIS2 if fintech and banking customers are a meaningful part of your pipeline.

Moving data out of the EU: what's actually settled and what isn't

GDPR restricts transferring personal data outside the European Economic Area unless you have a valid legal mechanism to do it. Most startups rely on one of two: an adequacy decision, meaning the European Commission has decided a country's laws offer comparable protection or Standard Contractual Clauses, the contractual fallback used for countries without one.

The mechanism most US-facing startups actually touch is the EU-U.S. Data Privacy Framework, which has let companies self-certify and receive EU personal data without SCCs since July 2023. In September 2025, the EU General Court upheld the framework against its first serious legal challenge, a case brought by French MP Philippe Latombe, which argued the framework didn't adequately address US bulk surveillance and questioned the independence of the Data Protection Review Court set up to hear EU complaints. The court rejected those arguments, and the framework is still operating.

That's not the same as saying the question is closed. An appeal to the EU's highest court was expected, and the EU has invalidated two prior transfer mechanisms with the US (Safe Harbor, then Privacy Shield) on similar grounds. Rest your entire international transfer setup on Data Privacy Framework certification alone and you're one adverse ruling away from scrambling. The more durable approach is to keep Standard Contractual Clauses and a transfer impact assessment in place as a parallel or backup mechanism, particularly for higher-risk transfers rather than treating self-certification as a permanent architecture.

A related point worth a quick check rather than a blanket assumption: some sectors and member states impose data residency expectations tighter than GDPR's general transfer rules, particularly around public-sector contracts and health data. If you're bidding on that kind of work, ask the customer directly what their data residency requirements are before you assume GDPR's baseline is sufficient.

Two more rules worth knowing exist

You don't need a deep dive into either of these to know whether they touch you, but they're both part of the fuller set of data protection laws EU startups run into once they move past the basics.

The EU Data Act primarily targets connected products and IoT devices (smart home systems, wearables, connected vehicles, industrial equipment) and the businesses that hold data generated by them. Its main compliance dates have already landed, with user data access obligations in effect since September 2025 and requirements for new products phasing in through September 2026. Pure software with no connected hardware component is very likely outside its scope but check that assumption if your roadmap includes anything with a sensor in it.

The ePrivacy rules, which govern cookies, tracking technologies and electronic marketing, run alongside GDPR rather than inside it. Founders often assume their cookie banner is a GDPR requirement; it's technically an ePrivacy one, enforced differently in some member states and worth getting right on its own terms rather than assuming your GDPR privacy policy covers it.

How to actually figure out your exposure ?

Work through it in this order:

Confirm your GDPR footing firs - Everything above assumes it's handled. If it isn't, that's the priority.
Check your sector and your customers' sectors against NIS2's two annexes - not just your own industry label. A company that sells "just software" to hospitals or banks inherits its customers' scrutiny even without being named in the directive.
Ask whether financial institutions are a real part of your customer base - If yes, look at DORA's third-party provisions specifically, not GDPR.
Audit your data transfer mechanism - If you're relying solely on the Data Privacy Framework, add SCCs and a transfer impact assessment as backup documentation now, not after a ruling forces the issue
Flag anything connected or hardware-adjacent in your product - for a Data Act check, and confirm your cookie and marketing consent setup meets ePrivacy rules directly.

None of this is a substitute for legal advice specific to your business, your sector, and the member states you operate in. This is meant as an orientation, not a legal opinion and the fine print varies enough by country that a general guide can only get you so far.

That said, mapping out which of these frameworks actually apply to you is exactly the kind of work we do for founders every day. Mr.Compliance works on a flat-fee basis, so if you're trying to figure out whether NIS2's supply-chain pressure is going to show up in your next enterprise deal or whether your data transfer setup can survive another Schrems-style ruling, it's worth a conversation before a customer's security team asks first.