Comprehensive PCI Compliance Checklist 2021 (With Expected Updates for PCI DSS v4.0)

With so much reliance on digital payment processing, a standardized set of rules, guidelines, and policies for securing data is critical. Established by the Payment Card Industry (PCI), the Data Security Standard (DSS) provides a clear path to compliance—if you can keep up with the regular revisions and modifications. Thankfully, our comprehensive PCI Compliance Checklist 2021 contains all the updated information you’ll need.

Is PCI DSS Compliance Required?

Since the PCI DSS applies to any company that stores, processes, or otherwise uses credit card payments or cardholder data, compliance is mandatory for all retailers—and many other industries—in the U.S. Given its importance, any changes or modifications made to the PCI DSS need to be implemented in a timely manner. Failure to do so could result in severe fines.

Our PCI compliance requirements checklist provides a complete guide for meeting and maintaining these standards through the upcoming v4.0 transition.

What is your PCI level?
What documents are required?
How can your organization transition to PCI DSS v4.0?
What changes are expected in PCI DSS v4.0?

Your Comprehensive PCI Compliance Checklist 2021: Getting Started

The PCI DSS contains many different rules, regulations, and policies that must be observed by any organization that handles credit card payments. But with so many different rules—some of which only apply in certain cases—it can be difficult to determine which standards apply to your organization. That’s why it’s best to start your PCI requirements checklist by determining your PCI level.

PCI DSS Levels

The first step in achieving PCI compliance requires determining your exact PCI level. This establishes your general compliance requirements for the PCI DSS. Current PCI levels are (generally) as follows:

Level 1 – Those with more than six million annual Visa transactions must file a Report on Compliance (ROC) and Attestation of Compliance (AOC), which are filled out by a Qualified Security Assessor (QSA).
Level 2 – Those with one to six million annual Visa transactions must file a SAQ and an AOC.
Level 3 – Those with 20,000 to one million annual Visa transactions in the e-commerce space must file an AOC and a SAQ.
Level 4 – Those with less than 20,000 annual Visa e-commerce transactions or those with up to one million Visa transactions in any channel must file a SAQ.

Note that any required documentation must be filed on an annual basis. Failure to do so could result in significant fines or penalties, even if you’ve filed this paperwork in previous years.

There are no expected major changes to the PCI DSS Level system for 2022. However, organizations should note that credit card companies may stipulate slightly different criteria for each Level. The numbers above are specified by Visa, one of the five Founding Members of the PCI Security Standards Council (SSC). To help ensure your compliance, confirm your reporting Level with each credit card company or partner with a QSA, such as RSI Security.

Request a Free Consultation

Working with a QSA

Organizations meeting Level 1, 2, and 3 are required to enlist the assistance of a QSA. These independent security organizations are fully qualified by the SSC to administer and validate AOCs and ROCs. Since QSA re-certifications are required on an annual basis, you’ll always benefit from the services of a knowledgeable professional.

laptop

Required Documentation

Now that you know your organization’s PCI level, it’s time to fill out and file the required documentation. This includes AOCs, ROCs, and SAQs. Since there aren’t any major changes expected to these documents in PCI DSS v4.0, you can use our PCI compliance checklist for 2021 to make sure you have the correct documents in hand.

Attestation of Compliance (AOC)

An AOC is generally required for any organization that handles more than 20,000 annual transactions (per Visa). Completed by a QSA, this document provides evidence that your organization has met the specifications of the PCI DSS. These documents are always filed alongside additional documents, such as ROCs or SAQs, for further verification and validation.

Report on Compliance (ROC)

This document provides a thorough assessment of your organization’s security infrastructure. Like AOCs, ROCs are always filled out by a QSA. Onsite audits constitute a significant part of the ROC, as is a complete review of your organization’s security controls. An auditor will test these controls onsite, obtain any pertinent documentation, and report their findings through the ROC.

Unlike AOCs, ROCs are guided by a rigid and standardized reporting process. Your QSA will use an ROC Reporting Template furnished by the PCI SSC to ensure compliance. Since this document is available to the general public, it’s recommended that you review the template as part of the PCI DSS requirements checklist.

Self-Assessment Questionnaire (SAQ)

