PCI DSS Compliance Checklist & Tutorial

The Payment Card Industry Data Security Standard (PCI DSS) was created in 2004 by credit card companies to reduce fraud and establish credibility for the usage of cardholder data in electronic transactions. It introduced specific baseline security requirements for merchants and service providers processing credit card data, noncompliance with which would result in large penalties and increased transaction fees. 

Depending on the volume and nature of their transactions, organizations handling credit can conduct self-audits by answering a Security Assessment Questionnaire (SAQ) or require a third-party PCI Qualified Security Assessor (QSA). The starting point for any such audit is identifying and finalizing the scope of the audit. The specific security requirements for PCI DSS compliance depend on the volume and nature of credit card transactions within the organization. 

This article presents a checklist for passing the PCI audit and recommendations for preparing for the audit.

Summary of key PCI DSS compliance concepts 

Concept	Description
Scope and importance	Any organization dealing with credit card data needs to be PCI DSS compliant to avoid steep fines and breaches.
Types of organizations	Relevant organizations include merchants, service providers, and financial institutions.
Self-assessment vs. third-party audits	Smaller organizations can use self-assessments; larger ones need third-party audits.
Self-Assessment Questionnaires (SAQs)	Types include SAQ A, B, C and C-VT, D and D–Service Provider, tailored to different scenarios.
Levels of PCI compliance	There are four levels of compliance based on the volume of credit card transactions; the higher the level, the more rigorous the requirements.
High-level PCI DSS requirements	Six groups focus on network security, data protection, vulnerability management, and access control, monitoring, and policy.

Essential questions to answer when assessing PCI DSS compliance

The following subsections provide answers to common questions when assessing how to become compliant with PCI DSS.

Does every organization that processes credit card data need to be PCI DSS compliant?

Any business or entity that has a hand in the journey of credit card data—be it storing, transmitting, or simply processing—needs to adhere to PCI DSS. Violating these requirements doesn’t merely risk receiving a minor warning: It can result in thousands of dollars in penalties and potential loss of reputation and customers. 

The PCI DSS regulations offer a blueprint for how to store data securely, how to encrypt it when sending it across networks, and even what to do in the grim scenario of a data breach. Depending on how many card transactions you handle, you’ll fall into one of four levels, each with its own specific validation requirements. While bigger corporations will find themselves scrutinized more intensely through full-scale audits, smaller businesses can ensure compliance with the requirements listed in the self-assessment questionnaires through the help of technically equipped personnel.

What are the different categories of organizations that fall under the scope of PCI DSS?

Organizations dealing with credit card data fall into three primary categories:

• Merchants: Businesses that accept card payments in physical stores, online, or through various payment channels
• Service providers: Third-party organizations responsible for processing, storing, or transmitting card data on behalf of merchants
• Financial institutions: Banks, credit card issuers, and other financial institutions

Should you conduct a PCI self-assessment or invite third-party auditors?

A PCI DSS Self-Assessment or Self-Assessment Questionnaire (SAQ) is a set of questions delving into the nitty-gritty of how an organization handles credit card data. If answered with diligence and transparency, it serves as an effective tool to evaluate the organization’s security posture and to identify, remediate, and document the steps taken to ensure compliance.

Conduct a self-assessment when you’re a smaller operation processing a modest volume of transactions, usually less than 1 million annually, and your payment systems are straightforward. 

Conduct a third-party audit by engaging a PCI Qualified Security Assessor (QSA) if your organization processes over 6 million transactions per year, runs complex operations over diversified payment channels, and requires a QSA to provide stakeholder assurance.

What are the different types of Self-Assessment Questionnaires (SAQs)?

There are several types of SAQs that are tailored to different scenarios. The most common SAQs are the following:

• SAQ A: For merchants that fully outsource cardholder data functions to PCI DSS–validated third parties
• SAQ B: For merchants using standalone, dial-out terminals with no electronic cardholder data storage
• SAQ C and C-VT: For merchants with payment application systems connected to the internet (C) or via isolated virtual terminals on a personal computer (C-VT)
• SAQ D and SAQ D–Service Provider: For merchants and service providers who do not meet the criteria for other SAQ types

Please note that larger financial institutions or organizations with more complex data environments would require a thorough on-site audit conducted by a third-party PCI Qualified Security Assessor (QSA). For a comprehensive list of the SAQs, refer to the PCI DSS Self-Assessment Questionnaire Instructions and Guidelines document.

Are there different levels of PCI Compliance?

Yes: PCI compliance levels are determined by the volume of credit card transactions handled by a merchant. The higher the level, the more rigorous the requirements details, which are stated below.

For merchants

