DORA Compliance for Commerce: Why SaaS Platforms Create Third-Party ICT Risk
Key Takeaways
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.
What DORA Means for eCommerce in 2026
The Digital Operational Resilience Act (DORA) represents the EU’s most comprehensive regulation of financial services ICT risk since GDPR. Effective January 17, 2025, it applies immediately to all EU financial institutions—banks, insurers, investment firms, and cryptocurrency service providers—that operate commerce platforms, payment systems, or digital customer channels. For detailed regulatory guidance, refer to the EIOPA DORA guidance page.
Unlike GDPR, which focuses on data protection, DORA centers on operational resilience. It mandates that financial institutions must:
- Understand and map every third-party ICT dependency
- Assess and mitigate risks from external vendors
- Conduct rigorous security testing before going live
- Detect, respond to, and report ICT incidents in hours, not days
- Maintain complete audit trails of who did what and when
- Prove they can operate if critical vendors fail
For commerce teams at financial institutions, this creates an immediate dilemma: the vendor managing your eCommerce platform is itself a critical ICT third party. And under DORA, you are 100% responsible for vetting, monitoring, and managing that risk.
The transition year (2025) allowed time for readiness. 2026 enforcement is stricter. Regulators have signaled that the first wave of fines will target institutions with inadequate third-party assessments. The European Banking Authority (EBA) published the 2025 Regulatory Technical Standards (RTS), which operationalize DORA’s audit and testing requirements. Financial institutions that cannot demonstrate compliance are already at risk of supervisory action.
DORA Requirements for eCommerce: What Your Platform Must Do
DORA defines specific capabilities that any eCommerce platform handling financial services commerce must support:
| 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. You must be able to answer: “Who has access? Where is data stored? What could fail?” |
| Third-Party Contract Terms | Establish contractual ICT risk management clauses with all critical third parties | Your eCommerce vendor must allow you to audit their security controls, receive incident notifications, and enforce resilience requirements. Non-negotiable SLAs required. |
| Incident Notification | Notify regulators of significant ICT incidents within 4 hours of detection; operational continuity must be restored within 24 hours | Your platform must support forensic logging, incident detection, and rapid escalation. You must be able to prove what happened and when. |
| 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, user identification, and change details. |
| Testing & Resilience | Conduct advanced scenario analysis and red team exercises; prove the system survives worst-case failures | Your platform provider must allow you to test failover, conduct penetration testing, and validate disaster recovery without vendor interference. |
| Cyber Threat Intelligence | Monitor and share information about emerging threats; implement reasonable defenses (DDoS protection, intrusion detection, etc.) | Your platform must provide API-level DDoS protection, rate limiting, intrusion detection alerts, and integration with security monitoring tools. |
| Authentication & Access | Implement strong authentication (MFA), role-based access controls (RBAC), and principle of least privilege | Your platform must enforce granular RBAC, support SSO/SAML, allow segregation of duties, 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 applies directly to:
- 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 financial products (e.g., insurance policies in an eCommerce store) owned by an insurance firm must comply.
UK alignment: The FCA (Financial Conduct Authority) has published PS21/3, which mirrors DORA requirements for UK-regulated firms. UK banks and insurers must meet equivalent standards even though they are not subject to DORA directly.
Beyond financial services, DORA also affects other critical sectors serving EU essential entities. Organizations in energy and carbon markets, public sector procurement, and automotive manufacturing that build eCommerce capabilities handling critical operational data must also implement DORA controls. Similarly, iGaming platforms licensed in the EU and processing customer payments are increasingly subject to DORA as gaming regulators harmonize with financial services standards.
Why SaaS Commerce Platforms Struggle with DORA Compliance
SaaS eCommerce platforms were built on a fundamentally different model: multi-tenant, shared infrastructure, and vendor-managed security. This architecture conflicts with nearly every DORA requirement.
| 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 fundamental problem: SaaS platforms are shared, multi-tenant systems. One client’s security incident or compliance failure affects everyone. Shopify’s data breach is everyone’s problem. BigCommerce’s infrastructure misconfiguration is everyone’s risk. Salesforce’s API downtime disrupts all Commerce Cloud clients simultaneously.
Under DORA, a regulated financial institution cannot accept this model. Regulators will ask:
- “Can you unilaterally shut down access to this vendor if they fail a resilience test?”
- SaaS answer: No, they control the platform.
- “Can you audit their source code?”
- SaaS answer: No, it’s proprietary.
- “Can you enforce data residency where you need it?”
- SaaS answer: No, they manage global infrastructure.
- “Can you conduct penetration testing without permission?”
- SaaS answer: No, they prohibit it in the SLA.
- “If their API goes down, can you keep selling?”
- SaaS answer: No, you’re dependent on their uptime.
Regulators will conclude: This vendor is too critical and too opaque. You cannot use them for regulated financial services commerce.
How Self-Hosted Open Source Commerce Meets DORA Requirements
Self-hosted, open source eCommerce platforms address DORA’s core demand: institutional ownership and control.
| 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 Dependency Elimination | You own the platform; no vendor dependency | Spree is not the third party; you are the operator. Cloud providers (AWS, Azure, Google Cloud) are separate, negotiable dependencies |
| Incident Reporting (within 4 hours) | Full audit logs + incident detection tools under your control | Complete transaction, user action, and system event logs; integrate with SIEM tools; automated alerting |
| Full Audit Trail | Immutable log storage; 5+ year retention under your control | Every API call, order, user action, admin change logged with timestamp, user ID, and change details; export to compliance systems |
| Resilience Testing Control | You can pentest, conduct red team exercises, simulate failures | Deploy to your own data center or private cloud; run security tests; failover to backup infrastructure without vendor interference |
| Source Code Audit | Open source; audit code yourself or hire third-party auditors | MIT license; full source code access; hire security firm to audit before production deployment |
| Data Sovereignty | Deploy to EU/UK infrastructure; encrypt keys under your control | Self-host in your EU data center, or deploy to EU-only cloud regions (e.g., AWS EU-WEST-1); encryption keys in your HSM |
| Granular RBAC | Configure roles and permissions to enforce segregation of duties | Spree RBAC: segregate order approval, payment processing, inventory, reporting; enforce principle of least privilege |
| SSO/SAML/MFA | Integrate with enterprise identity providers | Native SSO/SAML support; enforce MFA for all admin access; integrate with your IdP |
| DDoS & Rate Limiting | Implement at infrastructure layer (WAF, CDN, reverse proxy) | Deploy behind AWS Shield, Cloudflare, or your own WAF; Spree supports rate limiting via middleware; integrate with bot detection |
The key difference: With open source, you are not dependent on the vendor. Spree is a tool, not a gatekeeper. You control deployment, updates, security patches, and operational decisions. If Spree (the company) disappeared tomorrow, your commerce system continues running because you own the code.
For DORA compliance, this is essential. Regulators want to see:
- Ownership: “This is our system. We deployed it, we maintain it, we operate it.”
- Audit capability: “We can prove what happened in our commerce system at any moment in time.”
- Resilience control: “We tested this system ourselves and verified it survives failures.”
- Security transparency: “We audited the code, we know what it does, we control how it’s secured.”
Self-hosted open source delivers all four.
Architecture & Deployment for DORA-Compliant Commerce
A DORA-compliant eCommerce infrastructure follows this pattern:
| 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.
Key design principles:
- Own the code: Self-host Spree, not SaaS.
- Control the infrastructure: Deploy to your data center or EU-only cloud.
- Encrypt at rest and in transit: TLS for APIs, encrypted databases, encrypted backups.
- Segregate duties: RBAC enforces that no single person can approve payments, process refunds, and audit transactions.
- Audit everything: Every order, every access, every change is logged.
- Test resilience: Run disaster recovery drills in your environment; conduct pentests.
- Minimize third-party risk: Evaluate and contract separately with payment processors, email providers, etc.
DORA Compliance by Industry
Different financial services have slightly different DORA priorities based on their business model:
| Scenario | Key DORA Priorities | Why Spree Works | Typical Setup |
|---|---|---|---|
| Bank Selling Financial Products (e.g., Investment Accounts) | Full audit trail, incident response <4 hours, resilience testing, segregation of duties | Spree logs every transaction; integrates with identity provider for MFA; supports role-based workflow approvals | Bank hosts Spree in its data center; routes payments to core banking system via secure API |
| InsurTech / Direct Insurance Sales | Policy audit trail, policyholder data residency, DDoS protection, incident detection | Spree logs all policy sales and changes; supports EU data residency; integrates with DDoS protection; audit export for regulators | InsurTech hosts Spree in AWS EU; policies linked to backend policy management system |
| WealthTech / Robo-Advisor Commerce | Access controls for financial advisors, order audit trail, performance monitoring under load stress | Spree RBAC segregates financial advisors; logs all recommendations and orders; can be tested under load by team | WealthTech hosts Spree in private cloud; integrates with advisory backend; runs annual resilience tests |
| Payment Processor / BNPL Provider | Real-time incident detection, rapid failover, payment routing audit trail, DDoS mitigation | Spree audit logs route to SIEM; payment API calls logged; infrastructure auto-failover via Kubernetes; DDoS protection at WAF | Provider hosts across multiple regions; Spree handles order / transaction logging; core payment engine separate |
| Cryptocurrency Exchange / Custodian | Hot wallet integration audit trail, regulatory reporting, access to private keys logged, market data audit | Spree logs all withdrawal / deposit requests; integrates with hardware wallet backend; segregation of duties for hot wallet access | Exchange hosts Spree in HSM-backed infrastructure; all key operations logged and reported |
Build DORA-Compliant Commerce with Spree
DORA enforcement has arrived. Financial institutions across the EU and UK are now required to demonstrate third-party risk management. SaaS eCommerce platforms cannot meet this requirement.
Spree, as a self-hosted, open source platform, gives you the ownership and control DORA demands:
- Full source code access for security audits
- Complete audit trails for every transaction and admin action
- EU/UK data residency options with encryption under your control
- Granular RBAC to enforce segregation of duties
- Resilience testing in your own environment
- No vendor lock-in — you control the system, not the other way around
If your institution sells financial products, processes payments, or manages critical customer data through digital channels, you need a platform you own.
Get Started with Spree Commerce →
Explore how Spree enables DORA-compliant commerce for financial services, insurance, WealthTech, and payment platforms. Deploy in your infrastructure, maintain full audit capability, and meet regulatory requirements.
Frequently Asked Questions
Is our bank allowed to use Shopify for a financial services eCommerce platform?
Not for regulated financial commerce. If the platform processes payments, holds customer data, or executes orders that affect regulated activities (e.g., selling insurance policies, investment products, or payment services), it qualifies as critical infrastructure under DORA. Shopify cannot meet the audit, testing, or data residency requirements regulators will demand. UK FCA guidance (PS21/3) confirms this. Use only platforms you control.
What counts as a “critical ICT third party” under DORA?
DORA lists three tiers: (1) critical third parties (e.g., AWS, Microsoft Azure) that serve multiple institutions and whose failure would harm financial stability, (2) important third parties (e.g., Salesforce, Stripe) that provide important functions but serve fewer institutions, and (3) 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. If you self-host, your infrastructure provider (AWS, Azure) becomes the third party, but Spree does not.
Do we need to audit Spree’s source code?
Yes, you should. DORA requires you to understand the ICT systems managing critical functions. With open source, you can (and should) audit the code, hire a security firm to do so, and verify dependencies. With SaaS, you cannot. A typical approach: hire a security firm for a one-time source code audit before production launch, then monitor updates via your vendor management process.
Can we keep using our current SaaS platform and just improve vendor management?
Improved vendor management helps, but it does not solve 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 is on Shopify, the answer is no. Vendor management is necessary but not sufficient.
How do we demonstrate DORA compliance to regulators?
Prepare a compliance report that covers: 1. System architecture: Diagram showing where Spree runs, what data it holds, what integrations it has. 2. Ownership and control: Document proving you own the infrastructure, code, and operations. 3. Audit trail evidence: Sample log exports showing transaction history, admin actions, system events. 4. Security testing: Pentest and resilience test reports showing the system was tested and vulnerabilities were found and fixed. 5. Vendor contracts: Agreements with third parties (cloud providers, payment processors) that enforce DORA requirements. 6. Incident response plan: Procedures for detecting, responding to, and reporting ICT incidents within 4 hours. Spree provides the tool; your team provides the governance.
What if we use a managed Spree hosting provider instead of self-hosting?
You trade some operational complexity for reduced maintenance burden, but the hosting provider becomes a critical third party. You must ensure the hosting contract includes DORA-compliant SLAs: incident notification within hours, audit log access, resilience testing rights, and data residency guarantees. Managed hosting can work, but the contract must be tight.
Are EU-only deployments required?
For most EU financial institutions, yes. DORA and GDPR both prefer data residency in the EU. For UK institutions under FCA PS21/3, UK residency is often expected. However, if you have a legitimate operational reason to deploy in the US (e.g., a global bank with US clients), you can do so if you implement equivalent safeguards (encryption, access controls, incident response). But regulators will scrutinize this decision.
How much does it cost to build a DORA-compliant eCommerce system?
Costs vary widely. A self-hosted Spree deployment requires: infrastructure (AWS, Azure, or your data center), initial security audit (€10K–50K), ongoing compliance and monitoring (€5K–20K annually), and internal team effort (1–2 FTEs for a medium bank). This is more expensive than Shopify upfront, but you own the system and avoid SaaS lock-in. Most financial institutions find the compliance benefit and long-term cost savings justify the investment.
Can we use multiple payment processors to reduce third-party risk?
Yes. Using two or three PCI-compliant payment processors instead of one reduces risk from any single processor failing. Each must be separately assessed under DORA, but processor diversification is sound architecture. Spree supports multiple payment gateways.
What happens if we miss DORA compliance in 2026?
Regulators have signaled enforcement is increasing. Fines range from €1M to €5M for serious violations; senior management can face personal fines up to €1M. More immediately, regulators will issue supervisory letters, require remediation plans, and may restrict business growth until compliance is demonstrated. Institutions found non-compliant may be prohibited from launching new digital services.
