The Compliance Landscape Just Changed
If you run a company in financial services, healthcare, defense, or the EU, your regulatory obligations around data and software changed dramatically between 2024 and 2026. The shift happened fast, and most companies are still catching up.
Here's the short version:
Four regulations. Four different compliance frameworks. And every SaaS tool in your stack touches at least one of them.
Why SaaS Creates Compliance Risk
The compliance challenge with SaaS isn't theoretical. It's structural. Every SaaS vendor you use creates risk in five specific ways.
1. You Don't Control Where Your Data Lives
When you use Salesforce, your customer data sits in Salesforce's infrastructure. You choose a "region" during setup, but you don't control the actual data flow. Backups, CDN caches, analytics pipelines, AI training datasets — your data moves through systems you can't audit and locations you can't verify.
Under GDPR, you're the data controller. You're responsible for knowing where personal data goes and ensuring adequate protection at every point. When your data controller obligations collide with your SaaS vendor's opaque infrastructure, you have a compliance gap that no Data Processing Agreement can fully close.
The Cloud Act makes this worse. If your SaaS vendor is a US company — and most are — the US government can compel disclosure of data stored on their servers, even if those servers are in Frankfurt. The EU's data protection authorities have increasingly flagged this as a GDPR violation. Some have started issuing fines.
2. Every Vendor Is a Third-Party Risk
DORA requires financial entities to maintain a Register of Information covering all ICT third-party service providers. This isn't a spreadsheet exercise. It requires documenting:
For a company running 342 SaaS tools, this is a full-time job. Multiple full-time jobs. DORA didn't create this burden because regulators enjoy paperwork. They created it because they watched critical financial infrastructure go down when a single SaaS provider had an outage — and nobody had a contingency plan because nobody knew the dependency existed.
NIS2 extends similar third-party risk management requirements to 18 sectors: energy, transport, health, digital infrastructure, public administration, space, food production, manufacturing, and more. If you're in any of these sectors, your SaaS dependency is now a board-level compliance topic.
3. You Can't Audit What You Don't Own
Compliance requires evidence. Logs. Access records. Data flow documentation. Penetration test results. Incident response timelines.
When you own your software, you generate this evidence as a byproduct of running the system. Your database has audit logs. Your application has access controls. Your infrastructure has monitoring. You can hand an auditor a complete picture in hours.
When you use SaaS, you ask the vendor for this evidence. You get a SOC 2 Type II report — which tells you what their controls were 6-12 months ago, not today. You get a GDPR compliance statement — which is a legal document, not a technical one. You get a penetration test summary — redacted to protect their other customers.
This is not sufficient for DORA. DORA requires ongoing monitoring of ICT third-party risk, not annual compliance certificates. If your SaaS vendor has a security incident, you need to know within hours, not months. Under DORA's incident reporting requirements, you may need to report to regulators within 4 hours of a major incident — including incidents at your third-party providers.
Good luck getting Salesforce to notify you within 4 hours.
4. AI Features Create New Liability
The EU AI Act categorizes AI systems by risk level. High-risk AI — which includes AI used in employment, credit scoring, insurance, and essential services — requires transparency, human oversight, and documented testing.
Every major SaaS vendor has added AI features in the last 18 months. Salesforce has Einstein GPT. ServiceNow has Now Assist. Zendesk has AI agents. HubSpot has AI content tools. These features are typically enabled by default or aggressively promoted during renewals.
Here's the compliance problem: when your SaaS vendor's AI makes a decision that affects your customers, you may be liable under the AI Act. Not the vendor. You. Because you deployed the system in your workflow, even if you didn't build the AI.
The AI Act requires that deployers of high-risk AI systems:
Can you do this for Salesforce's Einstein GPT? Can you monitor its decisions, audit its reasoning, and maintain operation logs? No. Because you don't own the system. You rent access to it.
5. Concentration Risk Is Real
If your CRM, helpdesk, marketing automation, and analytics all run on Salesforce's infrastructure, what happens when Salesforce goes down?
This isn't hypothetical. Salesforce had five major outages in 2024-2025, including a multi-hour disruption that affected thousands of companies simultaneously. During each outage, the affected companies couldn't access customer data, process sales, or handle support tickets.
DORA specifically addresses concentration risk — the danger of depending too heavily on a single ICT provider. Regulators can designate certain providers as "critical" and impose direct oversight. They can also require financial entities to demonstrate that they can exit a critical provider within a defined timeframe.
If your exit plan for Salesforce is "we'll migrate to HubSpot," that's a 6-12 month project. DORA expects better.
How Custom Tools Simplify Compliance
Custom software doesn't eliminate compliance obligations. But it changes the compliance model from managing third-party risk you can't control to demonstrating first-party controls you designed.
Data Residency You Can Prove
When you build custom software, you choose where the data lives. Your database runs on infrastructure you control — whether that's your own hardware, a European cloud region with contractual data sovereignty guarantees, or a sovereign cloud provider.
You don't need to trust a vendor's assurance that data stays in the EU. You can prove it. Your infrastructure configuration is your evidence.
For companies subject to GDPR's data transfer restrictions, the Cloud Act conflict, or DORA's data localization expectations, this is the cleanest solution available. No Standard Contractual Clauses. No Transfer Impact Assessments. No legal gymnastics. The data is here because you put it here and it stays here because nothing moves it.
Audit Trails You Control
Custom software generates exactly the audit trail you need. Not the generic logs a SaaS vendor provides. Your logs.
When an auditor asks "who accessed this customer record and when," you don't submit a support ticket to your vendor. You query your own database. The answer comes in seconds, not weeks.
AI You Can Explain
If you need AI features — and many companies do — building them into custom software gives you something SaaS AI cannot: explainability and control.
You choose the model. You control the training data. You implement the human oversight. You log the decisions. You can explain to a regulator exactly how the AI works, what data it uses, and what safeguards prevent harmful outputs.
Under the EU AI Act, this is the difference between a compliance conversation and a compliance crisis.
One Security Perimeter
Instead of 342 attack surfaces, you have one application with one security perimeter. You control:
Your penetration tests cover your actual system, not a sanitized report from a vendor. Your security team can focus on defending one well-understood application instead of monitoring 342 vendors for breach notifications.
Simplified Third-Party Risk Register
DORA requires a register of all ICT third-party providers. For a company running 342 SaaS tools, that register is a monster. For a company that owns most of its software, the register is short: your cloud provider, your DNS provider, your email provider, and a handful of essential services.
The reduction in compliance burden alone — the hours saved on vendor assessments, contract reviews, and risk monitoring — pays for a significant portion of the custom build.
Data Sovereignty as Competitive Advantage
Compliance is typically framed as a cost center. Something you have to do. A tax on doing business. But data sovereignty is increasingly becoming a competitive differentiator.
Customer Trust
Customers — especially enterprise customers, government agencies, and European organizations — are asking harder questions about where their data goes. "We use Salesforce" used to be a reassuring answer. Now it raises questions about Cloud Act exposure, AI training data, and concentration risk.
"Your data lives in our infrastructure, in the region you specify, and never leaves" is a stronger answer. It's a selling point, not a compliance checkbox.
Vendor Negotiation Power
When you own your critical systems, vendor negotiations change fundamentally. You're not negotiating from dependency. You're negotiating from choice.
The SaaS vendor who knows you can't leave will raise prices 11.4% annually because they can. The SaaS vendor who knows you've already replaced two of their competitors with custom tools will offer you a very different renewal quote.
Speed of Compliance
When new regulations emerge — and they will — adapting custom software is straightforward. You modify your code, update your data model, add the required logging. Timeline: days to weeks.
Adapting to new regulations when you depend on SaaS means waiting for each vendor to implement compliance features, hoping they interpret the regulation correctly, and praying they ship updates before enforcement begins. Timeline: months to never.
DORA's enforcement began January 2025. As of this writing, several major SaaS vendors still haven't fully documented their DORA compliance posture. Their customers — financial entities — are left hoping regulators don't ask questions they can't answer.
Who This Matters For Most
Data sovereignty isn't equally urgent for every company. But for these sectors, it's becoming non-negotiable.
Financial Services
DORA makes this the most regulated sector for ICT risk. Banks, insurance companies, investment firms, payment providers, and crypto-asset service providers all fall under DORA's scope. Their ICT third-party providers — including every SaaS vendor they use — are subject to oversight.
Custom software lets financial entities demonstrate operational resilience, maintain data sovereignty, and satisfy DORA's third-party risk requirements without the overhead of managing hundreds of vendor relationships.
Healthcare
Patient data carries the highest sensitivity classification in most jurisdictions. HIPAA in the US. GDPR's special categories in the EU. National health data regulations in every developed country.
Every SaaS tool that touches patient data is a compliance risk. Custom tools built with privacy-by-design principles, on infrastructure you control, with audit trails you own, simplify compliance dramatically.
Defense and Government
Government contractors and defense companies operate under regulations (ITAR, CMMC, national security frameworks) that increasingly restrict the use of commercial cloud services and SaaS tools. Some classified and controlled unclassified information (CUI) simply cannot live in a SaaS vendor's infrastructure. Period.
Custom software on accredited infrastructure is often the only compliant option.
EU Companies (All Sectors)
The combination of GDPR, NIS2, the AI Act, and national digital sovereignty initiatives makes EU companies the most affected by the SaaS compliance challenge. The Cloud Act conflict alone — the risk that US-based SaaS vendors can be compelled to disclose EU citizen data — has driven some EU companies to eliminate US SaaS dependencies entirely.
This trend will accelerate. The EU's digital sovereignty agenda is a policy priority, not a passing concern. Companies that get ahead of it now will avoid the scramble later.
The Pragmatic Path
You don't need to replace every SaaS tool to improve your compliance posture. Start with the tools that handle your most sensitive data and create the highest third-party risk.
Step 1: Map Data Sensitivity
Identify which SaaS tools process personal data, financial data, health data, or otherwise regulated information. These are your highest-risk dependencies.
Step 2: Assess Third-Party Risk
For each high-risk tool, evaluate: Where does the vendor store data? Who are their sub-processors? What's their incident notification timeline? Can they satisfy your regulatory requirements? For most SaaS vendors, the honest answer to at least one of these questions is "we don't know" or "we can't guarantee that."
Step 3: Replace High-Risk Dependencies
Build custom replacements for the tools that create the most compliance risk. This typically means:
For a deeper look at replacement by category, see our SaaS Replacement by Category guide. For the full strategic framework, read our Complete Guide to SaaS Replacement.
Step 4: Document and Maintain
Custom software makes compliance documentation easier, but you still need to do it. Maintain your data processing records, keep audit logs accessible, run regular security assessments, and update your software when regulations change.
The difference: with custom software, all of this is under your control. You don't wait for a vendor to update their compliance documentation. You update yours.
The Cost of Inaction
Compliance penalties are escalating. GDPR fines have exceeded $4 billion cumulative since 2018, as tracked by GDPR Enforcement Tracker, with individual fines reaching $1.3 billion (Meta, 2023). DORA penalties are still being defined by national regulators, but the framework allows for significant financial sanctions. NIS2 sets maximum fines at 2% of global annual turnover.
But fines aren't the real risk. The real risk is operational: being forced to stop using a SaaS tool mid-contract because a regulator determines it violates data sovereignty requirements. That's not a fine. That's a business continuity crisis.
Companies that own their critical software don't face this risk. Their data is where they put it. Their controls are what they built. Their compliance posture is what they designed, not what a vendor marketed.
The Bottom Line
Data sovereignty isn't about nationalism or protectionism. It's about control. Knowing where your data is. Proving who accessed it. Deciding how it's processed. Responding to regulations on your timeline, not your vendor's.
SaaS makes all of this harder. Not because SaaS vendors are malicious, but because the multi-tenant, US-headquartered, AI-infused SaaS model is structurally incompatible with the direction regulators are moving.
Custom software isn't a silver bullet. But for companies in regulated industries, handling sensitive data, or operating in the EU, it's increasingly the cleanest path to compliance.
The question isn't whether to start. It's whether you start now — when you can plan the transition — or later, when a regulator forces it.
Concerned about compliance risk in your SaaS stack? Get a free SaaS audit. We'll identify which tools create the highest regulatory exposure and show you what a compliant custom replacement looks like — with timelines and costs.