DORA Compliance for Commerce: Why SaaS Platforms Create Third-Party ICT Risk
What Does DORA Mean for eCommerce in 2026?
Your eCommerce platform is now a regulated ICT dependency. Since January 17, 2025, the Digital Operational Resilience Act (DORA) makes financial institutions directly liable for every third-party system touching their operations. That includes the platform running your online store.
Key Takeaways
Last verified: March 2026
Regulation: The Digital Operational Resilience Act (DORA) took effect January 17, 2025, making financial institutions liable for third-party ICT risk — including their eCommerce platform.
The SaaS problem: Shopify, BigCommerce, and commercetools are themselves third-party ICT providers, creating the exact concentration risk DORA was designed to eliminate.
The solution: Only self-hosted, open source commerce platforms deliver the code ownership, audit capability, and infrastructure control DORA demands.
Penalties: Non-compliance carries fines up to 2% of annual worldwide turnover, €5M fixed penalties, and €1M personal liability for senior management.
DORA applies to over 22,000 financial entities across the EU, from banks and insurers to investment firms and crypto service providers. Unlike GDPR, which centers on data protection, DORA targets operational resilience. It mandates that financial institutions:
- Map every third-party ICT dependency
- Assess and mitigate risks from external vendors
- Conduct security testing before going live
- Detect, respond to, and report ICT incidents within hours
- Maintain audit trails of who did what and when
- Prove they can operate if critical vendors fail
For commerce teams, this creates a direct problem: the vendor managing your eCommerce platform is itself a critical ICT third party. Under DORA, you are 100% responsible for vetting, monitoring, and managing that risk.
The European Banking Authority (EBA) published the 2025 Regulatory Technical Standards (RTS), which operationalize DORA’s audit and testing requirements. Enforcement is already active. The first wave of supervisory actions targets institutions with inadequate third-party assessments, and regulators have signaled that fines will escalate through 2026. For detailed regulatory guidance, refer to the EIOPA DORA overview.
What Does DORA Require from Your eCommerce Platform?
DORA imposes eight core technical requirements on any platform processing financial services commerce: ICT risk assessment, third-party contract governance, incident notification, full audit logging, resilience testing, cyber threat intelligence, access controls, and data sovereignty.
As DORA’s Article 28(2) states: “Financial entities shall ensure that contractual arrangements on the use of ICT services include provisions on the right of access, inspection and audit by the financial entity or an appointed third party.” In practice, this means your eCommerce vendor must open their security controls to your auditors. Most SaaS platforms refuse.
| Requirement | DORA Mandate | What This Means for eCommerce |
|---|---|---|
| ICT Risk Assessment | Conduct thorough assessments of ICT-related risks and third-party dependencies | Your platform must provide full visibility into infrastructure, vendors, data flows, and security architecture |
| Third-Party Contract Terms | Establish contractual ICT risk management clauses with all critical third parties | Your eCommerce vendor must allow audits of their security controls, provide incident notifications, and enforce resilience requirements |
| Incident Notification | Notify regulators of significant ICT incidents within 4 hours of detection | Your platform must support forensic logging, incident detection, and rapid escalation |
| Audit Trail & Logging | Maintain immutable records of all administrative actions, system changes, and data access for at least 5 years | Every user action, configuration change, and data modification must be logged with timestamps and user identification |
| Testing & Resilience | Conduct advanced scenario analysis and red team exercises | Your platform provider must allow penetration testing, failover validation, and disaster recovery drills without vendor interference |
| Cyber Threat Intelligence | Monitor and share information about emerging threats | Your platform must provide API-level DDoS protection, rate limiting, intrusion detection, and integration with security monitoring tools |
| Authentication & Access | Implement strong authentication (MFA), RBAC, and principle of least privilege | Your platform must enforce granular RBAC, support SSO/SAML, and restrict access to production systems |
| Data Sovereignty | Critical operational data must reside in EU/UK infrastructure under your full control | Your platform must allow deployment in your own data centers or EU-only cloud regions, with encryption keys under your control |
The common thread: DORA requires you to own and control the systems managing your financial commerce operations. You cannot delegate this responsibility to a vendor.
Industries Affected by DORA
DORA directly affects commerce operations across the full spectrum of EU financial services, with indirect reach into sectors serving regulated institutions.
Directly regulated:
- Banks & Credit Institutions — All credit institutions, investment firms, payment institutions, and electronic money institutions licensed in the EU. Includes neobanks, online-only banks, and digital currency custodians.
- Insurance & Reinsurance — Insurers and reinsurers authorized under Solvency II. Includes InsurTech platforms offering digital policy distribution.
- Investment Services — Investment firms authorized under MiFID II. Includes wealth management platforms, robo-advisors, and digital investment services.
- Cryptocurrency Service Providers — Entities under the Markets in Crypto Regulation (MiCA), including exchanges, custody providers, and stablecoin issuers.
- Payment & E-Money Institutions — Payment processors, e-money issuers, and fintech payment networks.
Indirect scope: Any organization providing payment or commerce services to regulated institutions must meet DORA’s requirements. A consumer goods company selling insurance policies through an insurer-owned eCommerce store must comply.
UK alignment: The FCA’s PS21/3 mirrors DORA requirements for UK-regulated firms. UK banks and insurers must meet equivalent standards even outside DORA’s direct jurisdiction.
Beyond financial services, DORA’s ICT risk controls increasingly extend into adjacent sectors. Organizations in energy and carbon markets building commerce capabilities must implement DORA controls when serving EU essential entities. Public sector procurement platforms handling critical operational data face similar requirements.
EU automotive manufacturing eCommerce operations intersect with DORA where supply chain finance touches regulated institutions. iGaming platforms licensed in the EU are increasingly subject to DORA as gaming regulators harmonize with financial services standards.
Why Can’t SaaS Commerce Platforms Meet DORA Requirements?
SaaS platforms create the exact third-party concentration risk DORA was written to eliminate. A 2024 European Supervisory Authority (ESA) joint report found that 60% of EU financial institutions rely on just three cloud and SaaS providers for critical functions, making vendor concentration a systemic risk to financial stability.
The architecture is fundamentally incompatible. SaaS eCommerce platforms run on shared, multi-tenant infrastructure where one client’s security incident affects everyone. Shopify’s data breach becomes your data breach. BigCommerce’s infrastructure misconfiguration becomes your risk. Salesforce’s API downtime disrupts every Commerce Cloud client simultaneously.
| DORA Capability | Shopify Plus | BigCommerce | Salesforce CC | commercetools |
|---|---|---|---|---|
| ICT Risk Assessment | ❌ No visibility | ❌ No visibility | ⚠️ Partial docs | ❌ No visibility |
| 3rd-Party Elimination | ❌ You ARE the 3rd party | ❌ You ARE the 3rd party | ❌ You ARE the 3rd party | ❌ You ARE the 3rd party |
| Incident Reporting | ⚠️ SLA unclear | ⚠️ SLA unclear | ⚠️ SLA unclear | ⚠️ SLA unclear |
| Full Audit Trail | ⚠️ Partial logs | ⚠️ Partial logs | ✅ Via Salesforce | ⚠️ Partial logs |
| Resilience Testing | ❌ No pentest | ❌ No pentest | ⚠️ Limited | ❌ No pentest |
| Source Code Audit | ❌ Proprietary | ❌ Proprietary | ❌ Proprietary | ❌ Proprietary |
| Data Sovereignty | ⚠️ US-based | ⚠️ US-based | ⚠️ US-based | ✅ EU HQ |
| Granular RBAC | ⚠️ Limited | ⚠️ Limited | ✅ Full RBAC | ⚠️ Limited |
| SSO/SAML/MFA | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| Stress Testing | ❌ Vendor-managed | ❌ Vendor-managed | ❌ Vendor-managed | ❌ Vendor-managed |
The five questions regulators will ask:
- “Can you shut down access to this vendor if they fail a resilience test?” SaaS answer: No.
- “Can you audit their source code?” SaaS answer: No, it’s proprietary.
- “Can you enforce data residency where you need it?” SaaS answer: No.
- “Can you conduct penetration testing without permission?” SaaS answer: No, the SLA prohibits it.
- “If their API goes down, can you keep selling?” SaaS answer: No.
The conclusion is unavoidable. These vendors are too critical and too opaque for regulated financial services commerce.
How Self-Hosted Open Source Commerce Meets DORA Requirements
Here’s what changes when you own the platform: every DORA requirement becomes something your team controls directly, rather than something you hope your vendor handles.
Self-hosted, open source eCommerce platforms address DORA’s core demand: institutional ownership and control. Instead of negotiating with a SaaS vendor for audit access, your security team audits the code themselves. Instead of requesting penetration testing permission, your team schedules tests on their own infrastructure.
| DORA Capability | Compliance Mechanism | Spree Implementation |
|---|---|---|
| ICT Risk Self-Assessment | Complete source code access; full infrastructure visibility | Source code on GitHub; deploy to your infrastructure; audit every dependency |
| Third-Party Elimination | You own the platform; no vendor dependency | Spree is a tool, not a gatekeeper. Cloud providers are separate, negotiable dependencies |
| Incident Reporting | Full audit logs + incident detection under your control | Transaction, user action, and system event logs; SIEM integration; automated alerting |
| Full Audit Trail | Immutable log storage; 5+ year retention under your control | Every API call, order, admin change logged with timestamp, user ID, and change details |
| Resilience Testing | Pentest, red team exercises, failover simulation on your schedule | Deploy to your data center or private cloud; run security tests without vendor interference |
| Source Code Audit | Open source; audit code yourself or hire auditors | BSD 3-Clause license; full source code access; engage a security firm for production audit |
| Data Sovereignty | Deploy to EU/UK infrastructure; encryption keys under your control | Self-host in EU data center or EU-only cloud regions; encryption keys in your HSM |
| Granular RBAC | Configure roles and permissions for segregation of duties | Spree RBAC: segregate order approval, payment processing, inventory, reporting |
| SSO/SAML/MFA | Integrate with enterprise identity providers | Native SSO/SAML support; enforce MFA for all admin access |
| DDoS & Rate Limiting | Implement at infrastructure layer | Deploy behind AWS Shield or Cloudflare; Spree supports rate limiting via middleware |
These compliance capabilities are built into the platform, not third-party plugins that introduce their own compliance gaps. Spree’s BSD 3-Clause license means your security team can audit every line of code. No black boxes, no proprietary dependencies, no vendor gatekeeping.
For financial institutions needing DORA-compliant commerce, a self-hosted open source platform with full source code access, infrastructure control, and built-in audit capability provides the strongest architectural fit.
If Spree (the company) disappeared tomorrow, your commerce system keeps running. You own the code, the infrastructure, and the data. For DORA compliance, that independence is the whole point.
Architecture & Deployment for DORA-Compliant Commerce
A DORA-compliant commerce architecture requires EU-based deployment with layered security controls at every tier.
| Layer | Component | DORA Function |
|---|---|---|
| Edge Security | WAF + DDoS Protection | Rate limiting, bot detection, IP whitelisting for admin access |
| Infrastructure | Your EU Data Center or EU-Only Cloud (AWS EU, Azure EU) | Data sovereignty, encryption at rest, physical security |
| Orchestration | Kubernetes Cluster (Managed) | Auto-scaling, rolling deployments, health checks |
| Application | Spree Commerce API + Admin (self-hosted) | Transaction processing, order management, RBAC |
| Database | PostgreSQL (encrypted at rest) | Immutable audit logs, 5+ year retention, compliance exports |
| Identity | SSO/SAML + MFA (your corporate IdP) | Authentication, segregation of duties, access control |
| Disaster Recovery | Backup Infrastructure (separate region) | Failover, resilience testing, business continuity |
| Monitoring | SIEM (Splunk, ELK, Datadog) | Real-time alerting, 4-hour incident reporting workflow |
External integrations (each assessed separately under DORA): payment processors (PCI DSS-compliant), email services (encrypted channels), SMS providers, and analytics (minimalist, no sensitive data). All governed by DORA-compliant vendor agreements. Spree integrates with any payment processor, so your team can diversify across providers to reduce concentration risk.
Key design principles:
- Own the code: Self-host Spree, not SaaS.
- Control the infrastructure: Deploy to your data center or EU-only cloud.
- Encrypt everything: TLS for APIs, encrypted databases, encrypted backups.
- Segregate duties: No single person approves payments, processes refunds, and audits transactions.
- Audit everything: Every order, access, and change is logged.
- Test resilience: Run disaster recovery drills and pentests quarterly.
- Minimize third-party risk: Contract separately with payment processors, email providers, and other services.
DORA Compliance by Industry
Different financial services have specific DORA priorities. For industry-specific guidance, see:
| Industry | Key DORA Priorities | Deep Dive |
|---|---|---|
| Energy & Carbon Markets | Grid operator ICT resilience, carbon trading audit trails, cross-border settlement | Energy & Carbon marketplace compliance |
| Public Sector Procurement | GovCloud deployment, sovereign infrastructure, eIDAS integration | Public sector procurement commerce |
| EU Automotive Manufacturing | Supply chain finance controls, CRA compliance, multi-tier supplier portals | EU Automotive B2B commerce |
| iGaming | Real-time transaction monitoring, multi-jurisdiction licensing, KYC/AML integration | iGaming multi-jurisdiction commerce |
Financial services deployment scenarios:
| Scenario | Key DORA Priorities | Typical Spree Setup |
|---|---|---|
| Bank Selling Financial Products | Full audit trail, incident response <4h, resilience testing, segregation of duties | Bank hosts Spree in its data center; payments route to core banking via secure API |
| InsurTech / Direct Insurance Sales | Policy audit trail, policyholder data residency, DDoS protection | InsurTech hosts Spree in AWS EU; policies linked to backend management system |
| WealthTech / Robo-Advisor | Access controls for advisors, order audit trail, load testing | WealthTech hosts Spree in private cloud; integrates with advisory backend |
| Payment Processor / BNPL | Real-time incident detection, failover, payment routing audit | Provider hosts across regions; Spree handles order logging; core payment engine separate |
| Crypto Exchange / Custodian | Hot wallet audit trail, regulatory reporting, key access logging | Exchange hosts Spree in HSM-backed infrastructure; all key operations logged |
Related EU Regulations Your DORA Program Should Map To
DORA does not operate in isolation. Most financial entities caught by DORA also carry obligations under NIS2, GDPR, and the rest of the 2026 EU compliance stack. Mapping the overlaps early avoids duplicating audit work.
- NIS2 eCommerce Compliance covers essential and important entity obligations for network and information systems security. Financial infrastructure is already in scope under NIS2; DORA layers additional ICT risk requirements on top.
- GDPR and Schrems II eCommerce Compliance covers data residency, CLOUD Act exposure, and Standard Contractual Clause supplementary safeguards. Every DORA-regulated entity is also a GDPR data controller, and the CLOUD Act risk sits under both regimes.
- EU eCommerce Compliance 2026: GDPR, DORA, NIS2 and CRA is the umbrella overview, with audit procedures, deadlines, and platform requirements for every major EU regulation affecting commerce.
Build DORA-Compliant Commerce with Spree
DORA enforcement is here. Financial institutions across the EU and UK must now prove they own and control their critical ICT systems. For regulated commerce, that means moving off SaaS platforms you can’t audit, test, or deploy on your own terms.
For financial institutions building DORA-compliant commerce, Spree provides the ownership and control regulators require: full source code access for security audits, immutable audit trails for every transaction, EU/UK data residency with encryption under your control, and granular RBAC to enforce segregation of duties.
Frequently Asked Questions
Can our bank use Shopify for a DORA-regulated eCommerce platform?
No. If the platform processes payments, holds customer data, or executes orders affecting regulated activities (selling insurance policies, investment products, or payment services), it qualifies as critical ICT infrastructure under DORA. Shopify does not provide the audit access, resilience testing rights, or data residency controls regulators demand. UK FCA guidance (PS21/3) confirms the same standard for UK institutions. Use only platforms you own and control.
What counts as a “critical ICT third party” under DORA?
DORA defines three tiers: critical third parties (like AWS or Azure) whose failure would harm financial stability, important third parties (like Salesforce or Stripe) serving fewer institutions, and non-critical vendors. Your eCommerce platform is a critical ICT function. If you buy it from a SaaS vendor, that vendor becomes a critical third party you must manage. If you self-host with Spree, your infrastructure provider is the managed dependency, but Spree itself is not.
Do we need to audit Spree’s source code before deploying?
Yes. DORA requires you to understand the ICT systems managing critical functions. With open source, you can hire a security firm for a source code audit before production launch, then monitor updates through your vendor management process. With proprietary SaaS, that level of scrutiny is impossible. A typical approach: one-time security audit (€10K-50K), then ongoing monitoring of Spree’s release notes and dependency updates.
Can we just improve vendor management with our current SaaS platform?
Better vendor management helps, but it falls short of DORA’s core demand: you must own and control critical systems. Regulators will ask, “If this vendor fails a resilience test, can you switch to an alternative in 24 hours?” If your entire eCommerce system runs on Shopify, the answer is no. Vendor management is necessary but not sufficient.
How do we demonstrate DORA compliance to regulators?
Prepare documentation covering six areas: system architecture (where Spree runs, what data it holds, what integrations exist), ownership proof (you own infrastructure, code, and operations), audit trail evidence (sample log exports), security testing reports (pentest and resilience test results), vendor contracts (DORA-compliant agreements with cloud providers and payment processors), and incident response procedures (detecting, responding to, and reporting ICT incidents within 4 hours).
What happens if we miss DORA compliance deadlines?
Enforcement is active and escalating. Fines range from €1M to €5M for serious violations. Senior management faces personal fines up to €1M. More immediately, regulators issue supervisory letters, require remediation plans, and may restrict business growth until compliance is demonstrated. Institutions found non-compliant may be barred from launching new digital services.
