DORA Compliance on Swiss Infrastructure: Building Operationally Resilient Fintech and Crypto Platforms

October 8, 2026

by SwissLayer 18 min read

DORA Compliance on Swiss Infrastructure for Fintech

Most fintech CTOs first heard about DORA sometime in 2023, nodded at it as another regulatory acronym, and moved on. Then January 17, 2025 arrived and it stopped being theoretical. The EU's Digital Operational Resilience Act (Regulation 2022/2554) is now enforceable law, and it applies to virtually every financial entity operating in or serving the European Union — banks, payment processors, crypto-asset service providers, insurance companies, investment firms, and critically, the ICT third-party service providers they depend on.

If you run a fintech platform or crypto exchange that touches EU customers, DORA applies to you. If you provide infrastructure to companies that fall under DORA, it applies to you too. And unlike GDPR, which primarily concerns data protection, DORA is specifically about operational resilience — can your systems survive disruptions, and can you prove it?

This is not a summary of the regulation. You can read the official text for that. This is a practical guide to what DORA actually requires from your infrastructure stack, how those requirements map to real technical decisions, and why managed Swiss infrastructure positions you well for compliance — not because Switzerland is in the EU, but precisely because of how Swiss hosting intersects with DORA's technical and jurisdictional requirements.

What DORA Actually Requires: The Five Pillars

DORA is built around five pillars that collectively define what "digital operational resilience" means for financial entities. Each pillar has specific technical implications for your infrastructure:

• ICT Risk Management — You need a comprehensive framework for identifying, protecting against, detecting, responding to, and recovering from ICT-related incidents. This is not a checkbox exercise. Regulators want documented processes, assigned responsibilities, and evidence that the framework actually works
• ICT-Related Incident Reporting — Major ICT incidents must be classified, documented, and reported to competent authorities within strict timelines. You need infrastructure that generates the telemetry required for accurate incident reports
• Digital Operational Resilience Testing — Regular testing of your ICT systems, including threat-led penetration testing (TLPT) for significant institutions. Your infrastructure needs to support testing without compromising production
• ICT Third-Party Risk Management — You must maintain a register of all ICT third-party arrangements, assess concentration risks, and ensure contractual provisions cover exit strategies and audit rights. Your hosting provider is squarely in this category
• Information Sharing — Voluntary sharing of cyber threat intelligence and vulnerability information between financial entities

The first four pillars have direct infrastructure implications. Let's break each one down into what it actually means for your servers, networks, and operations.

Pillar 1: ICT Risk Management Framework — What Your Infrastructure Must Support

Article 6 of DORA requires financial entities to establish an ICT risk management framework that is "comprehensive, well-documented, and regularly updated." The framework must cover identification of ICT assets, protection measures, detection capabilities, response procedures, and recovery plans. Translated to infrastructure decisions, this means:

Asset inventory and classification. You need a complete, current inventory of every ICT asset — servers, network devices, storage systems, applications, data stores, and their interdependencies. This is harder than it sounds. In cloud environments where infrastructure is ephemeral, maintaining an accurate inventory requires automation:

# Infrastructure asset discovery — automated inventory
# Run periodically and compare against your CMDB

# Enumerate running services
systemctl list-units --type=service --state=running \
  | grep -v "^UNIT" | awk '{print $1}' > /var/log/dora/active-services.txt

# Network listeners — what ports are open and what's behind them
ss -tlnp | awk 'NR>1 {print $4, $6}' > /var/log/dora/network-listeners.txt

# Installed packages with versions
dpkg-query -W -f='${Package}\t${Version}\t${Status}\n' \
  | grep "install ok installed" > /var/log/dora/installed-packages.txt

# Storage volumes and mount points
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID \
  > /var/log/dora/storage-inventory.txt

# Running containers (if using Docker/Podman)
docker ps --format '{{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}' \
  2>/dev/null > /var/log/dora/container-inventory.txt

# Compare against previous inventory
diff /var/log/dora/active-services.txt.prev \
     /var/log/dora/active-services.txt 2>/dev/null || true

Protection measures. DORA Article 9 requires "protection and prevention" measures including access control, encryption, network security, and vulnerability management. On the infrastructure side, this translates to:

• Network segmentation between production, staging, and management planes
• Encryption at rest for all data stores containing financial or personal data
• Encryption in transit for all internal and external communications
• Centralised access control with role-based permissions and multi-factor authentication
• Automated patch management with defined SLAs for critical vulnerabilities

