What Do I Need to Do to Comply with PCI?

Understanding what is (and what isn’t) considered payment card data is an important first step in understanding how to comply with PCI DSS. Generally, the regulation only applies to the Primary Account Number (PAN) of a payment card. If other data elements, such as the cardholder name, expiration date, and/or security code are present without any PAN, then PCI DSS doesn’t apply. However, if these other data elements are stored, processed, or transmitted with the PAN, or are otherwise present in the Cardholder Data Environment (CDE), they must be protected in accordance with applicable PCI DSS requirements, per the PCI Security Standards Council website. 

When PAN is being stored, PCI regulations require it be unreadable (PCI FAQ 1222) via encryption, truncation, tokenization, or one-way hashing. Whether or not the card is encrypted or tokenized, PCI requirements still apply to the system housing the number, since PAN could potentially be reversed if the encryption key or token lookup table is compromised. However, if the number is truncated (not masked) such that the system only stores a maximum of the first 6 digits or only last 4 digits of the PAN, the number is no longer considered to be PAN (PCI FAQ 1091) eliminating the need for that system to comply with PCI requirements. 

How does Zendesk help me meet PCI compliance?

Zendesk has a feature called the PCI Compliant Ticket Field. It allows you to put a Primary Account Number (PAN) into a custom ticket field in the Zendesk agent interface. This number is then redacted to the last 4 digits prior to the data being submitted to the user interface. This meets the payment card protection requirement for PCI compliance. Keep in mind that this PCI DSS compliant feature only applies to the Support product. To learn more about the security and privacy controls that Zendesk employs, including those that help support PCI compliance, see 'Is Zendesk PCI Compliant'. 

Request a copy of the Attestation of Compliance (AoC) (under ‘Artifacts’)

What if I don’t want end-users putting the full PAN into my Zendesk instance? 

While we strongly recommend only entering PAN via the PCI Compliant Ticket Field to ensure compliance with PCI standards, there are mitigations that you can implement to reduce exposure of this data should it be inputted outside of this dedicated field. 

Automatic Redaction

Zendesk has a feature called “automatic redaction”. Once you enable it in your Admin Center, you can use it to redact new payment card related data from the moment it’s turned on. This will allow the system to search for numbers between 12 and 16 characters long and redact them to the first 6 digits and the last 4 digits. Thereby mitigating the chances of sensitive data being overshared or misused. It also supports Messaging tickets. Please note, that automatic redaction doesn’t apply to the Help Center, Zendesk Chat nor other Zendesk products. 

Manual Redaction (with API Tools)

To use Data Loss Prevention (DLP) and API tools, you need to export your Zendesk ticket data to a secure location. To learn how to do this see the Export ticket data via CSV or XML document. Then you can use the Incremental API to pull tickets from a specific range of dates or the Listing Comments API to pull ticket comments from tickets. Once the necessary payment card data is isolated, you can apply one of the many open source tools available to identify sensitive data such as PAN. With the Redaction API, you can remove this information from the ticket comments. 

Usage and storage controls

You can also minimize the exposure of sensitive account holder data by only storing payment card data when absolutely necessary and as part of a legitimate business need. Sharing unprotected PAN via email, instant message, chat or other communique should also be avoided to stay in compliance with PCI DSS. 

Likewise, PAN should always be unreadable when it is being stored including in backup locations, logs and portable devices. One-way hashed cryptography, truncation that shows only the last four digits of a PIN and similar storage control methods of encryption, masking and/or truncation may also be used. 

As a general security best practice, you should also train employees to recognize and report any non-compliant exposure, usage or distribution of payment card data within your system or day-to-day operations. 

How do I determine if an application or system is in-scope for PCI compliance?

Does the system store, transmit, or process payment card data? If so, it’s in-scope for PCI. Each company is responsible for identifying the systems within their environment where PCI DSS requirements apply. When doing this assessment, it’s important to remember that PCI not only requires all baseline systems that store, transmit, or process payment card data to be in-scope for PCI, but also any systems directly connected to those baseline systems. Scoping can be explored using the following steps:

1. First, recognize and document all known data flows and systems that are expected to transmit, process, and/or store payment card data. These systems make up your baseline CDE.
2. Second, document all directly connected system components to the baseline environment. These systems are also considered part of your CDE.
3. Third, explore systems outside the CDE that you have reason to believe may be transmitting, processing, and/or storing payment card data. Document any that you find and trace their path back to the CDE. Some of the most common examples may include email systems, help desks, HR repositories, financial reporting systems, company spreadsheets, etc.

Note: Storage exceptions include MIME encoded emails and custom ticket fields in suspended tickets, but we anticipate soon releasing functionality to remove these two exceptions.

How can I make PCI DSS compliance more manageable?  

To make PCI DSS compliance more manageable, you need to reduce your overall PCI scope. Review your CDE and scrutinize any interface that transmits, processes, or stores payment card data. Adhere to data protection best practices that require you to only acquire and consume sensitive data that are critical to your operations. Ask yourself the following:

• Do our business processes require the use of a payment card? How are we using the PAN?
• Are we storing the full PAN as a reference number, or is it used to support other business processes (e.g. auto-billing or chargebacks)? If we are using the full PAN as a reference number, can we limit the use and storage by truncating it?
• Do we have control over whether or not a card number enters a particular system? For example, is the system associated with a web form, email, helpdesk, or some other client-facing interface? If so, can we develop a way to remove or redact the data as it enters the system?
• Are there ancillary systems that connect to the CDE that we don’t really need? Can we segment those systems through firewall rules or even remove the interfaces altogether?
• Are our critical business processes architecturally sound? Can we simplify some of our processes and remove systems from PCI scope?
• Are we storing payment card data for the sake of convenience? Is the storage use case clearly agreed to and understood by internal stakeholders, or is it being stored in preparation for some future need that may or may not present itself?
• Is access to the full PAN an edge case or common practice? Does our architecture over-accommodate these edge cases?

Reducing your PCI scope has the benefit of reducing the number of systems where PCI requirements apply, lessening the cost of the audit process, and limiting the number of attack surfaces in your environment. Depending on your experience, resources, and the amount of time you have available, it may make sense to engage a PCI expert to help guide you through your scoping efforts.

Legal notice

Zendesk maintains a Payment Card Industry Attestation of Compliance (“AoC”) for subscribers using the Credit Card Field for the Zendesk Help Desk and Help Center services only and does not include any other services or products offered by Zendesk. The AoC demonstrates Zendesk's compliance with the Payment Card Industry Data Security Standard ("PCI DSS") version 3.1, as formulated by the Payment Card Industry Security Standards Council. Zendesk subscribers who are on the Enterprise Subscription Plan can benefit from Zendesk's AoC by following the processes set forth in this article.  Upon following the procedures set forth in this article, it may take up to 5 business days for your Zendesk account to be moved into a Zendesk PCI-compliant environment.

This article should not be used as a substitute for obtaining advice from a professional licensed or authorized to practice in your jurisdiction. You should always consult a suitably qualified professional regarding any specific legal or compliance issue. Nothing in this article is intended to constitute legal advice.

Glossary of Terms

Acquirer – Also referred to as “merchant bank,” “acquiring bank,” or “acquiring financial institution.” Entity that initiates and maintains relationships with merchants for the acceptance of payment cards. The acquirer is typically responsible for monitoring PCI compliance with their merchants’ account.

AoC – Acronym for Attestation of Compliance. This is the audit report that shows if and how an organization is PCI compliant.

Cardholder data – At a minimum, cardholder data consists of the full Primary Account Number (PAN). Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code.

CDE – Cardholder Data Environment.The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.

DLP – Data Loss Prevention. Data loss prevention software is designed to detect potential data breach or data loss events.

Encryption – Process of converting information into an unintelligible form except to holders of a specific cryptographic key. Use of encryption protects information between the encryption process and the decryption process (the inverse of encryption) against unauthorized disclosure.

Luhn check – Also known as the “Mod 10” algorithm, it is a simple checksum formula used to validate a variety of identification numbers, such as credit card numbers. Most credit cards use the algorithm as a simple method of distinguishing valid numbers from mistyped or otherwise incorrect numbers.

Masking – A method of concealing a segment of data when displayed or printed. Masking is used when there is no business requirement to view the entire PAN. Masking relates to protection of PAN when displayed or printed.

PCI Compliant Ticket Field – This field is designed to accept credit card numbers from agents, where it will automatically redact the credit card number to the last 4 digits prior to the data being submitted to the Zendesk platform. This field is required to be enabled to benefit from Zendesk’s AoC.

PCI-SSC – Acronym for Payment Card Industry Security Standards Council. This council was established in 2006 by the five credit card brands (Visa, MasterCard, American Express, Discover, JCB).

PCI-DSS – The Payment Card Industry Data Security Standard. The PCI SSC created a unified standard by which all merchants and service providers would be subject.

PAN – Primary Account Number. Also referred to as “account number.” Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder.

Service provider – Business entity (not a payment card issuer) that is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS, and other services as well as hosting providers and other entities.

QSA – Qualified Security Assessor. The PCI SSC has certified firms to perform PCI assessments and to assist with PCI validation; the designation is a QSA firm, or similarly an individual at a QSA firm can be certified as an individual QSA.

Redact – The process of removing sensitive information, such as PAN, where it is not needed.

SAQ – Self Assessment Questionnaire. An entity validating PCI compliance will either undergo an external assessment by a QSA, or complete an SAQ and submit it to the card brands or their merchant bank.

Tokenize – The process of breaking a stream of meaningful text, such as credit card number, into data elements called tokens that represent the actual data, but alone are meaningless. Tokenization is a method to remove credit card data from systems or databases, thereby reducing the scope of the CDE.

Truncation – Method of rendering the full PAN unreadable by permanently removing a segment of PAN data. Truncation relates to protection of PAN when stored in files, databases, etc.