A Closer Look at Payment Card Industry Data Security Standards (PCI DSS)
Breaking Down Barriers Between PCI Compliance and Cybersecurity
The Payment Card Industry Data Security Standards (PCI DSS) consist of hundreds of operational and technical requirements for organizations that accept, store, process or transmit cardholder information. Organizations such as merchants, processors, acquirers, insurers and service providers may be subject to PCI DSS compliance.
Overseen by the PCI Security Standards Council (PCI SSC), the PCI DSS framework is intended to protect payment data and make it more difficult for cybercriminals to access this sensitive information. PCI SSC also oversees payment card standards for software and app developers with the Payment Application Data Security Standard (PA-DSS), as well as the PIN Transaction Security (PTS) mandates for organizations that create credit card transactions devices.
There are 15 PCI security standards which merchants, financial institutions and service providers are expected to apply to payment processes with the intended purpose of ensuring security for all related technologies and practices.
The newest version is PCI DSS v4.0, which PCI SSC released in March 2022. It’s the first update to these standards since summer of 2018. Version 3.2.1 will remain in effect until it’s retired on March 31, 2024. PCI SSC will require organizations to meet v4.0 requirements by March 31, 2025.
In this overview, learn more about the newest version, including PCI DSS goals, who should be PCI compliant, and best practices for implementation and management.
Learn more about:
Make PCI Compliance Business-as-Usual
Protecting cardholder data is more than a requirement; it’s good business practice.
Learn MoreHow to Enable Continuous PCI Monitoring
Explore the security requirements behind PCI DSS and how to maintain the standards.
Learn MoreJoin the PCI DSS Community
Join other professionals interested in learning more about PCI Data Security Standards.
Learn MorePCI DSS Frequently Asked Questions
Have questions about PCI DSS? Check out this FAQ for answers to common questions.
Learn MorePCI Merchant Levels
PCI merchant levels are established by payment card brands, which are based on transaction numbers.
Learn MorePCI DSS Requirements
Learn more about the four primary goals for the new set of PCI DSS standards (version 4).
Learn MoreEnsuring PCI Compliance
Now is the time to be working on becoming compliant for PCI DSS v4, which goes into effect in 2025.
Learn MoreMaintain PCI Compliance With Comprehensive Visibility Into Your Attack Surface
If your organization handles credit or debit card processing, attackers are likely lurking, hoping to access that valuable data. Protect your customers’ information and ensure PCI compliance with Tenable One.
Make PCI Compliance Business-as-Usual
Attackers know credit and debit card information is valuable, and they’re developing ever-more complex and expansive measures to try to steal it from you. Protecting that data isn’t just a good business practice, it’s a requirement for PCI DSS compliance.
PCI DSS covers a range of baseline technical and operational security controls intended to protect cardholder data from breaches and theft. These standards are applicable to any organization that accepts, stores, processes, or transmits cardholder information. It applies to point-of-sale vendors, hardware and software developers, merchants and financial institutions — basically anyone involved in processing credit and debit card data.
This solution brief explores best practices about how you can go beyond just passing a PCI audit, but also how — and why — you should make PCI compliance part of business-as-usual operations.
In this brief, learn more about:
- The potential impact of PCI security standards on your operations
- Why PCI DSS is more than an audit process
- How you can continuously assess your PCI compliance
- Get near real-time insight into potential cardholder data threats
- Maintain compliance between assessments
PCI Insights
Addressing PCI DSS
A breach of your clients’ cardholder data could result in fines, penalties, and response and recovery costs that can quickly reach into millions of dollars. Beyond that, it puts your customers at risk of identity theft and can quickly destroy your brand and reputation. That’s why it’s important to understand exactly what’s expected of your organization to meet PCI security standards and build customer confidence that you take the maintaining the security and privacy of their sensitive data very seriously.
This solution brief takes a closer look at the role of internal and external vulnerability scanning in meeting PCI requirements. If your organization still manages your security and compliance controls manually, you will likely benefit from learning more about how using an exposure management platform like Tenable One can help your organization improve efficiencies and decrease the likelihood you may overlook critical vulnerabilities in your cardholder data systems and applications.
Read more to learn about:
- How to develop configuration standards for all of your cardholder data environment systems
- Addressing threats and vulnerabilities in your public-facing web applications
- How to utilize active and passive scanning
- Risk-based vulnerability management best practices for PCI compliance
Tenable Community: Your Go-To Resource for All Things PCI
If you have questions about PCI compliance and security, join the Tenable Community to connect with others who have similar interests. In the community, you can learn more about important PCI topics such as ASV scanning, PCI validation, PCI audits, and more.
Here are some sample conversations happening now:
PCI Internal Scan or PCI-DSS Compliance Audit File
We have used PCI internal scan template and got some vulnerabilities as expected such as unpatched ... My question is, do I need to run PCI-DSS audit file for our quarterly internal scans?
Read MorePCI DSS Version for External Scans
What PCI DSS version is used by Tenable.io for external PCI compliance scans?
Read MoreTenable.io PCI ASV - Background and Review Process
Approved Scanning Vendors (ASVs) are organizations that validate adherence to PCI requirements by performing vulnerability scans of internet-facing environments.
Read MoreFrequently Asked Questions About PCI
Are you new to PCI security and compliance? Do you have questions but not sure where to start? Check out some of these frequently asked questions about PCI.
What does PCI stand for?
What is PCI?
Who is the PCI Security Standards Council (PCI SSC) and what do they do?
Why is PCI important?
Is PCI compliance required by law?
What does it mean to be PCI compliant?
What is PCI DSS?
What is PCI DSS intended to do?
What are the 12 primary PCI compliance requirements?
There are 12 primary requirements for PCI compliance:
- Install and maintain a firewall configuration to protect cardholder data
- Don’t use vendor-supplied defaults for system passwords and other security parameters
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open, public networks
- Use and regularly update anti-virus software or programs
- Develop and maintain secure systems and applications
- Restrict access to cardholder data by business need-to-know
- Assign a unique ID to each person with computer access
- Restrict physical access to cardholder data
- Track and monitor all access to network resources and cardholder data
- Regularly test security systems and processes
- Maintain a policy that addresses information security for all personnel
Who should be PCI compliant?
What are some benefits of PCI compliance?
There are many benefits of PCI compliance. Here are a few examples:
- Security for customers' cardholder data
- Decreased risk of data breaches and other security incidents
- Building customer reputations and trust
- Protecting your organization/brand
- Not incurring fines or penalties for non-compliance
- Competitive advantage
What happens if I am not PCI compliant?
What are the PCI compliance levels?
In PCI DSS, what is considered cardholder data (CHD)?
What is considered sensitive authentication data?
What is a PCI DSS cardholder data environment (CDE)?
What is the PCI Software Security Framework (SSF)?
What are PCI SSC Software Standards?
What is considered validated software through PCI SSC software standards?
What is considered a validated software vendor through PCI SSC software standards?
What is PA-DSS?
What is a PCI SSC Approved Scanning Vendor (ASV)?
Is Tenable a certified ASV?
Is vulnerability scanning part of PCI compliance?
How often does PCI require a vulnerability scan?
What are some common PCI violations?
What is a PCI ASV vulnerability?
How long should an PCI ASV scan take?
What are the main stages of a PCI scan process?
Using Tenable, the main stages of the PCI scan process are:
- Create a scan with a template.
- Launch the scan.
- Submit the scan to your PCI ASV dashboard.
- Create an attestation request draft.
- After addressing all the failures, submit the scan attestation for ASV review.
What systems should be in scope for PCI ASV scanning?
Are ASVs the same as Qualified Security Assessors (QSA)?
What are some best practices for PCI DSS implementation?
Understanding PCI DSS Merchant Levels
Organizations are classified into one of four compliance levels based on payment card transaction volume during a 12-month period. This includes credit, debit, prepaid, gift, chip and store value cards that have a logo of a PCI SSC Participating Payment Brand (a PCI SSC member or affiliate).
Each credit card brand can set its own criteria for merchant levels based on a variety of factors, so it’s important to check directly with your acquiring bank or credit card brand for your appropriate level. Here is an example of merchant levels from Visa and Mastercard:
-
Merchant Level 1
More than 6 million credit or debit card transactions per year.
Requirement: Conduct an annual internal audit and have quarterly approved scanning vendor (ASV) PCI scan.
-
Merchant Level 2
1-6 million transactions annually.
Requirement: Conduct annual self-assessment questionnaire. Could be subject to quarterly ASV PCI scan.
-
Merchant Level 3
20,000 to 1 million annual transactions.
Requirement: Conduct an annual self-assessment. Could be subject to quarterly ASV PCI scans.
-
Merchant Level 4
Fewer than 20,000 annual transactions and all other merchants that process up to 1 million transactions each year.
Requirement: Conduct an annual self-assessment questionnaire. May be subject to quarterly ASV PCI scans.
According to PCI SSC, there are three other payment brands (JCB, Discover and AMEX). While they have their own merchant levels and requirements, in many instances, meeting the criteria above will generally meet their standards. But, don’t forget to check with your brand for specifics.
Understanding PCI DSS Requirements
After three rounds of requests for comments (RFCs), more than 6,000 feedback items and input from more than 200 companies, PCS SSC released PCI DSS v4.0 in March 2022. While v3.2.1 will remain in effect until the end of the first quarter of 2024, organizations should already be taking steps to implement 4.0 standards. The new requirements will become effective on March 31, 2025.
According to PCI SSC, there are four primary goals for the new standards:
-
Meeting the payment industry’s security needs
Examples: Expanded multi-factor authentication, updated passwords and new e-commerce and phishing requirements.
-
Promoting security as a continuous process
Examples: Clearly assigned roles and responsibilities for each requirement and more guidance on how to implement and maintain security
-
Adding flexibility for different methodologies
Examples: Allowing group, shared and generic accounts and targeted risk analyses.
-
Enhancing validation methods
Examples: More alignment between information in reports and attestations.
Understanding PCI DSS Requirements
To help organizations that accept, store, process or transmit payment card information protect customer’s sensitive data safely and privately, there are 12 principal requirements for PCI DSS v4.0.
They are:
Build and Maintain a Secure Network and Systems
- Install and maintain network security controls
- Apply secure configurations to all system components
Protect Account Data
- Protect stored account data
- Protect cardholder data with strong cryptography during transmission over open, public networks
Maintain a Vulnerability Management Program
- Protect all systems and networks from malicious software
- Develop and maintain secure systems and software
Implement Strong Access Control Measures
- Restrict access to system components and cardholder data by business need-to-know
- Identify users and authenticate to system components
- Restrict physical access to cardholder data
Regularly Monitor and Test Networks
- Log and monitor all access to system components and cardholder data
- Test security of systems and networks regularly
Maintain and Information Security Policy
- Support information security with organizational policies and programs
These requirements apply to:
- Cardholder data environment (CDE)
- System components, people, and processes that store, process and transmit cardholder data and/or sensitive authentication data
- System components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process or transmit CHD/SAD
- System components, people, and processes that could impact the security of the CDE
There are some incidents where PCI DSS requirements may apply to organizations that do not store, process or transmit cardholder data. For example, organizations that manage cardholder data environments (CDE) or entities that outsource their payment processing to third parties. If your organization outsources to such third parties, you’re still responsible for protecting cardholder data by ensuring that the third party meets PCI DSS standards.
Ensuring PCI DSS Compliance
You may be wondering if you need to be compliant for PCI DSS v3.2.1 or PCI DSS v4.0.
If your organization is not yet PCI DSS compliant, focus your compliance journey on meeting version 4.0 requirements. The effective date for PCI DSS v4.0 is March 31, 2025.
If your organization is compliant for version 3.2.1, then now is the time to focus on meeting the standards established in version 4.
The first step toward PCI compliance should begin with establishing your merchant level. As mentioned above, that level is based upon the number of payment card transactions during a 12-month time frame and each credit card brand can set its own criteria for each level and related requirements.
In terms of validating your PCI DSS compliance, based on your transaction volume, your organization may be able to complete a self-assessment questionnaire (SAQ), a report on compliance (ROC) or you may be required to work with a third-party independent qualified security assessor (QSA). To earn a PCI certification, you must work with a QSA. A QSA is approved by PCI SSC to certify your organization meets PCI DSS standards and can issue an attestation of compliance (AOC), if you meet all requirements of your assessment.
To determine if you qualify for a self-assessment or need to work with a QSA, consult with your credit card brand or financial acquirer.
If you can complete a self-assessment, it’s important to note there are several different self-assessment questionnaires that are applicable based on environment type. According to PCI SSC, each questionnaire has a “Before You Begin” section that discusses the environment that’s applicable to that questionnaire, including eligibility criteria.
After choosing the appropriate questionnaire and confirming your environment criteria, you should complete all sections within the SAQ as well as each AOC included in each SAQ. AOCs are also available as standalone documents.
If your organization is required to complete external vulnerability scans, you can work with an ASV vendor to evaluate your vulnerability management practices and ensure your scanning processes meet PCI DSS standards. The approved ASV vendor can provide you with scan reports.
Once you’ve completed your SAQ, AOC and scans, submit all required documentation to your payment brand or acquirer.
Again, individual payment brands ultimately determine an organization’s classification or risk level, but in general, according to PCI SSC, there are six key steps for PCI compliance. At a high level, here is what a PCI DSS assessment may include:
Scope
Know which system components and networks are in scope for PCI DSS.
Assess
Examine compliance of system components in scope after testing procedures for each PCI DSS requirement.
Report
Assessor and/or entity completes required documentation — for example, self-assessment, questionnaire (SAQ) or report on compliance (ROC) — with documentation for all compensating controls.
Attest
Complete appropriate Attestation of Compliance (AOC)
Submit
Submit SAQ, ROC, AOC and other supporting documentation such as ASV scan reports to the acquirer (for merchants) or to the payment brand/requestor (for service providers)
Remediate
Perform remediation (if required) to address requirements not in place then provide an updated report
Proactively Monitor and Maintain Your PCI Compliance
With Tenable One’s broad coverage and continuous monitoring, you can effectively manage all of your PCI DSS controls with instant, easy-to-understand insight into how well you’re meeting your PC compliance goals.
PCI Blog Bytes
Everybody Does Good VM When S#*t Hits the Fan
To meet PCI DSS compliance, your organization needs insight into the critical vulnerabilities that exist in your environment now, what you’re going to do to remediate them, and how you’re going to address them in the future. Read this blog to learn about how to maintain your vulnerability management program to meet your PCI standards.
Cloud Security: 5 Key Takeaways from the SANS DevSecOps Survey
Regardless of how big or small you are, it’s likely that today your organization manages multiple security and compliance frameworks such as PCI. But, how do you know if you’re using best practices? This blog takes a closer look at findings from the “SANS 2022 DevSecOps Survey,” including insight into ways to build confidence in your PCI compliance practices.
Cyber Hygiene: 5 Advanced Tactics to Maximize Your Risk Reduction
Most modern businesses today accept some type of credit or debit card payments. If you do, you’re likely required to be PCI DSS compliant. If you’re not protecting that payment data, you’re putting your customers — and your business — at risk. This blog, part of a series on cyber hygiene, overviews ways you can ensure comprehensive visibility for your networks.
PCI on Demand
When It Comes to Effective Cloud Security, Sharing is Caring
For many organizations, different departments, locations or divisions can have a variety of cloud-based services and applications. As such, it’s important to build cross team collaboration to ensure effectiveness of your cloud security measures and to meet PCI DSS cloud computing requirements.
In this webinar, learn more about:
- How to improve cross-team engagement with adoption of policy as code
- How to scale cloud adoption with key cloud security capabilities
- The evolution of cloud security posture management (CSPM) to include infrastructure as code
Effectively Protect Your Microsoft Azure Cloud Deployments from Code to Runtime
Misconfigurations and other errors could affect your PCI compliance. That’s why it’s important to have comprehensive visibility into your cloud environments so you can identify your security vulnerabilities, prioritize what needs your attention first, and effectively analyze and remediate your cloud security risks.
In this webinar, learn more about:
- Key Microsoft Azure security considerations such as user management and cloud resources
- How to effectively protect Azure deployments from runtime to policy
- How to identify, assess and defend your organization’s Azure attack paths
Ensure Your Cloud Environments Meet PCI DSS Standards
As more organizations shift systems and applications into the cloud, PCI SSC has included cloud-computing controls and considerations as part of its PCI DSS guidance. Whether you’re working in a private, community, public or hybrid cloud environment, Tenable One can give you the comprehensive visibility you need to ensure you’re protecting your customers’ payment card data while meeting PCI DSS compliance standards.
Assess Scope
As part of PCI DSS compliance, your organization must understand the scope of your systems and networks. Many organizations struggle with this because they don’t have visibility into all of their assets. With Tenable One, you can discover all of your in-scope assets such as servers, web applications, network devices and databases.
Document with Confidence
Completing and submitting appropriate documentation is part of the PCI DSS compliance journey. If you’re still tracking this data manually in spreadsheets or other GRC tools, it’s time-consuming and you can overlook important information. Tenable One simplifies documentation with out-of-the-box report and scan templates.
Discover and Prioritize Vulnerabilities
To ensure you’re keeping payment card data safe, you need to know more than just where you have vulnerabilities. You also need insight into the potential impact on your compliance so you know which ones to remediate first. Tenable One enables risk assessments so you can discover, prioritize and remediate security issues — on-prem and in the cloud.
See Tenable One in Action
Continuously assess and manage all of the systems and applications within your cardholder data environment (CDE) with Tenable One.
- Tenable Cloud Security
- Tenable One