This is where hosting choice matters. A dedicated server gives you hardware-level isolation that shared cloud environments cannot guarantee. When an auditor asks "who else has access to the physical hardware running your critical financial systems?" — the answer with dedicated Swiss infrastructure is "nobody."

Detection capabilities. Article 10 requires "mechanisms to promptly detect anomalous activities." Your infrastructure must generate enough telemetry to detect incidents in near-real-time:

# Baseline detection infrastructure for DORA compliance

# 1. System-level audit logging (auditd)
# /etc/audit/rules.d/dora-compliance.rules

# Log all authentication events
-w /var/log/auth.log -p wa -k auth_log
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity

# Log privilege escalation
-a always,exit -F arch=b64 -S setuid -S setgid -k privilege_escalation
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -k root_commands

# Log file system changes to critical paths
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/nginx/ -p wa -k nginx_config
-w /etc/tor/ -p wa -k tor_config

# Log network configuration changes
-w /etc/network/ -p wa -k network_config
-w /etc/resolv.conf -p wa -k dns_config

# 2. Network anomaly detection baseline
# Capture connection patterns for baseline comparison
ss -tnp | awk '{print $4, $5}' | sort | uniq -c | sort -rn \
  > /var/log/dora/connection-baseline-$(date +%Y%m%d).txt

# 3. File integrity monitoring
# Using AIDE (Advanced Intrusion Detection Environment)
sudo apt install -y aide
sudo aideinit
# Schedule daily checks
echo "0 3 * * * root /usr/bin/aide --check" \
  | sudo tee /etc/cron.d/aide-dora

Response and recovery. Articles 11 and 12 require documented ICT business continuity policies and response plans. Your infrastructure must support defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). This means tested backups, documented failover procedures, and — critically — evidence that you have actually tested them.

Pillar 2: Incident Reporting — The Infrastructure Telemetry Problem

DORA's incident reporting requirements (Articles 17-23) are where most fintech platforms discover their infrastructure gaps. When a major ICT incident occurs, you must submit an initial notification within 4 hours of classifying the incident, an intermediate report within 72 hours, and a final report within one month. The reports must include:

• Timeline of the incident (when it started, when detected, when resolved)
• Root cause analysis
• Impact assessment (number of affected clients, financial impact, cross-border effects)
• Remediation measures taken and planned

You cannot produce accurate incident reports without infrastructure that captures the right data. The 4-hour initial notification window means you need detection systems that classify incidents automatically — you do not have time to manually correlate logs across 15 different systems to determine whether something qualifies as "major."

# Incident classification framework aligned with DORA criteria
# DORA classifies incidents as "major" based on these factors:

# 1. Number of clients affected
# 2. Duration of the incident
# 3. Geographic spread
# 4. Data losses
# 5. Impact on critical services
# 6. Economic impact

# Automated incident severity classification
# /usr/local/bin/dora-incident-classify.sh

#!/bin/bash
# Input: incident metrics from monitoring system
# Output: DORA classification and reporting requirements

AFFECTED_CLIENTS=${1:-0}
DURATION_MINUTES=${2:-0}
DATA_LOSS=${3:-false}       # true/false
CRITICAL_SERVICE=${4:-false} # true/false
CROSS_BORDER=${5:-false}    # true/false

SEVERITY="minor"
REPORT_REQUIRED=false

# Classification logic based on DORA RTS criteria
if [ "$AFFECTED_CLIENTS" -gt 10000 ] || \
   [ "$DURATION_MINUTES" -gt 120 ] || \
   [ "$DATA_LOSS" = "true" ] || \
   [ "$CRITICAL_SERVICE" = "true" ]; then
    SEVERITY="major"
    REPORT_REQUIRED=true
fi

if [ "$CROSS_BORDER" = "true" ] && [ "$SEVERITY" = "major" ]; then
    SEVERITY="major-cross-border"
fi

echo "Classification: $SEVERITY"
echo "Regulatory report required: $REPORT_REQUIRED"
if [ "$REPORT_REQUIRED" = "true" ]; then
    echo "Initial notification deadline: $(date -d '+4 hours' -Iseconds)"
    echo "Intermediate report deadline: $(date -d '+72 hours' -Iseconds)"
    echo "Final report deadline: $(date -d '+1 month' -Iseconds)"
fi

The infrastructure requirement here is centralised, tamper-evident logging with accurate timestamps. Every component in your stack — web servers, application servers, databases, load balancers, firewalls, authentication systems — must send structured logs to a central collector with synchronised clocks. We covered building tamper-proof audit trails in a previous post, and those same principles apply directly to DORA incident reporting.

