Skip to main content
Commerce Security Authority
Category: Incident Response and Skimming

Account Data Compromise

Also known as: ADC, ADC event, account data compromise event
Simply put

An Account Data Compromise (ADC) is an incident in which an unauthorised person gains access to card payment data within a business's environment, typically with the intent to misuse it. Card networks treat such incidents as ADC events, which can trigger investigation, notification, and response obligations. Because an ADC involves compromised payment data, it may carry costs beyond those of a general data breach.

Formal definition

An Account Data Compromise (ADC) is an event in which account data held or processed in a merchant, issuer, or acquirer environment is accessed by an unauthorised party, generally with intent to exploit that data. Card networks such as Mastercard define and manage ADC events through published rules and alert processes, with obligations that vary by the date the first ADC Alert is published and by the parties involved. An ADC event follows a lifecycle spanning pre-breach, during-breach, and post-breach activities, and issuers and acquirers are expected to understand this lifecycle and maintain incident response capabilities. Note that the specific ADC rules, alert procedures, and financial responsibilities are governed by individual card brand and network programs and differ by region and version; readers should confirm current requirements against the applicable network's published ADC documentation.

Why it matters

An Account Data Compromise is treated by card networks as a distinct category of incident, not simply a general data breach. Because an ADC involves card payment data specifically, it can carry costs and obligations beyond those of an ordinary data breach, including network-driven investigation, notification, and response requirements. General breach cost figures circulate widely, but these represent broad data-breach studies rather than ADC-specific measurements; exact ADC costs depend on the incident, the parties involved, the card brand programs that apply, and the region, and should not be assumed from general breach statistics.

For merchants, issuers, and acquirers, the practical significance of an ADC is that it can trigger formal obligations under a card network's published ADC rules and alert processes. These obligations vary by the date the first ADC Alert is published and by the parties involved, which means the timing and content of an ADC Alert can directly shape what a business must do and what financial responsibility it may bear. Confirming current requirements against the applicable network's published ADC documentation is essential, because the specific rules, alert procedures, and financial responsibilities differ by card brand, region, and version.

Because an ADC event follows a lifecycle spanning pre-breach, during-breach, and post-breach activities, the value of preparation is high. Organisations that understand this lifecycle and maintain incident response capabilities are better positioned to meet notification timelines and network obligations if an ADC occurs. Treating an ADC as a payment-security incident with its own governance, rather than folding it into generic breach handling, helps ensure the correct network processes are followed.

Who it's relevant to

Merchants
Because an ADC happens when an unauthorised person accesses card payment data in a merchant's business environment, merchants are directly exposed to ADC obligations and their associated costs, which may exceed those of a general data breach. Merchants benefit from understanding the ADC lifecycle and preparing incident response processes before an event occurs.
Acquirers
Acquirers are named parties in network ADC programs and are expected to understand the pre-, during-, and post-breach lifecycle of an ADC event and to maintain incident response capabilities. The obligations and financial responsibilities that apply can vary by the date the first ADC Alert is published and by the parties involved, so acquirers should confirm current requirements against the applicable network's published documentation.
Issuers
Issuers are likewise expected to understand the ADC lifecycle and maintain incident response capabilities. Their obligations under an ADC event are governed by individual card brand and network programs that differ by region and version, making familiarity with current network ADC documentation important.
Incident response and payment security teams
Teams responsible for incident response need to treat an ADC as a distinct payment-security incident rather than a generic data breach, aligning their response to the network's ADC alert processes and lifecycle stages. Maintaining a tested response plan helps organisations meet notification and response obligations if an ADC occurs.

Inside ADC

Compromised Cardholder Data
An ADC event may involve exposure of cardholder data such as the primary account number (PAN), cardholder name, expiration date, or service code. Under PCI DSS, certain cardholder data may be stored subject to defined protection controls, so its presence in a compromise reflects how that data was secured at rest and in transit.
Compromised Sensitive Authentication Data
An ADC may also involve sensitive authentication data, including full track (magnetic-stripe) data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks. This data must not be retained after authorization, even in encrypted form, so its exposure often points to prohibited storage or interception during processing.
Point of Compromise
The location or system where account data was exposed, which can span merchant environments, service providers, payment applications, e-commerce pages, or network components. Identifying the point of compromise is central to scoping the incident and containing further exposure.
Attack Vector and Method
The mechanism by which account data was accessed, such as malware on payment systems, e-commerce skimming, physical device tampering, credential misuse, or interception of unencrypted data. The applicable safeguards differ between card-present and card-not-present environments.
Card Brand and Network Involvement
ADC handling is subject to individual card brand and network programs, which define notification, forensic investigation, and account-monitoring obligations. These requirements are set by the brands and networks and vary by region and program.
Forensic Investigation Scope
A defined process, often involving a qualified forensic investigator under card brand programs, to determine what data was exposed, the time window involved, and whether prohibited storage of sensitive authentication data occurred. Findings inform remediation and validation of affected controls.

