Track Data
PCIComplianceHubLast updated
The data encoded in the tracks of a payment card magnetic stripe, or the equivalent data held on a chip. Track 1 carries the primary account number, cardholder name, expiration date, service code and discretionary data; Track 2 carries a shorter set without the name. Both include a card validation value, CVV1 or CAV1. Track data is Sensitive Authentication Data in full and must never be stored after authorization, in any system, including logs and diagnostic output.
Applies to. Requirement 3 applies the term to every entity that reads a card, at a terminal or through the chip, and to every system component that handles the read: the point-of-interaction device, the store controller, the payment switch, and any log or crash dump in between. The rule that full track data is not kept after authorisation binds merchants and service providers alike, and it does not matter whether the data came off the stripe or arrived as a stripe image from a chip.
Example. A parking operator's kiosks buffer transactions when the network drops and send them later. The buffer holds the whole Track 2 read until the batch is authorised, but the vendor's software never wipes the buffer file afterwards. Old track data builds up on every kiosk, and the operator only learns of it when a forensic investigator asks for the files after a breach.
Limits. Track data is not the PAN, even though the PAN is inside it. An entity may keep the PAN, expiration date, service code and cardholder name it parsed from a track, protected as Cardholder Data under Requirement 3; it may not keep the track as read. Chip cards do not make the term irrelevant, because the chip can return a stripe image that is track data in full. The term also does not cover the card verification code printed on the card or the PIN, which are separate elements of Sensitive Authentication Data with their own controls.