PCI DSS: A terminology and acronym minefield

- Information security - PCI DSS

28-02-2018


Paul Traill, Senior Information Security Consultant

Like many other subject areas that touch upon IT or cyber security, 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.

Here is an explanation of some of the acronyms and terms you are likely to see:

Reporting Requirements

The type of report you submit is based upon the number of annual transactions your business processes. It’s useful to have a conversation with your acquirer bank to confirm this, and if still unsure, contact a specialist cyber firm, like PGI, to validate reporting requirements.

AOC – Attestation of Compliance. This is a short (8-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 194-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 9—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 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.

PCI DSS

Entities

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

Merchant. An organisation that accepts 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. 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.

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 the Glossary document provided by the Security Standards Council here.

If you’re looking for a more simplified option, we can help you with your PCI DSS compliance. Just contact us to talk about your requirements: sales@pgitl.com or +44 (0) 845 600 4403

Ready to get started? Speak to one of our experts.

If you have any questions about our services or would like to learn more about our consultants here at PGI, please get in touch with us and speak with one of the team, call us on +44 (0)845 600 4403 or email us at sales@pgitl.com

Get in touch

Want to find out more?