PCI Compliance FAQ: Answers to Get You Started

As globally accredited PCI QSAs, we get a lot of questions regarding the many facets of PCI DSS, payment card security’s flagship standard.

In an attempt to empower organizations considering or currently undergoing compliance under these requirements, we’ve aggregated some of the queries we get most frequently. They are separated into these topics:

• General questions regarding the standard
• PCI DSS v4.0
• Does PCI apply to you?
• PCI scans
• Other technical PCI questions

General PCI Questions

Who are the ‘Participating Brands’?

The PCI “participating brands” are those credit-card networks that came together to support a consistent set of security controls for the handling of cardholder data. Currently, these brands include:

• American Express
• Discover
• JCB
• Mastercard
• UnionPay
• Visa

Where Can I Find Copies of the Current Standards & SAQs?

The PCI SSC’s website has a Document Library that includes all the security-related guidance and documentation needed for merchants, service providers, and assessors alike.

Beneath the search bar, filter by “SAQS” and select the one appropriate for your organization. Not sure which SAQ? There is a document in the Library titled “Understanding SAQs for PCI DSS” that can help.

Is PCI Compliance Mandated by Law?

No. There is no state or federal law mandating PCI. However, organizations seeking to process, or facilitate the processing of, credit cards from any of the participating brands will likely be required by their acquiring bank or customers to complete the appropriate assessment under the standard.

Assessments may also serve organizations who have been victims of a breach, as these validations can help document the actions taken since to prevent the exposure of data.

PCI DSS v4.0

When Can I Be Assessed Against PCI DSS v4.0?

Both merchants and services providers must use version 4.0 after March 31, 2024. It is optional to use version 4.0 now.

Do I Have to Use PCI DSS v4.0’s Customized Approach?

No. PCI DSS v4.0 introduced its customized approach as an option for organizations to meet the security objective of a requirement rather than directly meeting the text. However, every applicable requirement must still be met for compliance with the standard.

This concept is similar to a compensating control, which you may prefer. If you do, don’t worry—the control worksheet will remain as an option under PCI DSS v4.0.

Why Did the Council Reorganize the Requirement Numbers?

As payments, technologies, threats, and controls evolve, the PCI SSC adjusted the numbers to better organize requirements under security concepts.

We understand that might be frustrating, but our assessors know these revisions and additions. We can work with your organization even if your document references align with a previous iteration.

Is the Process for an Assessment Going to Change Fundamentally?

No. The general concept of an assessment and what is reviewed is largely identical to previous versions of the PCI DSS.

For more details on PCI DSS v4.0, make sure you read our articles on the different components:

• What Service Providers Should Know About PCI DSS v4.0
• How to Define Time in PCI DSS 4.0
• Decrypting Cryptographic Requirements in PCI DSS v4.0
• Factoring in Multi-Factor Authentication in PCI DSS v4.0
• How to Keep Legacy Systems Compliant Under PCI DSS v4.0
• Understanding the Updates to Risk Management in PCI DSS v4.0
• Scoping Out Scoping Requirements in PCI DSS v4.0

Does PCI Apply to You?

I Don’t Store Credit Card Information. Does PCI Apply To Me?

If the security of cardholder data can still be impacted, yes—the PCI DSS still applies to you. The good news is that the scope of your assessment will be commensurate with that impact. Here are some generalized examples of organizations that would still fall under PCI DSS:

• Service Providers That Manage Firewalls: You do not store, process, or transmit cardholder data but you have remote access to merchants or providers that do interact with cardholder data.
  • Your PCI DSS review would address remote access, authentication to these environments, hardening of networking devices, and how changes are tracked.
• Merchants Who Accept Cardholder Data Using an iFrame:
  • Because a compromise of the system or web page offering up the iFrame could result in a breach, your assessment would evaluate your removal of system defaults, patching, access controls, vendor management, and incident response.