Swiss infrastructure adds a specific advantage here: log data residency. DORA requires that incident data and reports be available to EU supervisory authorities, but it does not require that raw infrastructure logs be stored in the EU. Storing your operational logs on GDPR-compliant hosting in Switzerland — an adequate jurisdiction under GDPR — means your log data is protected by both the Swiss FADP and by EU adequacy recognition, without the jurisdictional complications of hosting logs in a non-adequate third country.

Pillar 3: Digital Operational Resilience Testing

Articles 24-27 require regular testing of your ICT systems. The testing requirements scale with the significance of the financial entity:

• All entities: Vulnerability assessments, network security testing, source code reviews, scenario-based testing, compatibility testing, performance testing, and penetration testing — at least annually
• Significant entities: Threat-led penetration testing (TLPT) at least every three years, using external testers with specific qualifications, following the TIBER-EU framework or equivalent

Your infrastructure must support these testing requirements without compromising production operations. This means:

Isolated testing environments. You need the ability to spin up production-equivalent environments for testing that are network-isolated from actual production systems. On dedicated hardware, this is straightforward — allocate specific servers or VLANs for testing. In shared cloud environments, achieving true isolation is more complex and harder to prove to auditors:

# Production-equivalent test environment setup
# Using network namespaces for isolation on dedicated hardware

# Create isolated network namespace for DORA testing
sudo ip netns add dora-test

# Create veth pair connecting test namespace to host
sudo ip link add veth-test type veth peer name veth-prod
sudo ip link set veth-test netns dora-test

# Configure test namespace networking
sudo ip netns exec dora-test ip addr add 10.99.0.2/24 dev veth-test
sudo ip netns exec dora-test ip link set veth-test up
sudo ip netns exec dora-test ip link set lo up

# Host side
sudo ip addr add 10.99.0.1/24 dev veth-prod
sudo ip link set veth-prod up

# Firewall rules — test namespace cannot reach production
sudo iptables -I FORWARD -i veth-prod -d 10.0.0.0/8 -j DROP
sudo iptables -I FORWARD -i veth-prod -d 172.16.0.0/12 -j DROP
# Allow only specific test targets
sudo iptables -I FORWARD -i veth-prod -d 10.99.0.0/24 -j ACCEPT

# Run penetration test tools inside the isolated namespace
sudo ip netns exec dora-test /bin/bash
# Now inside isolated network — cannot reach production

Evidence collection during testing. DORA requires that test results be documented and that remediation plans be tracked. Your testing infrastructure needs to produce auditable output — not just "test passed" or "test failed," but detailed evidence of what was tested, how, what was found, and what was done about it:

# Automated evidence collection for DORA resilience testing
# Produces structured output for auditor review

REPORT_DIR="/var/log/dora/testing/$(date +%Y-%m-%d)"
mkdir -p "$REPORT_DIR"

# 1. Vulnerability scan with evidence
echo "=== DORA Resilience Test Report ===" > "$REPORT_DIR/summary.txt"
echo "Date: $(date -Iseconds)" >> "$REPORT_DIR/summary.txt"
echo "Tester: [internal/external identifier]" >> "$REPORT_DIR/summary.txt"
echo "Scope: Production infrastructure" >> "$REPORT_DIR/summary.txt"
echo "" >> "$REPORT_DIR/summary.txt"

# 2. Port scan baseline
nmap -sV -O -oX "$REPORT_DIR/port-scan.xml" \
  --script vuln localhost 2>/dev/null

# 3. SSL/TLS configuration test
echo "--- TLS Configuration ---" >> "$REPORT_DIR/summary.txt"
openssl s_client -connect localhost:443 -tls1_2 /dev/null \
  | openssl x509 -noout -dates -subject -issuer \
  >> "$REPORT_DIR/summary.txt"

# 4. Configuration compliance check
echo "--- Configuration Compliance ---" >> "$REPORT_DIR/summary.txt"

# Check: SSH hardened
grep -E "^(PasswordAuthentication|PermitRootLogin|Protocol)" \
  /etc/ssh/sshd_config >> "$REPORT_DIR/summary.txt"

# Check: Firewall active
ufw status verbose >> "$REPORT_DIR/firewall-status.txt"

# Check: Disk encryption
lsblk -o NAME,FSTYPE,MOUNTPOINT | grep -i crypt \
  >> "$REPORT_DIR/encryption-status.txt"