• Level 1: Merchants processing over 6 million transactions per year across all channels or any merchant that has suffered a breach that resulted in account data compromise
  • Requirements: Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) or an Internal Security Assessor (ISA), if applicable; quarterly network scans by an Approved Scanning Vendor (ASV) and completion of the Attestation of Compliance (AOC) form
• Level 2: Merchants processing 1 to 6 million transactions per year
  • Requirements: Annual Self-Assessment Questionnaire (SAQ); quarterly network scans by an ASV and completion of the AOC form
• Level 3: Merchants processing 20,000 to 1 million e-commerce transactions per year
  • Requirements: Annual SAQ; quarterly network scans by an ASV and completion of the AOC form
• Level 4: Merchants processing fewer than 20,000 e-commerce transactions per year and all other merchants processing up to 1 million transactions per year
  • Requirements: Annual SAQ recommended; quarterly network scans by an ASV, if applicable, and completion of the AOC form

For service providers

• Level 1: All service providers defined by a payment brand as Level 1 or providers that store, process, or transmit more than 300,000 transactions per year
  • Requirements: Annual ROC by a QSA or ISA; quarterly network scans by an ASV and completion of the AOC form
• Level 2: All other service providers that store, process, or transmit fewer than 300,000 transactions per year
  • Requirements: Annual SAQ or ROC as determined by the service provider’s needs or as specified by a payment brand; quarterly network scans by an ASV and completion of the AOC form

Common to all levels

All entities must build and maintain a secure network, protect cardholder data, maintain a vulnerability management program, implement access control measures, monitor and test networks regularly, and maintain an information security policy.

What are the high-level PCI DSS requirements?

At a high level, PCI DSS requirements are based on six principles, each addressing specific aspects of data security and compliance as stated below:

• The building and maintaining a secure network and systems group focuses on creating a secure network infrastructure, firewalls, and system configurations.
• The protection of cardholder data requirement is concentrated on safeguarding stored cardholder data and encrypting data during transmission. 
• The vulnerability management group focuses on continuous vulnerability scans and prioritized patch management. 
• The access control group requires controlling access based on the need-to-know principle and secure user authentication. 
• The monitoring and testing group focuses on reviewing security alerts and conducting comprehensive penetration testing. 
• Security policy and procedures create the baseline security requirements to establish and maintain compliance. 

Getting started with a PCI DSS Audit

Passing a PCI audit and achieving compliance with PCI DSS requirements can be a challenging yet fulfilling undertaking. Start early to ensure that you have adequate time to meet the audit deadline because, more often than not, you will run into unexpected roadblocks.

Identify cardholder data and sensitive information footprints within your organization. This will help you define and narrow down the scope for PCI audit as the stringent PCI standards would only apply to your cardholder data environment (CDE). Use network segmentation to isolate cardholder data and your PCI environment.

PCI DSS requires that cardholder data always be encrypted both in transit and at rest. Ensure that your encryption standards and processes are updated and standardized, access to encryption keys is restricted, and encryption keys are rotated periodically.

Implement and enforce access control measures to restrict access to sensitive data based on the principle of least privilege. 

Provide training to your development and IT teams that covers PCI-specific requirements of secure SDLC, data encryption, and backups. A PCI auditor will review your architecture, deployment, and processes against your documentation, network diagrams, data flow diagrams, and security protocols because they form the bedrock of how securely the architecture is designed and deployed.

Roadmap to prepare for a PCI DSS compliance audit

 The table below summarizes the preparation steps for a PCI DSS compliance audit.

<td”>Regularly update and patch systems Software updatesRegularly update all software to protect against known vulnerabilities.

Category	Item	Description
Scope assessment	Define scope	Identify all systems, processes, and personnel that interact with or affect the security of cardholder data.
	Validate scope	Confirm that your initial scope accurately captures all areas where cardholder data is present.
Build and maintain a secure network	Firewall configuration	Ensure that firewalls are configured to protect cardholder data.
	Vendor defaults	Change vendor-supplied default settings.
Protect stored data	Data encryption	Encrypt stored cardholder data.
	Data retention policy	Define and enforce a data retention policy that purges unnecessary stored cardholder data.
Encrypt data transmission	Secure transmissions	Use strong cryptography to secure cardholder data during transmission over public networks.
Regularly monitor and test networks	Access logs	Enable and maintain logs to track access to network resources and cardholder data.
	Vulnerability scans	Perform regular scans to identify vulnerabilities.
	Penetration testing	Carry out penetration tests to identify weaknesses in security controls.
Access control measures	Unique IDs	Ensure that each person with access has a unique ID.
	Physical access control	Limit and monitor physical access to systems that handle cardholder data.
Regularly update and patch system	Software updates	Regularly update all software to protect against known vulnerabilities.
	Security patches	Install critical security patches within a defined period.