Organizations that aren’t required to file an AOC or ROC are generally expected to produce an annual SAQ. There are currently nine different SAQ variations, which apply to different organizations according to their operations and interactions with cardholder data (CHD). No major changes are expected to SAQs in PCI DSS v4.0 or the 2022 PCI requirements checklist.

The nine different SAQ variations are:

SAQ A – Merchants that outsource the entirety of their CHD functionality are required to submit a SAQ A.
SAQ A-EP – E-commerce merchants that use a third-party website for payment processing are required to submit a SAQ A-EP.
SAQ B – Merchants that only use imprint machines or standalone, dial-out terminals are required to submit a SAQ B.
SAQ B-IP – Merchants with standalone, IP-connected point-of-interaction (POI) terminals that do not store any CHD are required to submit a SAQ B-IP.
SAQ C-VT – Merchants with web-based virtual terminals that don’t store CHD are required to submit a SAQ C-VT.
SAQ C – Merchants who don’t store CHD but do maintain payment application systems that are connected to the internet are required to submit a SAQ C.
SAQ P2PE-HW – Merchants using only hardware payment terminals in an SSC-approved P2PE system are required to submit a SAQ P2PE-HW.
SAQ D for Merchants – Merchants who are required to submit SAQs but don’t meet criteria for the above reports are required to submit a SAQ D.
SAQ D for Service Providers – Eligible service providers who do not meet criteria for the above reports are required to submit a SAQ D.

Transitioning to PCI DSS v4.0

The next iteration of the PCI DSS, version 4.0, was expected to see public release in 2021. However, the release date was delayed until Q1 2022. Given the significant evolution in IT capabilities and card payment security needs, the SSC has been progressing slowly with the intent of making v4.0 as comprehensive as possible.

v4.0 will significantly change some organizations’ compliance efforts while also not changing too much of the framework. The DSS’ 12 Requirements are not anticipated to change substantially (though some Requirements and sub-requirements will be expanded and receive new language). Additional changes will update the framework to reflect contemporary cybersecurity advancements and needs.

What is anticipated to change is how organizations meet stipulations, which may mean your PCI DSS requirements checklist requires modifications.

PCI DSS 12 Requirements

The 12 primary PCI DSS Requirements are expected to mostly remain the same. For review, the general stipulations and intent behind them are as follows:

Installing and maintaining a network firewall – This is a basic means of network protection that should be utilized by every organization, regardless of their size, scope, or industry.
Avoiding vendor-supplied or default system passwords – Remember, hackers have access to these generic passwords, too. Don’t make their job easier by using vendor-supplied defaults.
Protecting cardholder data (CHD) during storage – This highly sensitive data needs to remain protected at all times.
Encrypting CHD across all open or public networks – CHD should be encrypted whenever it’s sent on an open or public network.
Using and updating antivirus software – This one goes hand-in-hand with your network firewall. These two basic forms of protection are a necessity for any organization.
Developing and maintaining secure applications – Any future applications or system updates need to meet current security standards, too.
Restricting access to CHD on a need-to-know basis – Don’t take any unnecessary risks with CHD. Make sure it’s only accessible to those who need it.
Assigning a unique ID to each employee or user – This helps you monitor network and resource usage while making it easier to spot any inside threats or issues.
Controlling and restricting physical access to databases or devices containing CHD – While it’s critical that you secure CHD within your digital environment, physical access to systems and workstations must similarly be protected.
Tracking and monitoring access to network resources and CHD – Network monitoring tools often serve as early detection systems for network attacks and other issues.
Testing security systems and parameters – Ensure your current security protocols are fully functional with regular threat assessments and penetration tests.
Maintaining a policy that accounts for employees and contractors – All PCI DSS and general cybersecurity policies, procedures, and configurations should be well-documented and made available to all appropriate parties.

Outcome-Based Perspective

The most substantial change to the PCI DSS brought by v4.0 is “customized validation.” The SSC has recognized that the framework inadvertently created numerous unnecessary hurdles for many organizations. To rectify this, the DSS’ language will be updated to better reflect intent- and outcome-based perspectives; compliance can be verified if these are demonstrably met, similar to existing compensating control documentation.