# 5. Backup recovery test evidence
echo "--- Backup Recovery Test ---" >> "$REPORT_DIR/summary.txt"
echo "Last backup: $(ls -lt /var/backups/ 2>/dev/null | head -2)" \
  >> "$REPORT_DIR/summary.txt"

# Generate SHA-256 hash of all evidence files
find "$REPORT_DIR" -type f -exec sha256sum {} \; \
  > "$REPORT_DIR/evidence-hashes.txt"

echo "Evidence collected in: $REPORT_DIR"

For threat-led penetration testing (TLPT), DORA specifies that the testing must be conducted by qualified external parties and must cover the entity's critical functions. Your infrastructure provider needs to support this — providing the access, documentation, and cooperation that external testers require without compromising operational security. This is one area where having a managed Swiss infrastructure provider with clear contracts and defined audit support processes simplifies the compliance burden significantly.

Pillar 4: Third-Party ICT Risk — Why Your Hosting Provider Is in Scope

This is the pillar that makes hosting providers sit up and pay attention. Articles 28-44 of DORA establish detailed requirements for managing ICT third-party risk, and your hosting provider is explicitly an "ICT third-party service provider" under the regulation.

DORA requires financial entities to:

• Maintain a register of all contractual arrangements with ICT third-party providers, including sub-outsourcing chains
• Conduct pre-contractual due diligence assessing the provider's ICT risk management capabilities
• Include mandatory contractual clauses covering service levels, data locations, audit rights, incident notification, exit strategies, and sub-outsourcing restrictions
• Assess concentration risk — are too many critical functions dependent on a single provider or a small group of providers?
• Develop exit strategies for every critical or important function outsourced to a third party

The contractual requirements alone are substantial. Article 30 specifies that contracts with ICT third-party providers must include:

• Clear description of all functions and services provided
• Locations where data will be processed and stored (including sub-processors)
• Service level descriptions with quantitative and qualitative performance targets
• Notice periods and reporting obligations for the provider
• Rights of access, inspection, and audit by the financial entity, its auditors, and competent authorities
• Termination rights and adequate transition periods
• Data portability, application portability, and interoperability guarantees
• Incident notification requirements

This is where the choice between hyperscaler cloud and dedicated managed infrastructure becomes a compliance decision, not just a technical one.

With a major cloud provider, your "contractual arrangement" is a standard terms of service document that you accepted by clicking a button. Good luck negotiating custom audit rights or incident notification timelines with a company that has 200,000 other customers on the same platform. The provider's sub-processing chain extends through dozens of data centres across multiple jurisdictions, each with their own sub-contractors.

With Swiss managed infrastructure, the relationship is different. You have a named account contact. The contract is negotiable. The data location is specific and verifiable — your data is in a known Swiss data centre, on identified hardware, with a defined chain of custody. Audit rights are practical because the scale allows it. Exit strategies are realistic because your infrastructure runs on standard hardware with standard software — not on proprietary cloud services that create lock-in by design.

The Concentration Risk Problem

DORA's concentration risk requirements (Article 29) deserve special attention because they challenge a widespread industry pattern. If your fintech platform runs on AWS, your competitor's platform runs on AWS, and the payment processor you both use runs on AWS — that is concentration risk. A single disruption at the provider level cascades across the financial system.

The European Supervisory Authorities (ESAs) can designate ICT third-party providers as "critical" if they serve a significant portion of the financial sector. Critical providers face direct oversight and can be required to make changes to their operations. This is new territory — regulators gaining direct authority over technology companies that are not themselves financial institutions.

For fintech CTOs, the practical implication is this: your choice of infrastructure provider is now a regulatory risk factor. Choosing the same hyperscaler as everyone else in your sector increases your concentration risk profile, which increases your regulatory burden, which increases your compliance costs.

Using Swiss managed infrastructure from a provider that is not a designated critical third-party reduces this concentration risk. It does not eliminate third-party risk (you still depend on a provider), but it diversifies your dependency away from the providers most likely to trigger concentration risk scrutiny. This is not a marketing argument — it is how the regulation works.

Sub-Outsourcing Chains and Data Location

DORA Article 29(2) requires that contracts address "the possibility for the ICT third-party service provider to further sub-outsource critical or important functions." You need to know — and be able to demonstrate to regulators — where your data actually is and who can access it at every level of the supply chain.

With Swiss dedicated infrastructure, the sub-outsourcing chain is short and transparent:

• Layer 1: Your managed infrastructure provider (SwissLayer) — operates the servers, network, and management layer
• Layer 2: The data centre facility — provides power, cooling, physical security, and network connectivity
• Layer 3: Upstream network carriers — provides internet transit

