Are concerns mounting about the financial and regulatory fallout if a payment platform is breached? This guide explains, in plain British English, exactly what third‑party payment processors and gateways need to know about cyber insurance, what policies typically cover, how GDPR and PCI DSS affect claims, how to assess exposure, and practical steps to improve insurability.
Key takeaways: what to know in 1 minute
- Third‑party payment processors face concentration and regulatory risk: a single incident can create large aggregated losses across many merchants and cardholders.
- Typical cyber policies for payment processors include breach response, liability to merchants and customers, regulatory fines defence (limited in UK) and business interruption, but wording varies widely.
- PCI DSS and GDPR materially affect cover and claims outcomes: non‑compliance can lead to declined claims or additional endorsements.
- Underwriters focus on controls that reduce PAN exposure: tokenisation, HSMs, segmentation, logging and vendor management are common gating factors.
- A subscription‑style underwriting approach is common for large volumes; premium and limits depend heavily on transaction volume, average ticket size and concentration.
Why cyber insurance matters for third-party payment processors
Third‑party payment processors and gateways act as critical infrastructure in the payments ecosystem. They store, process or transmit cardholder data (PANs), handle authentication flows and often host merchant configuration and settlement data. A breach can cause several simultaneous losses: regulatory investigations, card‑scheme fines, remediation costs, fraud losses to merchants and cardholders, brand damage and large business interruption claims when payments stop.
For UK SMEs acting as payment processors (including microbusinesses offering white‑label services), cyber insurance is a risk‑transfer tool that can: reduce immediate cashflow shock from incident response; fund forensic and legal costs; provide crisis communications support; and, in some policies, cover liabilities to affected merchants and customers. However, cover is not automatic and depends on policy wordings, endorsements and the provider’s assessment of technical controls and contractual obligations.
Links to key UK institutions that set expectations for security and reporting:
- ICO (data protection and breach reporting)
- NCSC (cybersecurity guidance)
- PCI DSS (card security standard)
Typical policy cover for payment processors and gateways
Policies marketed at payment processors often contain overlapping modules. The exact scope depends on insurer wordings and endorsements, but the following are commonly offered:
- Breach response and forensics: costs to appoint incident response teams, digital forensics, legal advice and notifying affected parties.
- Data breach liability: third‑party claims from merchants or customers for negligence in handling personal data or card data.
- Regulatory and investigation costs: legal defence costs and sometimes fines or penalties, note that UK regulatory fines (ICO) are subject to public policy and many insurers restrict or exclude direct payment of statutory fines; defence costs may be insured while fines are limited.
- PCI‑related liabilities: claims arising from failure to maintain PCI DSS controls, costs from card scheme fines, frequently subject to strict conditions.
- Fraud and funds transfer fraud: coverage for social‑engineering and authorised push payment style losses may be limited and often requires specific extensions.
- Business interruption (BI): loss of gross profit, increased costs of working and loss resulting from a denial of service or system outage, commonly measured to the processor's revenue or fees.
- Contingent business interruption and dependent business interruption: losses to merchants when a processor’s outage causes merchant revenue loss can trigger large contingent BI claims if included.
- Technology errors and omissions (E&O): indemnity for errors in software, misconfiguration, API faults or incorrect processing that cause client losses.
Examples of policy limits and layers (indicative)
| Cover type |
Typical limit (SME) |
Common deductible |
| Breach response and forensics |
£50,000–£250,000 |
£1,000–£10,000 |
| Third‑party liability (E&O, data breach) |
£250,000–£5,000,000 |
£5,000–£50,000 |
| Business interruption / contingent BI |
Insured limit often linked to revenue; negotiable |
Period of indemnity / waiting period applies |
Figures are indicative at time of writing and will vary by insurer and underwriting appetite.
Clause and wording points to request or check
- Clear definition of "insured event" for denial‑of‑service and ransomware incidents.
- Explicit cover for card‑scheme fines and assessments, or a named endorsement for PCI DSS penalties.
- Wording that clarifies whether merchant chargebacks resulting from data exposure are covered.
- Definition of insured persons (does it include sub‑processors, affiliated merchants?).
GDPR, PCI DSS and obligations for payment processors
Regulatory frameworks directly affect insurability and claims handling.
-
GDPR: Processors must meet obligations under the Data Protection Act and GDPR for security, notification and contractual flow‑down. The ICO may impose fines and enforcement notices. Many insurers will cover defence costs relating to regulatory investigations but exclude civil fines or place limits on fines; policyholders should check the fines and penalties clause carefully. See ICO guidance for breach reporting timescales.
-
PCI DSS: The Payment Card Industry Data Security Standard is mandatory for organisations handling card data. Non‑compliance discovered after an incident often leads to card‑scheme penalties. Insurers typically ask for evidence of PCI compliance (AOC, ASV scan reports, attestation) at application and may decline cover or apply endorsements if serious non‑compliances exist.
-
PSD2 and FCA considerations: Where a processor provides payment services regulated under PSD2 and the firm is FCA‑authorised or contracts with FCA‑authorised entities, additional contractual and regulatory expectations exist. While the FCA does not mandate insurance, it expects firms to manage operational resilience. Reference: FCA.
Practical implications for claims
- Failure to follow notification duties under GDPR (72 hours to notify ICO where feasible) can complicate defence costs and remedies.
- Lack of PCI attestation at the time of loss can lead to card‑scheme positions that increase exposures and may lead to insurer investigation and possible denial.
- Evidence of a robust compliance programme (policies, training, quarterly scans, penetration tests) materially improves the chances of a clean underwriting outcome.
How to assess cyber risk in third‑party payment providers
Underwriters assess both technical controls and business model exposure. For payment processors, several metrics and controls are particularly relevant:
- Transaction volume and concentration: total annual processed value (APV), average ticket size and proportion of revenue tied to a small number of large merchants. High concentration increases catastrophic loss potential.
- Card data handling model: whether the processor stores PANs, uses tokenisation or operates as a pass‑through. Full PAN storage attracts higher scrutiny and higher premiums.
- Authentication and SCA: implementation of Strong Customer Authentication under PSD2 for relevant flows.
- Network architecture and segmentation: separation of cardholder data environment (CDE) from admin and corporate networks.
- Encryption and HSM usage: hardware security modules for key management and end‑to‑end encryption reduce PCI exposure.
- Logging, monitoring and SIEM: evidence of 24/7 monitoring, retained logs and incident detection timelines.
- Change control and release management: frequency of releases, testing and rollback procedures.
- Third‑party vendor management: dependencies on cloud providers, sub‑processors and open‑source libraries.
Underwriter checklist (practical items to prepare during application)
- APV and transaction counts for the prior 12 months.
- Breakdown of top 10 merchants by revenue/volume.
- PCI DSS status: latest Attestation of Compliance (AOC) and ASV scan results.
- Incident history: summary of any cyber incidents in the past 5 years and remediation steps taken.
- Technical controls: tokenisation, HSMs, segmentation diagrams and encryption practices.
- Contracts and SLAs with merchants and banks, including indemnity and flow‑down clauses.
Incident flow for a payment processor
Payment processor incident flow
⚠️
Step 1 → Suspicious activity detected by SIEM
🔎
Step 2 → Forensic triage and containment
📣
Step 3 → Notify ICO, schemes and affected merchants
💳
Step 4 → Card‑scheme engagement & remediation
🛠️
Step 5 → Restore services and review controls
Common exclusions and business‑interruption claims for payment processors
Insurers commonly exclude or limit the following in relation to payment processors:
- Deliberate fraudulent acts or dishonest acts by executives are frequently excluded.
- Bodily injury or physical property damage is normally outside cyber policies (these require other liability covers).
- Contractual penalties where contractual liability is not insurable or where the insured assumed liability beyond statutory limits without insurer agreement.
- War, nation‑state acts or state‑sponsored cyber attacks may be excluded or sub‑limited; some insurers restrict cover for nation‑state activity.
- Fines and penalties: many policies cover defence costs but exclude direct payment of regulatory fines; some offer an optional endorsement for limited cover of fines where local law permits.
Business‑interruption claims for processors can be large because of downstream merchant impact. Key issues underwriters look for when insuring BI:
- Clear definition of interruption trigger: whether interruption must be due to physical damage, denial‑of‑service, or a cyber event. Policies vary and bespoke wording is common.
- Measurement of loss: many policies calculate BI based on fee/processing revenue rather than full merchant revenue; contingent BI to cover merchant loss requires careful negotiation.
- Waiting periods and mitigation obligations: insurers expect rapid mitigation and may require documented continuity plans.
Practical scenario: if a gateway outage prevents all merchant settlements for 24 hours, the insured loss may include lost processing fees, penalties under merchant contracts and putative claims by multiple merchants. Aggregation clauses (how multiple claims are treated as a single event) are critical and can materially affect limit exhaustion.
Choosing the right insurer for third‑party payment processors
When selecting insurers or brokers, processors should consider:
- Underwriting expertise in payments: prefer insurers with experience underwriting card‑processing exposures and who understand card scheme mechanics.
- Wording flexibility: ability to negotiate endorsements for PCI fines, contingent BI or card chargeback cover.
- Claims support and incident response network: availability of forensic teams, legal counsel and crisis communications partners experienced in payments incidents.
- Capacity and layering: insurers must provide sufficient aggregate limits for the processor’s exposure; for large exposures, a multi‑insurer placement may be required.
- Clear treatment of regulatory fines and class actions: understand how the insurer treats regulatory defence costs and whether any limit applies to class action defence.
Questions to ask a prospective insurer or broker
- How do you define an "event" for aggregation and multiple losses?
- Do you offer endorsements for PCI fines or card‑scheme penalties?
- What evidence of PCI/GDPR compliance do you require at proposal stage and before renewal?
- How are business‑interruption losses measured for payment services (fees v merchant revenue)?
- Can the policy include contingent BI for merchant losses caused by the processor's outage?
Strategic analysis: advantages, risks and errors to avoid
✅ Benefits and when to consider cyber insurance
- Protection against immediate cashflow shocks from incident response and remediation.
- Transfer of defence costs for regulatory and civil claims.
- Access to incident response partners provided by insurer panels.
- Improved merchant confidence when insurance is documented in SLAs.
⚠️ Common errors and risks to avoid
- Relying on generic SME cyber wordings without tailoring to payment‑specific exposures.
- Failing to disclose PCI non‑compliance or prior incidents during application (can lead to voided claims).
- Assuming fines and card‑scheme penalties are covered without explicit endorsement.
- Not modelling aggregated exposure from a single compromised merchant or credential set.
Practical checklist before applying for cover
- Prepare APV, merchant concentration and ticket size figures.
- Collate PCI DSS AOC, ASV scan reports and recent penetration test results.
- Document incident response plan, logging retention and SIEM configuration.
- Review merchant and bank contracts for indemnities and flow‑downs.
- Decide target limits and acceptable deductibles in light of potential aggregated loss.
Preguntas frecuentes
What does cyber insurance typically cover for payment gateways?
Policies often cover breach response, third‑party liability, business interruption and technology E&O. Cover varies by wording and endorsements; card scheme fines and GDPR fines may be restricted.
Can an insurer pay ICO fines directly in the UK?
Many insurers exclude direct payment of statutory fines or limit them. Often defence costs are covered but payment of fines may require a specific endorsement and will depend on local insurability rules. See ICO guidance.
How does PCI compliance affect premiums and cover?
Insurers expect evidence of PCI compliance; full PAN storage or major non‑compliance can increase premiums or result in exclusions. Tokenisation and HSM use typically reduce underwriting friction.
Will business interruption cover merchant revenue losses?
Standard BI for processors often covers lost processing fees. Contingent BI to reimburse merchant revenue is less common and usually requires bespoke wording and higher limits.
What should be disclosed when applying for cyber cover?
Material facts such as prior incidents, PCI status, vendor incidents, and concentration of merchants must be disclosed. Failure to disclose can invalidate cover.
Are ransomware losses covered for payment processors?
Ransomware cover depends on policy wording; some policies include ransom payment and recovery costs, others exclude or sub‑limit payments. Underwriters increasingly require proof of robust backups and recovery procedures.
How do underwriters treat aggregated exposure across multiple merchants?
Underwriters assess aggregation by event and concentration. High aggregation may need higher limits, sub‑limits or aggregate capacity across insurers.
Your next step:
- Compile core underwriting documents: APV figures, PCI AOC, ASV report and recent pen test summaries.
- Map top 10 merchant exposures and identify single‑point dependencies that could cause aggregation risk.
- Discuss policy wordings with a broker experienced in payment processor risk and request sample wordings for PCI fines, contingent BI and aggregation clauses.
