One of the critical tasks in PCI DSS compliance is scope identification (scope) compliance. The first step in determining which assets are within or outside that scope is the identification of the type of data of payment cards that are processed, stored and/or transmitted by the entity and the format of such data. Depending on this, the entity may determine the associated infrastructure (servers, applications, NSCs, databases, wireless networks, virtualization systems, etc.), locations, personnel, and third parties that will be part of its compliance environment.
The PCI DSS standard applies to all entities that store, process or transmit cardholder data (Cardholder Data – CHD) and/or sensitive authentication data (Sensitive Authentication Data – SAD) – jointly referred to as ‘account data’ (Account Data) – or that could affect the security of cardholder data and/or sensitive authentication data.
Account Data in PCI DSS
Likewise, the PCI DSS standard establishes the controls that must be applied during the storage of this data, taking into account that if the PAN is stored together with other elements of the holder's data (CHD), then only the PAN must be unreadable.
Controls for card data storage
However, depending on what type of security controls are applied to the data and the format used, the scope (scope) compliance can be extended or minimized. That is why it is imperative to understand how applicability criteria are established based on data types and their data formats BEFORE proceeding with scope identification (req. 12.5.2 of PCI DSS v4.x):
PCI DSS requirement 12.5.2 related to scope of compliance documentation
Listed below are the types of data and other related assets that may or may not be in scope depending on their format and functionality. However, it is clarified that the applicability of these criteria may vary depending on the responsibilities and access permissions of the entities and/or systems involved:
| Data type | When are they INSIDE of scope? | When are they OUTSIDE of scope? | References |
|---|---|---|---|
| Account data (CHD and SAD) in clear text | Clear text card data can be temporarily stored in non-persistent memory (RAM memory, for example) while being processed. However, the systems that process this data will be within reach. | N/A | FAQ #1042: Should cardholder data be encrypted while in memory? |
| Encrypted NAP data | Encrypted PAN data will remain within the scope of PCI DSS:
Similarly, systems that execute encryption and data decryption routines, systems that perform key management tasks, and any connected system or network should be within reach. | Encrypted PAN data can be considered out of reach when the entity receives and/or stores encrypted data only, does not have access to clear data or related cryptographic keys, nor does it have the ability to decrypt them. | Section 4 of the PCI DSS standard: Scope of PCI DSS Requirements FAQ #1086: How does encrypted cardholder data impact PCI DSS scope? |
| Hash cryptographic with key (keyed cryptographic hashing) | Full PAN data protected with hash Keyed cryptographic will be in range if this data is stored on the same system that runs the hashing. Similarly, systems that run routines of hashing data, systems performing key management tasks and any connected system or network shall be within range. | PAN data protected with hash cryptographic with key may be considered out of reach where such data:
| FAQ #1089: How can hashing be used to protect Primary Account Numbers (PAN) and in what circumstances can hashed PANs be considered out of scope for PCI DSS? |
| Tokenized PAN data (acquisition tokens) | When purchasing tokens are used, different methods can be used for their generation. However, PAN tokens will be in range if they are stored on the same system that runs the tokenization. Similarly, systems that run data tokenization routines, systems that perform key management tasks (if applicable), and any connected systems or networks should be within reach. | PAN data protected by tokenization may be considered out of reach where such data:
| FAQ #1384: What is the difference between ‘acquiring tokens’, ‘issuer tokens’, and ‘Payment Tokens’? FAQ #1385: Which types of tokens are addressed by the PCI SSC tokenization documents? |
| Truncated PAN data (truncated) | When truncation of the NAP (removal of a certain number of digits) is used for storage following the criteria laid down by the trade marks, the systems executing the truncation as well as any connected system or network shall be within range. | PAN data protected by truncation during storage may be considered out of reach where such data:
| FAQ #1117: Are truncated Primary Account Numbers (PAN) required to be protected in accordance with PCI DSS? FAQ #1091: What are acceptable approved for truncation of primary account numbers? |
| Masked PAN data (masked) | When masking is used (masking) in order to protect the NAP during its display on screens, receipts, printouts, etc., the systems performing the masking, as well as any connected system or network, shall be within range. | PAN data protected with masking during display they can be considered out of reach when the display of the original PAN is not allowed in any way (e.g. on paper receipts). | FAQ #1146: What is the difference between masking and truncation? |
Once the entity has made the identification of its scope, it is recommended to involve a QSA Advisor for evaluation.
Leave us a message if you have any questions about this article.
EN 
ES