Each layer is identifiable, contractually bound, and subject to Swiss law. Compare this to a hyperscaler cloud deployment where the sub-outsourcing chain might include: the cloud provider, their data centre operators (which may be third parties), their network providers, their hardware vendors (some of whom have remote management capabilities), their content delivery partners, and their support contractors. Mapping this chain for DORA compliance is a project in itself.

# DORA Third-Party Register — Template for infrastructure documentation
# Article 28(3) requires maintaining a register of all ICT third-party arrangements

# /var/log/dora/third-party-register.json
{
  "register_version": "1.0",
  "last_updated": "2026-10-08",
  "entity": "Your Fintech Company",
  "arrangements": [
    {
      "provider": "Infrastructure Provider",
      "function": "Managed dedicated server hosting",
      "criticality": "critical",
      "data_locations": ["Switzerland - Zurich DC"],
      "sub_outsourcing": [
        {
          "sub_provider": "Data Centre Operator",
          "function": "Facility management (power, cooling, physical security)",
          "location": "Switzerland"
        },
        {
          "sub_provider": "Network Transit Provider",
          "function": "Internet connectivity",
          "location": "Switzerland, with peering in Frankfurt and Amsterdam"
        }
      ],
      "contract_details": {
        "start_date": "2026-01-01",
        "term": "24 months",
        "notice_period": "90 days",
        "audit_rights": true,
        "incident_notification_sla": "1 hour for critical incidents",
        "data_portability": "Full server image export within 48 hours",
        "exit_strategy": "Documented migration plan with 90-day transition support"
      },
      "risk_assessment": {
        "last_assessed": "2026-09-15",
        "risk_level": "medium",
        "concentration_risk": "low",
        "notes": "Non-hyperscaler provider reduces concentration risk"
      }
    }
  ]
}

Building Your ICT Risk Management Framework on Swiss Infrastructure

Let's get practical. Here is how to structure an ICT risk management framework that satisfies DORA requirements on Swiss dedicated infrastructure. This is not theoretical — these are the components you actually need to deploy and maintain:

1. Continuous asset discovery and classification.

# Automated asset discovery running daily via cron
# Stores results in structured format for DORA reporting

#!/bin/bash
# /usr/local/bin/dora-asset-discovery.sh

ASSET_DIR="/var/log/dora/assets"
DATE=$(date +%Y-%m-%d)
mkdir -p "$ASSET_DIR"

# Hardware inventory
dmidecode -t system 2>/dev/null | grep -E "(Manufacturer|Product|Serial)" \
  > "$ASSET_DIR/hardware-$DATE.txt"

# CPU and memory
lscpu | grep -E "(Model name|Socket|Core|Thread)" \
  >> "$ASSET_DIR/hardware-$DATE.txt"
free -h >> "$ASSET_DIR/hardware-$DATE.txt"

# Storage devices with SMART health
for disk in $(lsblk -dno NAME | grep -E "^(sd|nvme)"); do
    smartctl -H "/dev/$disk" 2>/dev/null \
      >> "$ASSET_DIR/storage-health-$DATE.txt"
done

# Network interfaces and configuration
ip addr show > "$ASSET_DIR/network-$DATE.txt"
ip route show >> "$ASSET_DIR/network-$DATE.txt"

# Software inventory with versions
dpkg-query -W -f='${Package}\t${Version}\n' \
  > "$ASSET_DIR/software-$DATE.txt"

# Running services
systemctl list-units --type=service --state=running --no-pager \
  > "$ASSET_DIR/services-$DATE.txt"

# Container inventory
docker ps --no-trunc --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}' \
  2>/dev/null > "$ASSET_DIR/containers-$DATE.txt"

# Cryptographic inventory — certificates and their expiry
find /etc/ssl /etc/letsencrypt -name "*.pem" -o -name "*.crt" 2>/dev/null \
  | while read cert; do
    echo "--- $cert ---"
    openssl x509 -in "$cert" -noout -subject -enddate 2>/dev/null
done > "$ASSET_DIR/certificates-$DATE.txt"

# Generate change report vs previous day
PREV="$ASSET_DIR/software-$(date -d 'yesterday' +%Y-%m-%d).txt"
if [ -f "$PREV" ]; then
    diff "$PREV" "$ASSET_DIR/software-$DATE.txt" \
      > "$ASSET_DIR/changes-$DATE.txt" 2>/dev/null
fi

2. Vulnerability management with defined SLAs.

DORA does not prescribe specific patching timelines, but it requires that your ICT risk management framework includes "timely" remediation of identified vulnerabilities. Define and document your SLAs:

• Critical vulnerabilities (CVSS 9.0+): Patch or mitigate within 24 hours
• High vulnerabilities (CVSS 7.0-8.9): Patch within 7 days
• Medium vulnerabilities (CVSS 4.0-6.9): Patch within 30 days
• Low vulnerabilities (CVSS below 4.0): Patch in next maintenance window

# Automated vulnerability checking
# Integrates with DORA vulnerability management SLAs

# Check for pending security updates
apt list --upgradable 2>/dev/null | grep -i security

# Check against known CVEs for installed packages
# Using Ubuntu/Debian security tracker
apt-get changelog $(dpkg -l | awk '/^ii/ {print $2}' | head -50) 2>/dev/null \
  | grep -i "CVE-" | sort -u | tail -20

# Kernel vulnerability check
KERNEL=$(uname -r)
echo "Current kernel: $KERNEL"
apt list --installed 2>/dev/null | grep "linux-image-$KERNEL"

# Enable automatic security updates with logging
# /etc/apt/apt.conf.d/50unattended-upgrades
# Unattended-Upgrade::Allowed-Origins {
#     "${distro_id}:${distro_codename}-security";
# };
# Unattended-Upgrade::Mail "security@yourcompany.com";
# Unattended-Upgrade::MailReport "on-change";

3. Backup and recovery with tested RTOs.

DORA Article 12 requires ICT business continuity policies that include "recovery time and recovery point objectives for each function." You need to define these, implement backup strategies that achieve them, and — this is the part most organisations skip — regularly test that your backups actually restore within the required timeframe.

# DORA-compliant backup verification script
# Tests actual restore capability, not just backup existence

#!/bin/bash
# /usr/local/bin/dora-backup-test.sh

REPORT="/var/log/dora/backup-test-$(date +%Y-%m-%d).txt"
echo "=== DORA Backup Recovery Test ===" > "$REPORT"
echo "Date: $(date -Iseconds)" >> "$REPORT"

# Define RTOs per service tier
# Tier 1 (critical): RTO 4 hours, RPO 1 hour
# Tier 2 (important): RTO 12 hours, RPO 4 hours
# Tier 3 (standard): RTO 48 hours, RPO 24 hours

# 1. Verify backup recency against RPO
echo "" >> "$REPORT"
echo "--- Backup Recency Check ---" >> "$REPORT"

