PCI DSS: A terminology and acronym minefield

We’ve all been there; you’re talking to someone who throws an acronym at you that you’ve never heard before, or worse, you have heard it, but it means something totally different in the context of your conversation (or you’ve forgotten). You end up furiously searching online for it under the table and once you’ve found it, the conversation has moved on.

The Payment Card Industry is riddled with acronyms and potentially bewildering terminology. This can be overwhelming for someone without a technical or information security background, who needs to understand the basics in order to achieve PCI DSS compliance.

We’ve compiled a list of some of the acronyms and terms you are likely to see while undertaking your PCI DSS certification process, so you don’t get lost in the word salad:

Reporting Requirements

There are three different types of report, and the one you need will depend on the number of annual transactions your business processes. If you don’t know, you may need to have a conversation with your acquirer bank to find out. If you’re unsure what documents you need, then one of our cyber security experts will be able to tell you and validate your reporting requirements. The three reports are:

AOC – Attestation of Compliance. This is a short (11-page) sign-off document that accompanies a ROC or a SAQ report. Multiple versions exist depending upon the scenario and environment.

ROC – Report on Compliance. A 470-page report that describes the compliance status for a level 1 merchant or service provider. A Qualified Security Assessor must complete this.

SAQ – Self Assessment Questionnaire. An alternative to a ROC, which can apply to merchants or service providers. There are 10—widely differing—versions of the Questionnaire and the one you must complete will be defined by the scope of compliance and applicable payment channels (e.g. an e-commerce web site, a telephone-based transaction, or use of a chip and pin machine).

Card Data

The purpose of having the Payment Card Industry Data Security Standard (PCI DSS) is to ensure the security of card data and reduce the risk of a data breach occurring.

CHD – Cardholder data. This includes the PAN, the cardholder’s name, the expiration date, and a service code (e.g. properties of the card, such as allowed services like ‘ATM only’ or ‘No restrictions’).

PAN – Primary Account Number. The long number shown on the front of a card.

SAD – Sensitive Authentication Data. This includes full track data (magnetic stripe data or the equivalent on a chip), the CVV (short number, normally appearing on the back of the card), and PINs or PIN blocks.

Account Data – When this is referred to it also means cardholder data, and can include CHD and SAD.

[image: Explanation of PCI DSS Terms]

Entities

Understanding the stakeholders involved in payment transactions is an important part of being compliant.

Merchant. An organisation that accepts card payments, usually in exchange for goods or services.

Acquirer. The bank or other entity that a merchant has a contractual relationship with to process the merchant’s payments. For example, RBS, Lloyds, HSBC, Barclays, WorldPay.

Issuer. An entity that actually issues a card to the cardholder, and each time a purchase is made with the card, provides transaction authorisation to the merchant’s acquiring bank. This could be a payment brand directly (like American Express); or issued through another organisation that issues a card on behalf of Visa and Mastercard. For example, you may be issued with a credit card by supermarkets who operate financial services, such as Tesco and Sainsbury’s, or other high street companies like M&S.

Payment Processor or Payment Service Provider (PSP). Acquirers used to own their own acquiring technology platforms, but most have now outsourced this activity.

Payment Gateway Supplier. A more recent area is the provision of payment gateway services for online transactions. The gateway collects payment details from cards presented to the merchant for payment and passes these onto to the acquirer or payment scheme. For example, Sagepay and Paypal.

TPSP. Third-Party Service Provider. An entity that is directly involved in the processing, storage, or transmission of transaction or cardholder data on behalf of another merchant or service provider. For example, a hosted data centre provider, or a managed service that provides firewall management, or a Security Operations Centre.

PCI Data Security Standard Terms

CDE – Cardholder Data Environment. This is the scope for PCI DSS compliance. All components (people, processes, technology) that are involved in the storage, processing, or transmission of cardholder data. The scope also includes components that are directly connected to the CDE. For example, devices such as servers that provide security services like patching or anti-virus updates, as well as endpoint devices used by systems administrators to maintain in-scope systems.

Segmentation. Not a mandatory requirement for compliance, but strongly recommended as a method for reducing the scope of PCI DSS compliance. This is where judicious placement of firewalls can be used to segment the CDE from the rest of a network.

Tokenization. This is a process by which the primary account number is replaced with a surrogate value called a token. For example, it helps to reduce the amount of cardholder data stored in the merchant’s environment, whilst still providing a valid reference to a customer or card transaction.

Where to next?

This is just a taster of the terms used frequently in PCI DSS. For even more descriptions, take a look at Appendix G within the PCI DSS standard itself.

Contact us, if you’re looking for a more simplified option, we can help you with your PCI DSS compliance.

This was originally published on 28 February 2018 and updated on 16 January 2024.