• Software Developer That Creates/Develops Bespoke Payment Software for a Variety of Customers:
  • Your software development processes are still in scope because some of the software stores, processes, and/or transmits data. To satisfy the compliance concerns of customers, you can have your processes assessed against the specific requirements to develop and maintain software within the PCI DSS, which would result in an AOC.
  • Another option is to have those processes assessed under the Secure Software Life Cycle of the Secure Software Framework. That would also result in an AOC, but you would be listed on the PCI SSC’s website as well. 

Does PCI Apply to Call Centers?

Yes, call centers that store, process, transmit, or can impact the security of cardholder data are in-scope. Before you protest, consider these common scenarios where call centers are in-scope:

• Call center staff manually enter card data into a website maintained by their clients. Though those calls are not recorded, you would still fall in scope for that manual entry.
• Call center staff facilitate taking card data, but cardholders enter data using their phone keypad. Though card details are not recorded, the systems turning tones into card numbers are in-scope. (Your staff could be exempt.)
• Call center staff process payments using software maintained by the call center. Both the systems and staff performing entry are in-scope.

The particulars of call centers and compliance can be tricky, so please contact us with your specific questions.

PCI Scan Questions

How Should I Complete My Four Quarterly Scans?

You must complete your next scan less than 90 days after the previous one (PCI SSC FAQ 1087).

Though you may be wondering how that works with 365 days in a year, the best practice is to not go more than three months without completing a scan.

What If I Don’t Have Four Quarterly Scans?

If you’re undergoing your first assessment, you’re in luck – only one clean, current scan is needed.

But if you’re a veteran, four clean scans are needed for each 90-day or 3-month period for the prior year to be compliant. Speak with your QSA if there was a business or technical constraint preventing a scan from being completed within that time window or if there was a problem that comprised the entire environment.

What Is Meant by a ‘Clean’ Scan?

A vulnerability scan typically has some findings that organizations must address based on each finding’s severity and the risk ranking process.

If things go simply:

• A scan run on January 1 has 12 findings. 4 are critical, 3 are medium, and 5 are informational. Critical and medium vulnerabilities are corrected, and a re-scan run on January 15 comes back with the fixed issues as addressed and no additional findings. That re-scan is clean.

If things get more complicated:

• A scan run on January 1 has 12 findings. 4 are critical, 3 are medium, and 5 are informational. Critical and medium vulnerabilities are corrected, and a re-scan run on January 15 shows the fixed issues are addressed, it also reveals an additional critical and medium finding. This is still considered a clean scan because the initial findings were corrected. (The critical will still need to be patched within 30 days from the re-scan.)

Other Technical PCI Questions 

What is the “Merchant of Record?”

The merchant of record, or MOR, is the organization or entity which has the relationship with the acquiring bank and is liable for the security of payments processed between them.

What is a Critical Security Control Failure?

Critical security controls are the aggregate term for the software, services, and systems that protect the scoped environment. When any one of these ceases to provide protections, that’s considered a failure, and the potential impact on your organization can be severe.

Examples cited in the standard include:

• Firewalls
• IDS/IPS
• FIM
• Antivirus
• Physical access controls
• Logical access controls
• Audit logging systems
• Segmentation controls

To meet this requirement, you need to be able to identify if any of these controls stop working. If your answer to any of the following questions is “I don’t know” or similar, then you need another review:

1. If an individual control stops functioning, how would our team know?
2. If the services become deprecated (active but not fully functional), how would IT discern this?
3. You identified a failed service, do staff know how to identify and remediate the fault?

Does the SAQ Change if I Am Using a Direct Post Instead of a Redirect or iFrame?

Yes. There’s a big difference between how each handles data:

• With a direct post, card data is sent from the cardholder’s browser to the payment processor. The potential negative impact of the merchant website on this data is greater than an iFrame or redirect. This method would need to be assessed against the SAQ A-EP.
• Conversely, when a merchant site provides an iFrame or redirect, the exposure of cardholder data is less. As such, an SAQ A is appropriate.

As this is a simplified review, we do suggest reading our more detailed article on your SAQ options. You should also speak with your provider regarding additional implementation details and how your choices affect cardholder data.