To help organizations prepare for the latest update to the Payment Card Industry Data Security Standard, referred to as PCI DSS v4.0, we put together key resources that help explain the changes and provide action steps to streamline the transition.

• What is PCI DSS?
  
  
• Beginner’s guide to PCI DSS compliance
  
  
• What is a PCI DSS Self-Assessment Questionnaire?
  
  
• Working toward compliance with PCI DSS v4.0

During our two webinars  — How to scope and streamline PCI DSS monitoring with Compliance Automation and A first-hand account of managing PCI DSS compliance — there were several questions about PCI security and tools to best achieve compliance. 

We posed these questions to expert auditors and security professionals. Read their answers and insights below. 

Questions about PCI DSS compliance

Does PCI DSS also apply to debit cards or payment cards? How about prepaid cards and children's accounts? 

Yes, PCI DSS protects sensitive cardholder data, which is present in debit cards and prepaid cards. For prepaid cards, like gift cards, there might not be any personal data associated with the card. However, the card number, expiration date, and card verification value (CVV) are still considered sensitive information because if the information is stolen, it can be used to make fraudulent transactions. 

In this context the merchant is the business that accepts payment from the cardholder using the prepaid card, and they are responsible for protecting the cardholder data they process as well as complying with PCI DSS.

What are the requirements for a level 1 service provider? Are they the same as a level 2 service provider, but with the addition of an audit?

The requirements for a level 1 service provider includes a Report on Compliance (ROC) by a Qualified Security Assessor (QSA), quarterly network scan by an Approved Scanning Vendor (ASV), and an Attestation of Compliance (AOC) form. 

A level 2 service provider requires a Self-Assessment Questionnaire (SAQ), quarterly network scan by an ASV, and an AOC form. 

Do service providers with more than 300,000 transactions a year still have to go through a ROC, ASV scan, and AOC? 

Yes, service providers with more than 300,000 transactions a year fall under the level 1 category, which requires an ROC by a QSA, a quarterly network scan by an ASV, and an AOC form. 

Is validating scope every six months only required for service providers?  

Yes. Under PCI DSS v4.0, service providers are required to validate their scope every six months. Additionally, any significant changes in their cardholder data environment should also prompt a documented internal review to check for any changes in scope. All other entities are required to validate their scope annually.

If you don't use the customized approach, can you pass PCI DSS v4.0’s enhanced requirements? 

The customized approach is optional. If you don't have the predefined control as stated in PCI DSS, the customized approach gives you flexibility to still meet the requirements. But if you already have what PCI DSS requires, then you can follow the defined approach. 

All of our payments are taken via Global Payments and we don’t store any cardholder data. Do we need to comply with PCI DSS or just ensure that Global Payments is?

In general, if the organization accepts credit cards, then it must be PCI DSS compliant, even if it is not handling the collection, processing, and storage of the protected cardholder data.  

But it does depend on the organization, so don't take this as a one-size-fits-all statement. You need to get confirmation from your vendor that they are PCI DSS compliant. Then, check if there's anything going through your channels. Even if you’re not storing data, you may need to be PCI compliant — it differs from scope to scope.

Does PCI DSS v4.0 change or clarify how the cardholder data environment (CDE) is defined?

The definition of CDE still remains the same, as being comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. However, there are several changes to the controls as well additional controls 

For example, it has expanded its scope of system components to include cloud components and now requires multi-factor authentication (MFA) implementation for all access into the CDE.  

What risk management framework do we have to use? Does PCI DSS offer its own risk management framework?

PCI DSS does not prescribe a specific risk management framework. Instead, it sets out security standards that organizations must meet to protect cardholder data. These standards involve managing the risks associated with storing, processing, and transmitting cardholder data. 

In terms of risk assessment, requirement 12.3 specifies that risks to the CDE are formally identified, evaluated, and managed.

For level 1 and 2 service providers, is the 300,000 transactions in aggregate or for one of the card brands?

Yes, this is an aggregate number performed annually by the service provider covering all brands except AMEX. 

For example, level 1 service providers store, process, or transmit more than 300,000 credit card transactions for Visa, Mastercard, and Discover or more than 2.5 million for AMEX annually. 

Is there any effort to standardize what the merchant levels are? For example, VISA and Mastercard classifies level 1 merchants as 6 million transactions, while Amex is 1 million.

Currently, there is no such communication on standardizing the transaction volume. The levels are determined by each individual payment brand separately.

Questions about Compliance Automation

Are there plans for adding CCRA/CCPA and NYDFS support?

We do have CCRA/CCPA and other state privacy regulations on our platform. We currently don’t have NYDFS at the moment, but we’re adding frameworks on a continual basis. We're also working on an asset to showcase all 31+ frameworks that we support today.

How can we compare against a unified compliance framework (UCF) that contains multiple compliance/controls to avoid evaluating the same risks/controls in OneTrust?

What tools or processes are available to expedite the assessment/compliance process?

Our Compliance Automation was built specifically for that purpose! Learn more about how Compliance Automation it can reduce your cost of compliance up to 60% and obtain certifications 50% faster.  

How often are the resources updated on the platform?

We update the resources as updates are made and provided by a specific standards body. Additionally, we review and update content based on feedback from customers, as well as updates provided by the specific standards body.

Do the control names in OneTrust Compliance Automation exactly match the control names as defined by the PCI SSC?

Not exactly, but the control number or the requirement number is the same. The reason for this is that while PCI DSS main requirements have names, the sub-requirements don't have names — just descriptions. 

Is there a place in OneTrust to store documents that support how you've defined your CDE (i.e., network diagrams, data flows) as part of your project definition?

These documents are also part of the evidence being stored within relevant controls. Additionally, the documents can be stored in our Security Assurance Portal (SAP) within Compliance Automation. These, and any other documents uploaded in SAP, can be shared with outside parties, as and when required.

Does your system provide a non-compliance notice with details of outstanding tasks?

There are multiple ways the system provides information on status:

• The Readiness Project View provides an overall status of the readiness projects in terms of the percentage of policies implemented, controls implemented, and evidences collected.
  
  
• The status of the evidence is also shown on the Compliance Calendar and Readiness Project Calendar views within each readiness project. These calendars provide information on the list of evidence, individuals responsible for collecting that evidence, and the status (i.e., collected, overdue, and upcoming).

How does OneTrust protect its sensitive customer data in the cloud? For example, some evidence might include key pieces of your customer's security practices used to protect their network and CHD.

All our customers’ data is stored in the AWS environment. We obtain and review their SOC 2 report on an annual basis. Additionally, we go through our own annual SOC 2 assessment covering Security, Availability, Confidentiality, and Processing Integrity Trust Service Criteria.

Could we have automated interfaces to collect evidence?

Yes, we have more than 130 integrations (and counting!) to automate evidence collection. Some examples of technology tools we have integrations with are AWS, ServiceNow, Okta, Jira, Microsoft Azure, Google Cloud Platform, CloudFlare, Zendesk, and Digital Ocean.

Learn more about how Compliance Automation helps you build, scale, and automate your security compliance program.