How a Data Breach Works
A data breach in the payments context follows a predictable attack lifecycle — from initial reconnaissance through exfiltration. Understanding each stage helps merchants and developers build controls at the right points in their stack. Most payment breaches are not the result of sophisticated zero-day exploits; they exploit known vulnerabilities that were never patched or misconfigurations that left sensitive data exposed.
Reconnaissance
Attackers identify targets by scanning for known vulnerabilities, reviewing public job postings that reveal technology stacks, or purchasing access to breached credential lists. E-commerce merchants running outdated CMS versions or unpatched payment plugins are commonly identified through automated scanning tools.
Initial Access
The attacker gains entry via SQL injection, phishing credentials, brute-forcing admin panels, or exploiting a vulnerable third-party plugin. In Magecart attacks, a single compromised CDN or analytics script is injected across thousands of merchant checkouts simultaneously.
Lateral Movement and Privilege Escalation
Once inside, attackers move toward the cardholder data environment (CDE). They escalate privileges, disable logging, and map internal systems. Dwell time — the period between initial access and detection — averages 204 days globally, giving attackers ample time to establish persistence.
Data Exfiltration
Cardholder data, credentials, or personal records are copied out of the environment. Attackers may exfiltrate in small batches over weeks to avoid triggering volume-based alerts. In e-commerce skimming, card data is captured in real time as customers type and sent to attacker-controlled servers.
Discovery and Containment
Breaches are most commonly discovered by third parties — card schemes, banks, or security researchers — rather than the merchant itself. Upon discovery, the merchant must immediately isolate affected systems, preserve forensic evidence, notify their acquirer, and engage a PFI if required by card schemes.
Regulatory and Scheme Response
Post-containment, the merchant faces parallel processes: regulatory reporting under GDPR or applicable data protection law, card brand forensic investigation, potential fines, mandatory card reissuance fees, and a remediation plan to restore PCI compliance before card acceptance rights are reinstated.
Why Data Breach Matters
Data breaches are among the most consequential events a payment-accepting business can face — financially, operationally, and reputationally. The costs are rarely limited to fines; they cascade across the entire payment stack. For smaller merchants, a major breach can be business-ending.
The scale of the problem is significant. According to the IBM Cost of a Data Breach Report 2023, the global average total cost of a data breach reached $4.45 million — a 15% increase over three years. In the financial services sector, average costs exceeded $5.9 million per incident. Verizon's 2023 Data Breach Investigations Report found that 83% of breaches involved external actors, with financial motivation driving the overwhelming majority of attacks against payment environments.
Card scheme consequences add a separate financial layer. Visa and Mastercard impose fines on acquiring banks — which are passed to merchants — ranging from $5,000 to $100,000 per month during periods of non-compliance following a breach. Card reissuance fees, charged at approximately $3–$10 per compromised card, can run into millions of dollars for large-scale incidents. These costs are independent of regulatory fines and civil liability.
Dwell Time Is the Hidden Risk
The average time between initial compromise and detection is over 200 days (IBM, 2023). Every day an attacker remains inside a cardholder data environment, more card data is at risk. Continuous monitoring and anomaly detection — not periodic audits — are the primary defense against extended dwell time.
Data Breach vs. Data Leak
These terms are often used interchangeably but describe meaningfully different incidents with different causes and responses.
| Dimension | Data Breach | Data Leak |
|---|---|---|
| Cause | Deliberate unauthorized access by an attacker | Accidental or negligent exposure — misconfigured storage, sent to wrong recipient |
| Actor | External attacker or malicious insider | Usually internal error or misconfiguration |
| Intent | Typically malicious — data theft, fraud | Unintentional in most cases |
| Common example | SQL injection stealing card numbers | S3 bucket with PAN data left publicly accessible |
| PCI DSS treatment | Triggers full incident response and PFI | May trigger mandatory reporting depending on exposure duration and data type |
| Regulatory notification | Required under GDPR, card scheme rules | Required under GDPR if personal data is affected, even without malicious intent |
| Remediation | Forensic investigation, patch, retest | Immediate closure, access log review, impact assessment |
In practice, data leaks are frequently exploited by attackers who discover exposed data before the merchant does — effectively converting an accidental leak into a breach. Misconfigured cloud storage containing cardholder data should be treated with the same urgency as an active intrusion.
Types of Data Breach
Not all payment data breaches look the same. Understanding the attack type determines both the technical response and the scope of affected data.
E-commerce Skimming (Magecart): Malicious JavaScript injected into checkout pages captures card data as customers type. The merchant's server may be completely clean — the compromise lives in a third-party script or CDN. Particularly dangerous because it is invisible to standard server-side security tools.
Network Intrusion: Attackers gain access to internal systems via phishing, credential theft, or vulnerability exploitation, then navigate to the cardholder data environment. Classic PCI DSS breach vector.
Physical Skimming: Overlay devices placed on card terminals or ATMs capture magnetic stripe data and PINs. Primarily affects brick-and-mortar merchants; largely mitigated by EMV chip adoption but still active in high-traffic environments.
Insider Threat: An employee with legitimate access to payment systems copies or sells cardholder data. Accounts for a meaningful minority of breaches and is notoriously difficult to detect with perimeter controls alone.
Third-Party / Supply Chain Breach: A vendor, plugin, or SaaS tool with access to the cardholder data environment is compromised. The merchant's own systems remain secure, but data flows through the compromised third party. Encryption of data in transit and strict vendor access controls are the primary mitigations.
Credential Stuffing: Automated use of username/password combinations from previous breaches to access merchant portals, payment dashboards, or customer accounts. Enabled by password reuse across services.
Best Practices
Preventing and containing data breaches requires different priorities depending on whether you're operating a merchant's payment infrastructure or building the underlying systems.
For Merchants
Maintain current PCI DSS compliance — not as a checkbox exercise but as a live security posture. Scope reduction is your most powerful tool: if your systems never touch raw cardholder data, your breach risk and compliance burden drop dramatically. Use a PCI-compliant hosted payment page or payment orchestration layer so card data never touches your servers.
Audit third-party scripts on your checkout pages quarterly. Every analytics tag, chatbot, and A/B testing tool loaded on your checkout is a potential Magecart vector. Implement a Content Security Policy (CSP) to restrict which scripts can execute on payment pages. Enable real-time transaction monitoring and establish a documented incident response plan before you need it — not after.
For Developers
Implement tokenization at the earliest possible point in the payment flow. Never log PANs, CVVs, or full card numbers — even in debug mode. Use parameterized queries exclusively to eliminate SQL injection risk. Enforce least-privilege access to any system touching cardholder data: developers should not have production database access by default.
Integrate dependency scanning into your CI/CD pipeline to catch vulnerable payment libraries before deployment. Apply ISO 27001-aligned secure development practices: threat modeling at design time, mandatory security review for changes touching the CDE, and penetration testing before major releases. Encrypt all cardholder data at rest using AES-256 and ensure TLS 1.2+ is enforced on all data-in-transit paths.
Common Mistakes
Treating PCI compliance as a substitute for security. PCI DSS compliance is a minimum baseline assessed at a point in time. Attackers operate continuously. Merchants who pass their annual assessment and then make no further security investments are frequently breached in the months between assessments.
Underestimating third-party script risk. Most Magecart-style breaches occur through compromised third-party JavaScript, not the merchant's own code. Failing to audit external scripts loaded on checkout pages — or failing to implement CSP — leaves a wide-open attack surface that internal security tools cannot see.
Delaying breach notification. Merchants sometimes delay notifying their acquirer or regulator while conducting internal investigations. This is almost always the wrong call. GDPR's 72-hour clock begins when you become aware of the breach, not when the investigation concludes. Late notification consistently results in higher regulatory fines and more aggressive card scheme penalties.
Incomplete scope of affected data. Post-breach investigations frequently reveal that data exposure was broader than initially believed — earlier transaction logs, backup files, or development databases containing production data. Assuming a narrow blast radius without forensic confirmation leads to inadequate notification and card reissuance, which compounds scheme fines.
No tested incident response plan. Having a written incident response plan is not enough. Plans that have never been rehearsed fail under the time pressure of a real breach. Tabletop exercises simulating a breach scenario — including acquirer notification, forensic engagement, and regulatory reporting — should be conducted at least annually.
Data Breach and Tagada
Tagada is a payment orchestration platform that sits between merchants and their acquiring banks, processors, and payment methods. This architectural position has direct implications for data breach risk.
Scope Reduction Through Orchestration
By routing payment flows through Tagada's orchestration layer — which handles tokenization, routing logic, and processor communication — merchants can eliminate their own cardholder data environment entirely. No CDE means dramatically reduced PCI scope, fewer assets to defend, and a smaller blast radius if any part of the merchant's infrastructure is compromised. Tagada's integrations use tokenized references rather than raw PANs, meaning a breach of a merchant's order management system exposes no usable card data.
When evaluating a payment orchestration provider from a breach-risk perspective, confirm their PCI DSS Level 1 certification, review their sub-processor list and data retention policies, and ensure their API responses never return raw PANs or CVVs. Orchestration platforms that handle fraud detection signals should also document how behavioral and transactional data is stored and protected, as this data can be sensitive even without containing explicit card numbers.