Information security policy	Policy development	Develop, maintain, and disseminate a security policy.
	Policy awareness	Make sure that all staff are aware of the security policy and are trained regularly.
Incident response plan	Plan creation	Create and maintain an incident response plan.
	Plan testing	Regularly test the incident response plan and update it as necessary.

Pro tips for implementing PCI requirements

PCI DSS involves 12 essential requirements. These are described below along with important tips related to them.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Implement controls to deny all traffic unless explicitly needed. Organizations have a hard time identifying outgoing traffic and blocking outbound access since it can create a bottleneck or break the process of external traffic. Use an outbound proxy to monitor and lock down your outgoing traffic.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Disable unnecessary services and protocols, and configure system security parameters to defend against attacks. Diligently test, document and allow only necessary services, ports and protocols.

Organizations that do not invest in the necessary initial research end up with an increased attack surface because they are hesitant to shut down any additional services, ports, and protocols, fearing that it may adversely impact regular operations. Build a culture of security by design as opposed to security being an afterthought. 

Requirement 3: Protect stored cardholder data

Limit storage amount and retention time while implementing cryptographic key management processes. Restrict access to sensitive data information based on the principle of least privilege. Tokenize, encrypt, and obfuscate information wherever possible.

Requirement 4: Encrypt the transmission of cardholder data across open, public networks

PCI DSS requires the use of strong encryption algorithms (e.g., AES-128 or higher) for encrypting data at rest. TLS 1.2 or higher should be used for encrypting data in transit. Encryption keys should be securely managed and rotated at least annually. 

Requirement 5: Protect all systems against malware and regularly update antivirus software or programs

Ensure that findings from the anti-malware solution are continuously monitored and policies are tweaked as required.

Requirement 6: Develop and maintain secure systems and applications

Establish a secure development lifecycle, and perform code reviews and vulnerability assessments. Ensure that secure SDLC requirements are understood, acknowledged, and adopted by your development team within iterative CI/CD processes. 

To bake security into the development lifecycle, conduct threat modeling to identify potential attack paths and run static code analysis and dynamic application testing to identify, track, and remediate vulnerabilities and security misconfigurations before code is deployed to production. 

Requirement 7: Restrict access to cardholder data based on the need-to-know principle

Clearly define roles and privileges within your organization before allowing anyone access to your cardholder environment. 

Use authentication technologies and firewall restrictions to limit movement and log user access. Conduct frequent audits of user activities and existing permissions to remove unnecessary access.

Requirement 8: Identify and authenticate access to system components

Implement multi-factor authentication and ensure proper user identification and authentication management. Avoid insecure authentication protocols such as SMS that can potentially be bypassed by threat actors.

Requirement 9: Restrict physical access to cardholder data

Do not store paper copies of credit card information, and ensure that the proper levels of physical access are applied i.e. to those who absolutely need it.

Requirement 10: Track and monitor all access to network resources and cardholder data

Implement a centralized logging and monitoring solution to consolidate, centralize, and monitor logs for anomalous security patterns. Ensure that these logs capture the necessary details to identify activity details, locations, and root causes. PCI DSS mandates that these logs be retained for at least one year in case of potential future investigations.

Requirement 11: Regularly test security systems and processes

Run internal and external network vulnerability scans, and perform penetration testing and intrusion detection. Run authenticated vulnerability scans on an automated basis and manual penetration testing exercises at least annually. A good mix of automated and manual tests will ensure that security probes are run consistently.

Requirement 12: Maintain a policy that addresses information security for all personnel

Conduct focused training for your IT and development team on the latest security best practices and technologies, as they have more direct interactions with sensitive financial data.

Final thoughts

PCI DSS compliance extends beyond simply passing an audit. Remember that compliance is not a one-time event but an ongoing commitment to data security and organizational integrity. By taking a proactive step in identifying requirements and prioritizing compliance, organizations can earn the trust of stakeholders and clients and avoid noncompliance penalties.

Identifying the assets associated with applications involved in processing credit card transactions is a complex task. Use automation technology to discover IT assets like databases, network ports, middleware technologies, storage systems, and public cloud services to ensure a comprehensive asset inventory. Employ automated dependency mapping to identify assets supporting the critical applications that collect credit card information. Vendors like Device42 focus on the compliance use case and partner with value-added resellers who can implement asset discovery and application mapping. 

Once you’re done, be sure to celebrate your success in passing a PCI audit! However, always remember that you’re dealing with very sensitive data that is a prime target for threat actors. Passing the compliance audit ensures that you have met the minimum security requirements for protection, but always be on the lookout for new attack vectors and explore opportunities for minimizing the attack surface through masking and tokenization of sensitive data. The root causes of most cyber incidents are usually human error, negligence, or a lack of awareness. Please do your best to ensure that your organization does not hit the headlines for any of the wrong reasons.