DDoS protection for financial services: compliance, architecture, and vendor selection

Compliance landscape

Financial institutions do not have the luxury of treating DDoS protection as optional. Multiple regulatory frameworks either explicitly or effectively require DDoS resilience as part of broader cybersecurity and operational risk management mandates.

PCI DSS 4.0

PCI DSS 4.0 (with all future-dated requirements now mandatory as of March 2025) does not mention "DDoS" by name, but several requirements create an effective DDoS protection mandate:

• Requirement 1 (Network Security Controls): Mandates firewalls, IPS, and network segmentation to protect the cardholder data environment (CDE). DDoS attacks that bypass or overwhelm these controls create a compliance gap.
• Requirement 6.4 (Public-Facing Web Applications): Requires protection for public-facing web applications against known attacks. HTTP/S DDoS floods targeting payment pages are in scope.
• Requirement 10 (Logging and Monitoring): Requires logging all access to cardholder data and monitoring for anomalies. A DDoS attack that disrupts logging infrastructure creates a material compliance failure because you cannot prove what happened during the disruption.
• Requirement 11.4 (External Penetration Testing): Requires regular testing including network resilience. Assessors increasingly expect DDoS resilience testing as part of this requirement.
• Requirement 12.10 (Incident Response): Requires a documented incident response plan that covers security incidents, including availability attacks. DDoS must be addressed in your incident response procedures.

Practical implication: PCI assessors expect to see documented DDoS detection capabilities, evidence of monitoring and alerting, and an incident response procedure that addresses DDoS specifically. Organizations without these controls face findings during assessments.

DORA (Digital Operational Resilience Act)

DORA (EU Regulation 2022/2554) has been enforceable since January 2025 and applies to all EU financial entities including banks, insurance companies, investment firms, payment service providers, and crypto-asset service providers. Its requirements directly address DDoS resilience:

• ICT Risk Management (Article 6): Financial entities must implement ICT risk management frameworks that identify, protect against, detect, respond to, and recover from ICT-related disruptions. DDoS attacks are explicitly in scope as an ICT disruption.
• Incident Reporting (Articles 17-19): Major ICT-related incidents must be reported to competent authorities. A DDoS attack that disrupts financial services is a reportable incident. Reports must include time of detection, impact assessment, and mitigation actions. Fast detection directly reduces reporting severity.
• Resilience Testing (Articles 24-27): Financial entities must regularly test their ability to detect, respond to, and recover from attack scenarios, including DDoS. This means tabletop exercises, technical testing, and for significant entities, threat-led penetration testing (TLPT).
• Third-Party Risk (Articles 28-30): If you rely on a third-party DDoS protection service, that provider is subject to DORA's third-party risk management requirements. You must assess their resilience, include audit rights in contracts, and maintain exit strategies.

Penalties: Up to EUR 10 million or 5% of annual turnover for non-compliance. For critical ICT third-party providers, penalties reach EUR 5 million or 1% of average daily worldwide turnover.

SOX (Sarbanes-Oxley Act)

SOX Section 404 requires internal controls over financial reporting. While SOX does not mention DDoS explicitly, auditors evaluate whether the organization has adequate controls to ensure the availability and integrity of financial reporting systems. A DDoS attack that prevents access to ERP systems, trading platforms, or financial databases during a reporting period could constitute a material weakness in internal controls.

SOX compliance effectively requires that financial reporting infrastructure has documented availability controls, including DDoS resilience, monitoring, and incident response.

Why detection time matters more in financial services

The financial impact of DDoS downtime is measured in transactions lost, not just minutes offline. Consider the math:

Each failed payment transaction carries a direct revenue loss, a customer experience cost, and potentially a regulatory reporting obligation. This is why financial services cannot accept the 2 to 10 minute detection windows that are common in flow-based or on-demand DDoS protection architectures.

Detection time targets by system criticality

• Tier 1 (payment processing, trading): Sub-second to 3-second detection. These systems handle real-time financial transactions where every second of disruption has measurable cost.
• Tier 2 (customer-facing portals, APIs): 3 to 10-second detection. These systems affect customer experience and generate support volume during outages.
• Tier 3 (internal systems, reporting): 10 to 30-second detection. Lower real-time impact but still subject to compliance requirements for availability and logging.

Agent-based detection achieves sub-second detection because it monitors packets directly at the server level. Flow-based detection (sFlow, NetFlow) typically achieves 5 to 15 second detection depending on sampling rate and flow export intervals. On-demand cloud scrubbing activation takes 2 to 10 minutes. Financial services should use agent-based detection for Tier 1 systems and flow-based detection for Tier 2 and 3 systems.

Reference architecture

Financial services DDoS protection should follow a defense-in-depth model with three distinct layers, each providing different capabilities and compliance evidence:

Layer 1: Edge protection

A cloud DDoS protection service (Cloudflare, Akamai Prolexic, AWS Shield Advanced, or Azure DDoS Protection) sits at the network edge and absorbs volumetric and application-layer attacks before traffic reaches your infrastructure.

