DORA Is Not Another Checkbox Exercise
The EU's Digital Operational Resilience Act went into full effect on January 17, 2025. Unlike previous regulations that treated ICT risk as a footnote in broader financial compliance, DORA puts technology infrastructure at the center of regulatory scrutiny. If you operate a fintech, a crypto exchange, a payment processor, an insurance platform, or any SaaS product that serves EU-regulated financial entities — DORA applies to you, directly or through your clients' supply chains.
Most compliance guides treat DORA as a policy exercise. Write some documents, update your risk register, move on. That misses the point. DORA has teeth in five specific areas that directly affect how you choose, configure, and manage your hosting infrastructure. This post breaks down what those requirements actually mean for your servers, your provider relationships, and your incident response capabilities — and where Swiss-hosted infrastructure gives you structural advantages that make compliance easier.
What DORA Actually Covers
DORA applies to over 22,000 financial entities and ICT service providers across the EU. The regulation is organized around five pillars, and every one of them has infrastructure implications:
• ICT Risk Management — Financial entities must identify, classify, and mitigate all ICT-related risks. This includes your hosting infrastructure, your network configuration, your backup systems, and your disaster recovery procedures. Article 6 requires a comprehensive ICT risk management framework that is "documented, reviewed at least once a year, and improved on a continuous basis."
• ICT Incident Reporting — Major ICT incidents must be reported to competent authorities within strict timelines. Initial notification within 4 hours of classification, intermediate report within 72 hours, final report within one month. Your infrastructure needs to support the logging, monitoring, and forensic capabilities to meet these windows.
• Digital Operational Resilience Testing — Regular testing of ICT systems, including vulnerability assessments, penetration testing, and — for significant entities — advanced threat-led penetration testing (TLPT) based on the TIBER-EU framework. Your servers need to support these testing activities without compromising production stability.
• ICT Third-Party Risk Management — This is the big one for hosting. DORA imposes specific contractual requirements on agreements with ICT service providers, including hosting companies. Articles 28-30 detail what those contracts must contain — exit strategies, audit rights, data location disclosure, subcontracting transparency, and more.
• Information Sharing — Voluntary but encouraged sharing of cyber threat intelligence among financial entities. Your infrastructure should support secure communication channels for this purpose.
Pillar 1: ICT Risk Management and Your Hosting Stack
Article 6 of DORA requires financial entities to establish an ICT risk management framework that identifies all ICT assets, maps dependencies, and assesses risks. Your hosting infrastructure is an ICT asset. Your provider is a dependency. Both must be documented, risk-assessed, and actively managed.
What this means in practice: you need full visibility into your infrastructure stack. Not just "we use a hosting provider" — you need to document the physical location of your servers, the network architecture, the hardware specifications, the OS and software versions, the access control mechanisms, and the data flows between components.
This is where self-managed dedicated servers have an advantage over opaque cloud platforms. When you run a Swiss dedicated server, you know exactly what hardware you are running on, what OS is installed, what services are exposed, and who has access. You can provide your compliance team with a complete inventory that satisfies Article 6 requirements without depending on your cloud provider's SOC reports to fill in the gaps:
# Generate a comprehensive infrastructure inventory for DORA compliance
# Hardware identification
dmidecode -t system | grep -E "Manufacturer|Product|Serial"
dmidecode -t processor | grep -E "Version|Core Count|Thread Count"
free -h
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
# Network configuration
ip addr show
ip route show
ss -tlnp
# Installed services and versions
dpkg -l | grep -E "nginx|apache|postgres|mysql|redis|openssh"
systemctl list-units --type=service --state=running
# Security configuration
ufw status verbose
fail2ban-client status
grep -c "PermitRootLogin no" /etc/ssh/sshd_configOn a managed cloud platform, generating this level of detail requires piecing together information from multiple dashboards, APIs, and documentation pages — some of which may not be available or may not reflect the actual runtime configuration. On bare metal, it is one SSH session and a set of standard Linux commands.
DORA also requires business continuity and disaster recovery planning (Article 11). Your hosting infrastructure must support documented backup procedures, recovery time objectives (RTOs), and recovery point objectives (RPOs). You need to demonstrate — not just claim — that your backups work and your recovery procedures have been tested:
# Automated backup verification script for DORA compliance
# Run weekly as part of resilience testing
#!/bin/bash
BACKUP_DIR="/backup/latest"
TEST_DIR="/tmp/backup-verify-$(date +%Y%m%d)"
LOG="/var/log/dora-backup-verify.log"
echo "$(date) - Starting DORA backup verification" >> $LOG
# 1. Verify backup exists and is recent (within 24h)
LATEST=$(find $BACKUP_DIR -maxdepth 1 -mtime -1 -name "*.sql.gz" | head -1)
if [ -z "$LATEST" ]; then
echo "FAIL: No backup found within last 24 hours" >> $LOG
exit 1
fi
echo "OK: Latest backup: $LATEST" >> $LOG
# 2. Verify backup integrity (checksum)
sha256sum -c "${LATEST}.sha256" >> $LOG 2>&1
if [ $? -ne 0 ]; then
echo "FAIL: Backup checksum mismatch" >> $LOG
exit 1
fi
echo "OK: Checksum verified" >> $LOG
# 3. Test restore to isolated database
mkdir -p $TEST_DIR
gunzip -c $LATEST | psql -h localhost -p 5433 -U test_restore test_db >> $LOG 2>&1
echo "OK: Restore completed" >> $LOG
# 4. Verify data integrity post-restore
ROWCOUNT=$(psql -h localhost -p 5433 -U test_restore -t -c \
"SELECT count(*) FROM critical_table;" test_db)
echo "OK: Restored row count: $ROWCOUNT" >> $LOG
# 5. Cleanup
dropdb -h localhost -p 5433 -U test_restore test_db
rm -rf $TEST_DIR
echo "$(date) - DORA backup verification PASSED" >> $LOGPillar 2: Incident Reporting and Infrastructure Requirements
DORA's incident reporting requirements are among the most demanding of any financial regulation. When a major ICT incident occurs, you have 4 hours from classification to submit an initial notification. That clock starts ticking the moment you determine the incident is "major" — which DORA defines based on criteria including the number of affected clients, the duration, the geographic spread, data losses, and the criticality of affected services.
Your infrastructure must support this timeline. That means comprehensive logging, real-time monitoring, and automated alerting — not as nice-to-haves, but as regulatory requirements. Here is the minimum monitoring stack you need:
# Essential monitoring for DORA incident reporting compliance
# 1. Centralized logging with retention (Article 12 requires adequate logging)
# rsyslog forwarding to central log server
cat >> /etc/rsyslog.d/dora-compliance.conf << 'EOF'
# Forward all logs to central logging infrastructure
*.* @@logserver.internal:514
# Local retention: minimum 5 years for financial data
$MaxMessageSize 64k
$ActionQueueType LinkedList
$ActionQueueFileName dora-fwd
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on
EOF
# 2. File integrity monitoring (detect unauthorized changes)
apt install aide -y
aideinit
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
# Daily integrity check via cron
echo "0 3 * * * root /usr/bin/aide --check | mail -s 'AIDE Report' security@company.com" \
>> /etc/crontab
# 3. Network flow logging (detect anomalous traffic patterns)
# Using nftables flow accounting
nft add table inet flow_log
nft add chain inet flow_log forward '{ type filter hook forward priority 0; }'
nft add rule inet flow_log forward log prefix \"FLOW: \" counterThe 72-hour intermediate report must include root cause analysis, impact assessment, and remediation actions taken. This requires forensic capabilities — the ability to reconstruct what happened, when, and why. If your hosting provider controls the hardware and you cannot access system-level logs, kernel audit trails, or network captures, you are at a disadvantage when that 72-hour clock is running.
On infrastructure you control — whether self-managed or through a managed Swiss infrastructure arrangement — you have direct access to every log, every metric, and every configuration change. You can run forensic analysis immediately without waiting for your cloud provider's support team to escalate your ticket.
Pillar 3: Resilience Testing on Your Infrastructure
DORA requires regular testing of ICT systems proportionate to the entity's size and risk profile. For all entities, this includes vulnerability assessments, network security assessments, and application security testing. For "significant" entities (determined by competent authorities), it includes Threat-Led Penetration Testing (TLPT) at least every three years.
TLPT under DORA follows the TIBER-EU framework. This is not a standard vulnerability scan. TIBER tests simulate real-world attack scenarios against your live production infrastructure. Your hosting environment must support this testing without the restrictions that some cloud providers impose. Many cloud providers require advance notification of penetration testing, limit the scope, or prohibit certain test types entirely. AWS, for example, prohibits DNS zone walking, port flooding, and protocol flooding in their acceptable use policy.
On dedicated hardware, you control the testing scope. You can run full-spectrum penetration tests — including network-level attacks, kernel exploit testing, and physical access simulations — because the hardware is yours and there are no other tenants to impact:
# DORA TLPT preparation checklist for dedicated infrastructure
# 1. Ensure full audit logging is enabled before testing
auditctl -e 1
auditctl -a always,exit -F arch=b64 -S execve -k exec_log
# 2. Baseline system state before TLPT engagement
# Package checksums
dpkg --verify > /var/log/dora-tlpt/pre-test-package-state.txt
# Running processes
ps auxww > /var/log/dora-tlpt/pre-test-processes.txt
# Network connections
ss -tlnp > /var/log/dora-tlpt/pre-test-connections.txt
# Firewall rules
nft list ruleset > /var/log/dora-tlpt/pre-test-firewall.txt
# 3. Verify monitoring captures test activity
# (your SIEM should detect and log the pen test activity
# — this validates your detection capabilities)Pillar 4: Third-Party Risk Management — The Hosting Contract
This is where DORA gets very specific about your hosting provider relationship. Articles 28-30 require that contracts with ICT third-party service providers include explicit provisions for:
• Service level descriptions — Quantitative and qualitative performance targets, including availability, latency, and throughput guarantees. Not marketing SLAs — contractually binding service levels with measurable metrics.
• Data location — The provider must disclose where data is processed and stored, and must notify you before any changes to data location. If your provider moves your workload to a different data center or jurisdiction, you have to know about it in advance.
• Audit rights — You (or your regulator) must have the right to audit the provider's operations, including on-site inspections. The provider cannot refuse a reasonable audit request.
• Exit strategies — The contract must include a transition plan for moving to a different provider, including data portability provisions and adequate transition periods.
• Subcontracting transparency — If your hosting provider subcontracts any part of the service, you must be informed and have the right to object.
• Incident notification — The provider must notify you of ICT incidents that affect your services, with timelines compatible with your own reporting obligations.
This is where the choice of hosting provider becomes a compliance decision, not just a technical one. Large cloud providers (AWS, Azure, GCP) have standard terms of service that may not include all DORA-required provisions. Negotiating custom contract terms with a hyperscaler is possible but difficult, especially for smaller financial entities.
Smaller, specialized hosting providers — particularly those already serving regulated industries — are often better positioned to offer DORA-compliant contracts. A Swiss hosting provider that operates its own data center infrastructure can provide:
• Exact data location (Zurich, Switzerland — no ambiguity, no multi-region failover to unknown jurisdictions)
• Direct audit access (you can physically inspect the facility)
• Clear subcontracting relationships (typically none — the provider owns and operates the infrastructure)
• Customizable SLAs with meaningful penalties
• Exit strategies that include full data export and reasonable transition periods
The Swiss Jurisdiction Advantage for DORA
Switzerland is not an EU member state, so DORA does not apply directly to Swiss-based hosting providers. However, Swiss hosting providers serving EU-regulated clients operate under a framework that is structurally compatible with DORA — and in some ways, superior to hosting within the EU itself.
Data protection equivalence. The EU has granted Switzerland an adequacy decision under GDPR, recognizing that Swiss data protection law (the FADP, revised in September 2023) provides an equivalent level of protection. This means data transfers from EU entities to Swiss-hosted infrastructure do not require Standard Contractual Clauses or Binding Corporate Rules — the adequacy decision covers it. For DORA's data location requirements, Swiss hosting is treated as an approved jurisdiction.
Legal stability. Swiss data protection law is not subject to the political dynamics of EU member states. The FADP provides clear, stable privacy protections that are unlikely to be weakened by changes in government. For financial entities planning multi-year infrastructure contracts — which DORA's exit strategy requirements encourage — this legal stability is valuable.
Neutrality and jurisdictional independence. Swiss hosting providers are not subject to US CLOUD Act requests, Chinese data localization laws, or other extraterritorial data access demands. When a regulator asks where your data is and who can access it, "Switzerland" is one of the cleanest answers you can give. No Five Eyes membership. No intelligence-sharing agreements that could create backdoor access to your infrastructure.
FINMA alignment. The Swiss Financial Market Supervisory Authority (FINMA) has its own ICT risk management requirements for Swiss financial institutions (FINMA Circular 2023/1 on Operational Risks). These requirements are substantively aligned with DORA, meaning Swiss hosting providers that serve Swiss financial institutions are already operating at a standard consistent with DORA expectations.
Practical Infrastructure Architecture for DORA
Here is a concrete infrastructure architecture that addresses DORA's five pillars using Swiss-hosted dedicated servers. This is not a theoretical compliance exercise — it is a buildable, auditable infrastructure design:
# DORA-compliant infrastructure architecture
# Swiss-hosted, self-managed, fully auditable
# ┌─────────────────────────────────────────┐
# │ PRODUCTION CLUSTER │
# │ │
# │ App Server 1 ──┐ │
# │ App Server 2 ──┼── Load Balancer ── Internet
# │ App Server 3 ──┘ (HAProxy) │
# │ │
# │ DB Primary ────── DB Replica │
# │ (PostgreSQL) (hot standby) │
# │ │
# │ Redis Cache Message Queue │
# │ (RabbitMQ) │
# ├─────────────────────────────────────────┤
# │ MONITORING & LOGGING │
# │ │
# │ Prometheus + Grafana (metrics) │
# │ Loki (log aggregation) │
# │ Wazuh (SIEM + integrity monitoring) │
# │ Uptime Kuma (availability tracking) │
# ├─────────────────────────────────────────┤
# │ BACKUP & DR │
# │ │
# │ Backup Server (encrypted, off-site) │
# │ DR Replica (separate physical rack) │
# │ Tested monthly (automated verification)│
# └─────────────────────────────────────────┘
# Key DORA compliance points:
# - All servers in Zurich, Switzerland (data location: documented)
# - Dedicated hardware (no multi-tenant risk, full audit trail)
# - Monitoring stack provides 4-hour incident detection capability
# - Backup verification proves RTO/RPO compliance
# - Full root access enables TLPT testing without restrictions
# - No subcontractors (provider owns infrastructure)Monitoring for the 4-hour reporting window. The critical metric is Mean Time to Detect (MTTD). If your monitoring cannot detect and classify a major incident within the first hour, you have already consumed a quarter of your reporting window. Set up multi-layer alerting:
# Prometheus alerting rules for DORA incident detection
groups:
- name: resilience_critical_alerts
rules:
# Service availability — detect within 60 seconds
- alert: ServiceDown
expr: up == 0
for: 1m
labels:
severity: critical
resilience_class: potential_major
annotations:
summary: "Service {{ $labels.job }} is down"
# Database replication lag — detect data integrity risk
- alert: ReplicationLagCritical
expr: pg_replication_lag_seconds > 30
for: 2m
labels:
severity: critical
resilience_class: potential_major
annotations:
summary: "DB replication lag: {{ $value }}s"
# Disk encryption status — detect security compromise
- alert: EncryptionStatusChanged
expr: node_luks_active == 0
for: 0m
labels:
severity: critical
resilience_class: major_security
annotations:
summary: "LUKS encryption inactive on {{ $labels.device }}"
# Unauthorized SSH access attempts
- alert: BruteForceDetected
expr: rate(sshd_auth_failures_total[5m]) > 10
for: 5m
labels:
severity: warning
resilience_class: potential_incident
annotations:
summary: "SSH brute force: {{ $value }} failures/min"Concentration Risk: DORA's Anti-Lock-In Provision
One of DORA's more interesting requirements is the management of ICT concentration risk (Article 29). Financial entities must assess whether they have excessive dependency on a single ICT service provider. If all your infrastructure runs on one cloud provider, that is a concentration risk that DORA requires you to document, assess, and mitigate.
This provision is specifically designed to address the systemic risk of the financial sector's increasing dependence on a small number of cloud providers. If AWS has a major outage that simultaneously affects dozens of banks, payment processors, and insurance companies, that is a systemic event. DORA wants financial entities to have plans for that scenario.
Swiss-hosted dedicated infrastructure provides a natural diversification layer. It is a different provider, a different jurisdiction, a different physical infrastructure from the hyperscalers. Financial entities can use Swiss hosting for their most critical, most regulated workloads — the systems that must remain operational even if their primary cloud provider experiences an extended outage:
# Multi-provider resilience architecture for DORA concentration risk
# Primary: Application tier on cloud (auto-scaling, global CDN)
# Critical: Database + compliance systems on Swiss dedicated hardware
# Rationale: Cloud outage does not affect data integrity or regulatory systems
# Health check that monitors cross-provider connectivity
#!/bin/bash
# Run from Swiss infrastructure, check cloud provider status
CLOUD_API="https://api.myapp.cloud/health"
SWISS_DB="localhost:5432"
ALERT_ENDPOINT="https://alerts.internal/dora-concentration"
cloud_status=$(curl -s -o /dev/null -w "%{http_code}" $CLOUD_API)
db_status=$(pg_isready -h localhost -p 5432)
if [ "$cloud_status" != "200" ] && [ "$db_status" = "accepting connections" ]; then
# Cloud is down but Swiss infrastructure is operational
# Activate failover procedures
curl -X POST $ALERT_ENDPOINT \
-d '{"event":"cloud_provider_outage","swiss_infra":"operational",
"action":"activate_resilience_continuity_plan"}'
fiCrypto and Digital Asset Companies Under DORA
DORA explicitly includes crypto-asset service providers (CASPs) licensed under MiCA within its scope. If you operate a crypto exchange, a custody provider, a DeFi protocol with a legal entity in the EU, or any crypto service that falls under MiCA regulation — DORA applies to you with the same force as it applies to traditional banks.
For crypto companies, the infrastructure requirements are particularly demanding. You are managing private keys, processing irreversible transactions, and operating systems where a security breach can result in immediate, unrecoverable financial loss. DORA's ICT risk management requirements amplify existing security best practices:
• Key management infrastructure must be documented, risk-assessed, and tested. Your HSM or cold storage setup is an ICT asset under DORA.
• Transaction processing systems must have documented RTOs and RPOs. If your matching engine goes down, how long until it is back? Can you prove it?
• Blockchain node infrastructure must be resilient. If your Ethereum nodes are all on the same cloud provider and that provider has an outage during a critical DeFi liquidation event, that is an ICT incident you must report.
• Wallet infrastructure requires full audit trails. Every signing operation, every key rotation, every access event must be logged and retained.
Swiss hosting has a natural fit for crypto infrastructure. Switzerland's "Crypto Valley" ecosystem in Zug and Zurich has produced a regulatory framework (DLT Act) that is among the most crypto-friendly in the world. Swiss-hosted infrastructure for crypto companies benefits from both FADP data protection and a regulatory environment that understands digital asset operations.
SaaS Companies: DORA Through Your Clients' Supply Chain
You do not need to be a financial entity to be affected by DORA. If your SaaS product serves banks, insurance companies, payment processors, or any DORA-regulated entity, you are an ICT third-party service provider in their supply chain. Your clients will start asking — if they haven't already — for DORA-compliant contracts, audit rights, and incident notification procedures.
The practical impact: your financial services clients will require you to demonstrate where their data is hosted, provide documentation of your ICT risk management practices, agree to audit provisions, and commit to incident notification timelines that are compatible with their own 4-hour reporting obligations.
If your infrastructure is on a major cloud provider, you are in a nested dependency situation. Your client depends on you. You depend on AWS. DORA requires your client to assess the risk of that entire chain. By hosting on infrastructure you directly control — such as managed Swiss infrastructure — you simplify that chain and make it easier for your clients to satisfy their DORA third-party risk management requirements.
What Regulators Will Actually Ask
When the European Supervisory Authorities (ESAs) come knocking — and they will, because DORA gives them direct oversight authority over "critical" ICT third-party providers — here is what they will want to see:
• Asset inventory — A complete list of ICT assets, including physical servers, their locations, configurations, and interconnections. Can you produce this on demand?
• Risk assessments — Documented analysis of ICT risks, including hosting provider concentration risk, data residency risk, and supply chain risk. Updated at least annually.
• Incident response plan — A tested plan that demonstrates your ability to detect, classify, and report incidents within DORA's timelines. Including evidence that you have tested it.
• Resilience testing results — Reports from vulnerability assessments, penetration tests, and (if applicable) TLPT exercises. Including remediation actions for identified vulnerabilities.
• Third-party contracts — Copies of your hosting agreements showing DORA-compliant provisions. Exit strategies, audit rights, data location disclosures.
• Business continuity evidence — Proof that your backup and disaster recovery procedures work. Not just that they exist — that they have been tested and the results documented.
Conclusion: Infrastructure Choices Are Compliance Choices
DORA transforms hosting infrastructure from a technical decision into a regulatory one. Where your servers are, who operates them, what contracts govern them, and how you monitor and test them — all of these are now compliance concerns with real enforcement consequences. Fines under DORA can reach up to 1% of average daily worldwide turnover, applied daily until remediation is complete.
Swiss-hosted dedicated infrastructure does not automatically make you DORA-compliant. No single choice does. But it gives you structural advantages that make compliance achievable without the contortions that opaque, multi-tenant cloud infrastructure requires. Direct hardware control for complete asset inventories. Full-stack access for incident forensics. Swiss jurisdiction for clean data residency answers. No subcontracting ambiguity. Physical auditability.
If you are building or refactoring infrastructure for a DORA-regulated entity — whether you are the financial entity itself or a SaaS provider in its supply chain — the hosting decision deserves the same attention as your application architecture. Get it right at the infrastructure layer, and every compliance requirement above it becomes simpler to satisfy.
Explore SwissLayer's Swiss dedicated servers and managed infrastructure options for your compliance-sensitive workloads. Single-tenant hardware, Swiss jurisdiction, full audit access — built for exactly this use case.