LATEST_BACKUP=$(ls -t /var/backups/*.tar.gz 2>/dev/null | head -1)
if [ -n "$LATEST_BACKUP" ]; then
    BACKUP_AGE_HOURS=$(( ($(date +%s) - $(stat -c %Y "$LATEST_BACKUP")) / 3600 ))
    echo "Latest backup: $LATEST_BACKUP" >> "$REPORT"
    echo "Backup age: ${BACKUP_AGE_HOURS} hours" >> "$REPORT"
    
    if [ "$BACKUP_AGE_HOURS" -gt 1 ]; then
        echo "WARNING: Backup age exceeds Tier 1 RPO (1 hour)" >> "$REPORT"
    fi
    if [ "$BACKUP_AGE_HOURS" -gt 4 ]; then
        echo "CRITICAL: Backup age exceeds Tier 2 RPO (4 hours)" >> "$REPORT"
    fi
else
    echo "CRITICAL: No backup files found" >> "$REPORT"
fi

# 2. Test restore integrity (to isolated directory)
echo "" >> "$REPORT"
echo "--- Restore Integrity Test ---" >> "$REPORT"
RESTORE_START=$(date +%s)

RESTORE_DIR=$(mktemp -d /tmp/dora-restore-XXXXX)
if tar xzf "$LATEST_BACKUP" -C "$RESTORE_DIR" 2>/dev/null; then
    RESTORE_END=$(date +%s)
    RESTORE_TIME=$((RESTORE_END - RESTORE_START))
    FILE_COUNT=$(find "$RESTORE_DIR" -type f | wc -l)
    echo "Restore successful: $FILE_COUNT files in ${RESTORE_TIME}s" >> "$REPORT"
else
    echo "CRITICAL: Backup restore FAILED" >> "$REPORT"
fi
rm -rf "$RESTORE_DIR"

# 3. Database backup test (if applicable)
echo "" >> "$REPORT"
echo "--- Database Backup Verification ---" >> "$REPORT"
if command -v pg_restore &>/dev/null; then
    DB_BACKUP=$(ls -t /var/backups/db/*.sql.gz 2>/dev/null | head -1)
    if [ -n "$DB_BACKUP" ]; then
        # Test restore to temporary database
        gunzip -t "$DB_BACKUP" 2>/dev/null
        if [ $? -eq 0 ]; then
            echo "Database backup integrity: OK ($DB_BACKUP)" >> "$REPORT"
        else
            echo "CRITICAL: Database backup corrupt" >> "$REPORT"
        fi
    fi
fi

echo "" >> "$REPORT"
echo "=== Test Complete ===" >> "$REPORT"
cat "$REPORT"

DORA and Swiss FADP: The Dual Compliance Advantage

Here is where Swiss infrastructure creates a unique compliance position. Switzerland is not an EU member state, which means DORA does not apply directly to Swiss financial entities. However, Switzerland's own financial regulation — enforced by FINMA — imposes operational resilience requirements that substantially overlap with DORA. And the Swiss FADP provides data protection standards that the EU recognises as adequate.

For a fintech or crypto platform that serves EU customers from Swiss infrastructure, this creates a dual compliance advantage:

• Swiss managed infrastructure satisfies DORA's data location transparency requirements. You can tell regulators exactly where your data is — in a named Swiss data centre — and demonstrate that the jurisdiction provides adequate data protection. No ambiguity about which region, which availability zone, or which shared infrastructure your data might move through
• Swiss FADP alignment strengthens your GDPR compliance posture. DORA does not replace GDPR — financial entities must comply with both. Running on GDPR-compliant hosting in a jurisdiction with an EU adequacy decision means your infrastructure satisfies the data protection requirements of both regulations simultaneously
• Swiss neutrality provides jurisdictional stability. DORA's third-party risk requirements include assessing "political risk" associated with ICT providers. Swiss hosting, with its tradition of political neutrality and independence from EU political dynamics, represents low jurisdictional risk — your infrastructure is not subject to the same geopolitical pressures as hosting in countries within political blocs
• Swiss data residency simplifies cross-border data transfer analysis. Under GDPR and DORA together, you need to document and justify any cross-border transfers of financial data. With swiss data residency, your data stays in Switzerland — an adequate jurisdiction — eliminating the need for Standard Contractual Clauses, Transfer Impact Assessments, or supplementary measures that would be required for data stored in non-adequate third countries

Crypto-Asset Service Providers: DORA Plus MiCA

If you operate a crypto exchange, custody service, or any other crypto-asset service provider (CASP) under MiCA (Markets in Crypto-Assets Regulation), DORA applies to you with specific additional considerations. CASPs are explicitly included in DORA's scope (Article 2(1)(f)), which means the same ICT risk management, incident reporting, resilience testing, and third-party risk requirements apply.

For crypto platforms specifically, the infrastructure implications are amplified:

• Hot wallet infrastructure is a critical function. Any disruption to wallet management systems has immediate financial impact. Your ICT risk management framework must treat wallet infrastructure as Tier 1 — shortest RTO, smallest RPO, highest protection level
• Blockchain node infrastructure adds complexity. If you run your own nodes (and for security-conscious platforms, you should), those nodes are ICT assets under DORA that need to be inventoried, monitored, and included in your resilience testing
• Key management is existential. Losing cryptographic keys means losing customer assets. DORA's requirements for ICT risk management around "cryptographic key management" (Article 9(4)(d)) are directly applicable and carry high stakes in a crypto context
• 24/7 operations. Crypto markets do not close. Your incident detection and response capabilities must operate continuously, not just during business hours. Your infrastructure must be monitored around the clock

Running crypto infrastructure on fintech swiss hosting — with hardware-level isolation, full-disk encryption, and a jurisdiction that does not compel key disclosure — addresses several of these requirements architecturally rather than through policy alone.

Exit Strategies: The Requirement Everyone Ignores

DORA Article 28(8) requires financial entities to "put in place exit strategies" for ICT third-party arrangements, particularly those supporting critical or important functions. This means documented, tested plans for migrating away from every ICT third-party provider you use — including your hosting provider.

This requirement is why infrastructure portability matters. If your application is built on proprietary cloud services — Lambda functions, DynamoDB tables, Cloud Spanner, proprietary AI/ML services — your exit strategy is essentially "rewrite the application." That is not a credible exit strategy under DORA.

Swiss managed infrastructure based on standard technologies creates realistic exit strategies:

• Standard operating systems (Debian, Ubuntu, RHEL) run on any compatible hardware
• Standard databases (PostgreSQL, MariaDB) export and import cleanly
• Standard containerisation (Docker, Kubernetes) is portable by design
• Standard backup formats (filesystem images, database dumps) are provider-independent
• No proprietary service dependencies — no lock-in to provider-specific APIs or services

# DORA Exit Strategy Documentation Template
# /var/log/dora/exit-strategy.md

# Exit Strategy: Infrastructure Provider Migration
# Last tested: [date]
# Next test: [date + 12 months]

## Critical Data Inventory
# What data needs to migrate:
# 1. Application databases (PostgreSQL) — [X] GB
# 2. File storage (user uploads, documents) — [X] GB
# 3. Configuration and secrets — Vault export
# 4. SSL certificates and private keys
# 5. Audit logs (retention requirement: [X] years)

## Migration Procedure
# Step 1: Provision equivalent infrastructure at target provider
# Step 2: Configure networking and security baseline
# Step 3: Sync data using rsync/pg_dump (estimated time: [X] hours)
# Step 4: DNS TTL reduction (48h before cutover)
# Step 5: Final sync and cutover
# Step 6: Verify functionality on target
# Step 7: DNS update to target
# Step 8: Monitor for [X] days
# Step 9: Decommission source infrastructure

## Estimated Timeline
# Total migration: [X] business days
# Maximum acceptable downtime: [X] hours
# Data transfer window: [X] hours

## Dependencies
# - Target provider must support: [list requirements]
# - DNS changes propagation: max 48 hours
# - Certificate reissuance: max 24 hours

## Last Test Results
# Date: [date]
# Test scope: [partial/full]
# Result: [pass/fail]
# Issues found: [list]
# Remediation: [list]

Implementation Roadmap: Where to Start

If you are reading this and your fintech or crypto platform does not yet have a DORA compliance programme in place, the regulation is already enforceable and you are behind. Here is a pragmatic roadmap for getting caught up, prioritised by regulatory risk:

Phase 1: Immediate (weeks 1-4)

• Complete your ICT third-party register — document every provider, data location, and contractual arrangement
• Implement centralised logging with tamper-evident storage
• Establish your incident classification and reporting procedures
• Review existing contracts with ICT providers against DORA Article 30 requirements
• Assign ICT risk management roles and responsibilities

Phase 2: Foundation (months 2-3)

• Deploy automated asset discovery and inventory
• Implement vulnerability scanning with defined remediation SLAs
• Document your ICT risk management framework (policies, procedures, ownership)
• Establish backup testing procedures and verify RTOs/RPOs
• Begin exit strategy documentation for critical third-party arrangements

Phase 3: Maturity (months 4-6)

• Conduct first round of resilience testing (vulnerability assessments, penetration testing)
• Test your incident reporting procedures with tabletop exercises
• Test exit strategies for at least one critical provider
• Implement continuous monitoring and anomaly detection
• Prepare for TLPT if your entity is classified as significant

Phase 4: Ongoing

• Annual resilience testing cycle
• Quarterly ICT third-party register review
• Monthly vulnerability management reporting
• Continuous incident detection and response
• Annual review and update of the ICT risk management framework

The Honest Assessment

DORA is a serious regulation with real teeth. The European Supervisory Authorities have direct oversight powers, including the ability to conduct inspections, request information, and issue recommendations that financial entities must comply with or explain. Non-compliance carries administrative penalties and potentially the suspension of activities.

But DORA is also, fundamentally, common sense formalised. If you are running a fintech platform that handles people's money, you should already have an ICT risk management framework, incident reporting procedures, resilience testing, and vendor management. DORA codifies what good operational practice looks like and makes it enforceable.

The infrastructure decisions you make affect how hard or easy compliance will be. Choosing EU jurisdiction infrastructure through a Swiss provider with clear contracts, transparent sub-outsourcing chains, hardware-level isolation, and standard technologies makes DORA compliance a documentation and process exercise rather than an infrastructure transformation project. Choosing a complex cloud deployment with proprietary dependencies, opaque sub-outsourcing, and shared multi-tenant infrastructure makes compliance harder, more expensive, and more brittle.

Swiss hosting does not make you DORA-compliant by itself — nothing does. Compliance is a function of your entire ICT risk management programme, not any single vendor or technology choice. But the right infrastructure foundation makes everything else simpler. Hardware you control. A jurisdiction you trust. Contracts you can actually negotiate. Data locations you can pinpoint. Exit strategies that work. That is what operational resilience looks like when you build it from the ground up on managed swiss cloud infrastructure designed for regulated workloads.

Your regulators will audit your infrastructure choices. Make sure you can explain them.