Common questions

Answers to the questions practitioners most commonly ask about ADC.

Is an Account Data Compromise only a concern if stored PAN is exposed?
No. An account data compromise can involve either cardholder data or sensitive authentication data, and the two categories are distinct. Cardholder data includes the PAN, cardholder name, expiration date, and service code, and some of it may be stored under defined controls. Sensitive authentication data includes full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, and it must not be retained after authorization even when encrypted. A compromise that captures sensitive authentication data in transit or in memory during processing can be significant even if no PAN was persistently stored, so scoping an ADC investigation to stored PAN alone can understate the exposure.
Does achieving PCI DSS compliance mean an entity cannot suffer an Account Data Compromise?
No. PCI DSS is intended to help reduce the likelihood and impact of account data compromise, but validated compliance at a point in time does not guarantee that a compromise cannot occur. Controls can drift out of place between assessments, attackers may target data in transit or in memory, and an entity's environment may change after validation. Compliance and the ability to suffer an ADC are not mutually exclusive, and card brand and network rules govern how a suspected compromise is investigated and handled regardless of an entity's compliance status.
What data should we prioritize identifying when scoping the affected environment after a suspected ADC?
Distinguish cardholder data from sensitive authentication data across the environment, because they carry different retention rules and different implications. Identify where PAN, cardholder name, expiration date, and service code may exist, and separately identify any point where full track data, CAV2/CVC2/CVV2/CID, or PIN blocks could have been present in memory, in transit, or improperly retained after authorization. Note that data-reduction techniques such as tokenization, encryption, truncation, masking, and hashing transform data differently, so their effect on what was exposed depends on how each was implemented and validated rather than on the label alone.
How do we determine which reporting and forensic obligations apply after a suspected compromise?
The applicable notification, forensic investigation, and evidence-handling obligations are governed by card brand and network rules, which vary by region and change over time. Rather than assuming a fixed process, confirm the current requirements published by the relevant brands and your acquirer, because timelines, the use of an approved forensic investigator, and reporting thresholds can differ. Treat the specific procedural steps as dependent on the current published rules for your region and relationships.
Which PCI DSS requirements are relevant to preventing and detecting an ADC?
Multiple areas of PCI DSS are relevant, including protecting stored cardholder data, not retaining sensitive authentication data after authorization, protecting data in transit, restricting access, and logging and monitoring to support detection. Requirement numbering and wording differ between PCI DSS versions, so confirm the exact requirements against the current published standard rather than relying on a fixed number. Note also that some controls readers may associate with an ADC belong to separate standards, such as PCI PIN for PIN handling or PCI P2PE for validated point-to-point encryption.
Can strong authentication controls like EMV or 3-D Secure eliminate the risk that leads to an ADC?
No single authentication control eliminates the risk. EMV chip authentication, 3-D Secure, strong customer authentication, and multi-factor authentication address different risks at different points in a transaction, and they are intended to reduce specific categories of fraud rather than guarantee protection of account data. An account data compromise concerns the exposure of cardholder data or sensitive authentication data, which can occur through channels these controls do not cover, so they should be treated as complementary layers rather than as a substitute for data protection and monitoring.

Common misconceptions

If the compromised account data was encrypted, the organization is automatically not liable and the event is not reportable.
Encryption may reduce exposure, but its effect depends on implementation and key management, not on the label alone. Notification and investigation obligations are governed by card brand and network programs, and sensitive authentication data must not be stored after authorization even when encrypted, so encryption does not by itself remove reporting responsibilities.
Being PCI DSS compliant means an account data compromise cannot happen.
PCI DSS is intended to help reduce risk, but validation reflects a point in time and a defined scope. No single standard or control eliminates the possibility of compromise, and an ADC investigation may reveal gaps between an attested state and the environment at the time of the event.
All account data compromises involve the same type of data and the same response.
Compromises differ by whether cardholder data, sensitive authentication data, or both were exposed, and by whether the environment was card-present or card-not-present. These distinctions change the applicable controls, the severity, and the specific card brand and network obligations that apply.

Best practices

Confirm before any incident whether sensitive authentication data is being stored after authorization, since such storage is prohibited under PCI DSS and is a common and severe finding during ADC investigations.
Maintain an incident response plan that defines how to identify the point of compromise, contain exposure, and preserve evidence for forensic investigation, and confirm its requirements against the current published standard rather than a fixed requirement number.
Understand and document the notification and forensic obligations of each relevant card brand and network program, recognizing that these vary by region and change over time.
Minimize stored cardholder data and apply appropriate controls such as tokenization, truncation, masking, or encryption where suitable, validating their scope-reduction effect through implementation review rather than assuming it from the label.
Segment and monitor payment environments so that a compromise in one system is less likely to expose account data across the broader environment, and so the point of compromise can be scoped more quickly.
After an ADC, remediate the specific gaps identified in the forensic findings and revalidate the affected controls, rather than relying on a prior point-in-time attestation.