For some organizations, this is incredible news. However, they will likely face an increased burden of proving compliance, which may mean that only the largest, most mature, and most sophisticated organizations realize the reporting benefits.

Compensating Controls

For PCI DSS v3.2.1 and earlier, organizations that didn’t meet the framework’s stipulations word-for-word were given the option of providing compensating control worksheets (CCW) in their reporting documentation—regardless of Level-determination—for all relevant Requirements. Up to now, CCWs were an organization’s only means of not explicitly implementing a given Requirement or sub-requirement and maintaining compliance.

Per Appendix B of SAQ A, CCWs require documentation regarding:

The legitimate technical or business constraints preventing the organization from implementing and complying with the original Requirement or sub-requirement in question
The intent or outcome of the original Requirement or sub-requirement
The risk(s) acknowledged in the absence of implementing the original Requirement or sub-requirement
An explanation of the compensating controls implemented in lieu of the original Requirement or sub-requirement, along with:
- The extent to which the compensating controls achieve the intent or outcome of the original Requirement or sub-requirement
- An adjusted risk assessment accounting for the compensating control’s implementation
An explanation of how the organization’s QSA assessed and validated the compensating controls
A description of the organization’s processes and documentation regarding ongoing maintenance of the compensating control

Organizations that continue to use the “traditional” compliance validation approach will still be able to submit CCWs as needed. Those intending to adopt the new “customized validation” approach can also turn to CCWs for the best current frame of reference of what to expect.

What does “Customized Validation” mean?

At a high-level, “customized validation” will likely mirror much of the CCW process. The SSC even refers to the new process as the “natural evolution of compensating controls.” The primary difference is that organizations will no longer need to state the technical or business constraints preventing their implementation of the original Requirements and sub-requirements as stipulated by the framework.

So long as the relevant aspect of an organization’s cybersecurity program addresses a Requirement or sub-requirement’s intent or mandated outcome, willful flexibility is now allowed.

“Customized validation” is anticipated to best suit organizations operating a very mature cybersecurity program (i.e., those that already go above and beyond the “floor” of PCI DSS Requirements). If your organization is approaching this new, flexible reporting option as a way to avoid elements of PCI DSS implementation, you’ll likely be disappointed with the increased burden.

Remember that your QSA partner will gladly help with all of your PCI compliance checklist requirements, but they must still function as a third party and are beholden to SSC re-certification. Therefore, “customized validation” isn’t a compliance shortcut, and, especially during the initial years of v4.0, organizations that choose it will likely find their implementations held to a high level of scrutiny.

Additional v4.0 Changes

Aside from “customized validation” presenting a significant change to how compliance can be demonstrated, PCI DSS v4.0 is expected to emphasize the following updates to the framework:

Updated security requirements for cloud and serverless workloads – While similar requirements were established in earlier versions, cloud usage has evolved. Those stipulations also did not apply specifically to cloud or serverless workloads.
New control requirements for data encryption – Data encryption is now required for any data transmission, including those made within trusted networks.
Mandatory Designated Entities Supplemental Validation (DESV) – In previous iterations, DESVs were only required from organizations that experienced a security or data breach. In PCI DSS v4.0, DESVs may be mandatory for every organization.
General security enhancements – Although specific details haven’t been released, we can expect to see more stringent security enhancements across the board (e.g., adopting NIST guidelines for multifactor authentication and passwords). The primary focus of PCI DSS v4.0 is on enhanced security, both online and off, so it’s a common theme amongst all the upcoming changes.

You can get a headstart on these updates by expanding your organization’s use of encryption, transitioning to the cloud (if you haven’t already), enabling multifactor authentication, and working with a QSA to assess the current state of your organization’s IT security.

v4.0 Transition Timeline—Compliance by When?

Once fully activated, organizations are granted a transition period of 18 months to become familiar with and implement v4.0 changes. Additionally, an extra period of time will be granted for any future-dated obligations, with implementation deadlines specified accordingly.

Maintaining Full PCI DSS Compliance

No PCI compliance checklist for 2021 is complete without providing some insight into the expected updates, revisions, and modifications in 2022 and beyond. To ensure your organization maintains compliance for years to come, contact RSI Security today.