Maintain 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.
Tenable Connect community: Your go-to resource for all things PCI
If you have questions about PCI compliance and security, join the Tenable Connect 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.
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?
PCI DSS version for external scans
What PCI DSS version is used by Tenable.io for external PCI compliance scans?
Tenable.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.
Frequently 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?
-
PCI is the abbreviation for the Payment Card Industry. PCI represents organizations that process, transmit and store cardholder data including debit, credit, prepaid, point-of-sale, ATM and e-wallet cards.
-
What is PCI?
-
PCI is a set of security standards your organization can use to process, transmit and store payment card information while ensuring you’re using best practices to protect and secure payment card data.
-
Who is the PCI Security Standards Council (PCI SSC) and what do they do?
-
The PCI Security Standards Council (PCI SSC) is an organization created to manage and develop PCI Data Security Standards (PCI DSS). Its goal is to ensure organizations take necessary steps to protect cardholder data.
-
Why is PCI important?
-
PCI is important because it protects and secures sensitive cardholder data for all transactions, even when stored. If your organization accepts debit, credit, and point-of-sale cards, you should be PCI compliant. Not only is it a requirement, but these standards can help ensure you’ve got the right security controls in place to keep your customers’ payment data safe.
-
Is PCI compliance required by law?
-
No. PCI compliance is not required by law. Some state laws and industry requirements may have PCI-related mandates to protect cardholder data during payment transactions.
-
What does it mean to be PCI compliant?
-
To be PCI compliant, your organization must demonstrate that you meet PCI DSS requirements to secure cardholder data. Some PCI controls are related to data encryption, vulnerability management, and ongoing risk assessments and risk management. To demonstrate compliance, a qualified security assessor should assess your organization each year.
-
What is PCI DSS?
-
PCI DSS is an abbreviation for Payment Card Industry Data Security Standards, which represents a set of security standards your organization can use to protect and secure payment card data whenever you process, transmit or store it.
-
What is PCI DSS intended to do?
-
The intention of PCI DSS is to provide set standards for organizations to ensure they’re maintaining secure environments for payment data. The goal is to reduce the likelihood of a successful breach.
-
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?
-
If your organization accepts, processes, stores, or transmits credit cards you should be compliant for PCI DSS, regardless of your industry or organization size.
-
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?
-
If you are not PCI compliant, your organization could lose the right to accept payment cards. You could also be subject to fines, penalties, and potentially criminal or civil legal action. If you’re not compliant, you may also have to pay higher processing fees and could potentially be the victim of a security incident.
-
What are the PCI compliance levels?
-
There are four levels of PCI compliance levels based on how many transactions you process during a 12-month period. The levels are: 1: more than 6 million credit or debit card transactions per year; 2: 1-6 million transactions annually; 3: 20,000 to 1 million annual transactions and 4: 4: Fewer than 20,000 annual transactions and all other merchants that process up to 1 million transactions each year.
-
In PCI DSS, what is considered cardholder data (CHD)?
-
In PCI DSS, cardholder data (CHD) is any information your organization uses to identify a cardholder or account information. This may include cardholder name and address as well as card number, expiration date and CVV code.
-
What is considered sensitive authentication data?
-
For PCI DSS, sensitive authentication data is considered any data that someone may use to authenticate a cardholder. For example: PINs, PIN blocks and the data associated with the magnetic stripe on the back of the card.
-
What is a PCI DSS cardholder data environment (CDE)?
-
A PCI DSS cardholder data environment (CDE) represents any network, system or application that stores, processes or transmits cardholder data, including authentication data.
-
What is the PCI Software Security Framework (SSF)?
-
The PCI Software Security Framework (SSF) is a set of standards your organization can use to develop and maintain secure software as part of PCI DSS compliance.
-
What are PCI SSC Software Standards?
-
PCI SSC Software Standards are requirements for software products used in PCI DSS-compliant environments. Some of the requirements include encryption, password management, vulnerability management and secure software development.
-
What is considered validated software through PCI SSC software standards?
-
Validated software through PCI SSC software standards are software that third-parties have independently tested and validated to demonstrate the software meets PCI SSC software standards.
-
What is considered a validated software vendor through PCI SSC software standards?
-
A validated software vendor through PCI SSC software standards is any vendor that has had its software assessed by an independent assessor and after testing has demonstrated compliance with specific PCI SSC software standards.
-
What is PA-DSS?
-
PA-DSS is an abbreviation for the Payment Application Data Security Standard. The PCI Security Standards Council created PA-DSS to help software vendors and merchants ensure they are developing and maintaining security standards for payment applications that store, process or transmit cardholder data during transactions.
-
What is a PCI SSC Approved Scanning Vendor (ASV)?
-
A PCI SSC Approved Scanning Vendor (ASV) is an organization the Payment Card Industry Security Standards Council (PCI SSC) has approved to conduct external vulnerability scanning services for organizations that handle card data.
-
Is Tenable a certified ASV?
-
Yes. Tenable is a certified ASV for PCI DSS compliance. As a certified ASV, PCI SSC has approved Tenable to perform vulnerability scans of organizations’ systems to ensure they’re compliant with PCI DSS requirements. Major credit card companies accept Tenable scans as proof of PCI DSS compliance.
-
Is vulnerability scanning part of PCI compliance?
-
Yes. Vulnerability scanning is a requirement of PCI compliance. Vulnerability scanning is a type of test your organization or a third party can conduct to discover potential misconfigurations and other security issues before threat actors can exploit them.
-
How often does PCI require a vulnerability scan?
-
PCI requires vulnerability scans at least quarterly, but it is a good idea to conduct them more frequently, especially as your organization or environment changes.
-
What are some common PCI violations?
-
Some examples of common PCI violations are leaving device screens that show cardholder data to be visible by the public, not storing paper copies of cardholder data in locked cabinets or locked drawers, using default passwords or not routinely changing passwords, failure to encrypt sensitive cardholder data, not having secure network configurations, and not implementing strong access control measures.
-
What is a PCI ASV vulnerability?
-
A PCI ASV vulnerability is a vulnerability an ASV identifies during a PCI-compliant vulnerability scan.
-
How long should an PCI ASV scan take?
-
The amount of time PCI ASV scan can will vary based on a variety of factors such as: network size and complexity. In many cases, it takes several hours to conduct a PCI ASV scan.
-
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?
-
Any external-facing system that is a pathway to the cardholder data environment should be considered in scope for PCI ASV scanning.
-
Are ASVs the same as Qualified Security Assessors (QSA)?
-
No. ASVs and QSAs are not the same. PCI SSC certifies QSAs to conduct on-site PCI compliance assessments, while ASV are approved to conduct external vulnerability scans for PCI compliance testing.
-
What are some best practices for PCI DSS implementation?
-
There are several best practices to consider for PCI DSS implementation. PCI SSC recommends organizations implement a PCI DSS as a security baseline, which is a framework to help organizations of all sizes develop data security processes to protect cardholder data, including controls for prevention, detection and appropriate response to security incidents.
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:
1. Meeting the payment industry’s security needs
Examples: Expanded multi-factor authentication, updated passwords and new e-commerce and phishing requirements.
2. 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
3. Adding flexibility for different methodologies
Examples: Allowing group, shared and generic accounts and targeted risk analyses.
4. 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.
Tenable One
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.
Tenable One
Request a demo
The world’s leading AI-powered exposure management platform.
Thank You
Thank you for your interest in Tenable One.
A representative will be in touch soon.
Form ID: 7469
Form Name: one-eval
Form Class: c-form form-panel__global-form c-form--mkto js-mkto-no-css js-form-hanging-label c-form--hide-comments
Form Wrapper ID: one-eval-form-wrapper
Confirmation Class: one-eval-confirmform-modal
Simulate Success