What it provides: Massive scrubbing capacity (Cloudflare: 500+ Tbps, Akamai: 20+ Tbps), application-layer filtering (WAF rules, rate limiting, challenge pages), geographic distribution (attacks absorbed near their source), and cost protection (no overage fees during attacks).

What it does not provide: Server-side visibility, per-second packet-level metrics, PCAP captures, or protection for non-HTTP services on lower Cloudflare tiers.

Compliance evidence: Edge mitigation logs, attack reports, volume statistics. Useful for demonstrating that protection exists, but insufficient for detailed incident reconstruction.

Layer 2: Server-side detection

An agent-based detection tool runs on each server, monitoring traffic at the packet level in real time. This is the layer that provides sub-second detection, per-protocol visibility, and the forensic evidence that compliance frameworks require.

What it provides: Sub-second detection, per-second per-protocol traffic metrics, automatic PCAP capture during attacks, detection of attacks that bypass edge protection (IP leaks, internal attacks, non-HTTP protocols), and automated mitigation triggers (BGP FlowSpec, RTBH, scrubbing activation).

What it does not provide: Volumetric scrubbing capacity. The agent detects and triggers, but absorbing a 100 Gbps flood requires upstream scrubbing.

Compliance evidence: Per-second detection timestamps (proves detection time for incident reports), PCAP captures (forensic evidence for regulators), per-protocol traffic logs (demonstrates monitoring granularity), and automated mitigation timestamps (proves response time). This layer provides the strongest compliance evidence for PCI DSS Requirement 10, DORA incident reporting, and SOX control effectiveness.

Flowtriq provides this layer at $9.99/node/month, with sub-second detection, automated PCAP capture, multi-channel alerting, and BGP FlowSpec/RTBH automation.

Layer 3: Automated response

When the detection layer identifies an attack, automated response actions execute without human intervention:

• BGP FlowSpec rules propagated to edge routers within seconds, filtering attack traffic at the network level based on source IP, protocol, port, and packet characteristics.
• RTBH announcements as a fallback for attacks too large for FlowSpec filtering.
• Cloud scrubbing activation for volumetric attacks exceeding local capacity, triggered automatically via BGP or API.
• SIEM integration with Splunk, QRadar, or Sentinel for centralized logging and compliance reporting.
• Multi-channel alerts to SOC teams, management, and regulators as required by incident response procedures.

Vendor evaluation framework

Financial institutions should evaluate DDoS protection vendors against criteria that reflect both technical requirements and compliance obligations:

Red flags in vendor evaluation

Watch for these warning signs when evaluating DDoS protection vendors for financial services:

• No published detection time SLA. If the vendor cannot commit to a detection time, you cannot demonstrate compliance with incident response requirements.
• Per-attack pricing. Vendors that charge per mitigation event create a perverse incentive: the more attacks you face, the more you pay. Financial institutions should demand flat or per-node pricing.
• HTTP-only protection marketed as comprehensive. If the vendor only protects ports 80 and 443, your payment processing backend (custom TCP ports), FIX protocol interfaces, and database replication channels are unprotected.
• No PCAP or forensic capability. Compliance frameworks require evidence of what happened during an incident. Dashboard screenshots are not sufficient for regulators. Packet-level evidence is.
• Manual activation required. If mitigation requires a human to log in and click a button, your 2 AM attacks go unmitigated until someone wakes up.

Recommended architecture by institution size

Compliance evidence checklist

Ensure your DDoS protection deployment produces the following evidence for compliance audits:

1. Detection time logs: Per-second timestamps showing when each attack was first detected. Required for DORA incident reporting and PCI DSS Requirement 10.
2. Mitigation action logs: Timestamps and details of every mitigation action (FlowSpec rule deployed, RTBH activated, scrubbing triggered). Required for PCI DSS Requirement 12.10 (incident response) and DORA Article 17 (incident reporting).
3. PCAP captures: Packet-level evidence of attack traffic. Critical for forensic analysis and regulatory inquiries.
4. Traffic baseline reports: Historical traffic patterns demonstrating that detection thresholds are calibrated to your actual traffic. Required for PCI DSS Requirement 11 (monitoring) and DORA Article 24 (resilience testing).
5. Incident response records: Documented post-mortem for each attack including timeline, impact assessment, mitigation effectiveness, and lessons learned. Required by all three frameworks.
6. Testing evidence: Records of regular DDoS resilience testing, including tabletop exercises and technical tests. Required by DORA Article 24 and PCI DSS Requirement 11.4.
7. Third-party vendor assessments: Due diligence documentation for DDoS protection vendors, including SOC 2 reports, contract terms, and exit strategies. Required by DORA Articles 28-30.

Flowtriq provides sub-second detection, automated PCAP capture, per-second traffic logs, multi-channel alerting, and SIEM-compatible event export. At $9.99/node/month, it gives financial institutions the server-side detection layer and forensic evidence that compliance frameworks require, without the six-figure budgets of legacy DDoS appliances. Start a 14-day free trial with no credit card required.

Frequently asked questions

Related articles