The Payment Card Industry Data Security Standard (PCI DSS) are commonly followed by organizations that handle credit card transactions to ensure the security of cardholder data. Since standards and requirements can change over time, it’s essential to refer to the most recent version of the PCI DSS v4.0 standard for the most up-to-date information and to answer the question of, why do I need to be PCI compliant?
PCI DSS v4.0 was updated in April 2022. The description of the updated change from PCI DSS v3.2.1 to PCI DSS v4.0 states:
"For details of PCI DSS changes, see PCI DSS - Summary of Changes from PCI DSS Version 3.2.1 to 4.0. Rearranged, retitled, and expanded information in the "Completing the Self-Assessment Questionnaire" section (previously titled "Before You Begin"). Aligned content in Sections 1 and 3 of Attestation of Compliance (AOC) with PCI DSS v4.0 Report on Compliance AOC. Added PCI DSS v4.0 requirements. Added appendices to support new reporting responses."
To answer the question ‘Why do I need to be PCI compliant,’ we have broken down the PCI DSS Compliance Guide v4.0 for easy understanding.
4 Continual Steps To Protect Payment Data
There are four ongoing steps to protecting payment account data with PCI DSS:
- Assess - identifying all locations of payment account data, taking an inventory of all IT assets and business processes associated with payment processing, analyzing them for vulnerabilities that could expose payment account data, implementing or updating necessary controls, and undergoing a formal PCI DSS assessment.
- Remediate - identifying and addressing any gaps in security controls, fixing identified vulnerabilities, securely removing any unnecessary payment data storage, and implementing secure business processes.
- Report - documenting assessment and remediation details, and submitting compliance reports to the compliance-accepting entity (typically, an acquiring bank or payment brands).
- Monitor and Maintain - confirming that security controls put in place to secure the payment account data and environment continue to function effectively and properly throughout the year. These "business as usual" processes should be implemented as part of an entity's overall security strategy to help ensure protection on an ongoing basis.
PCI SSC Standards
The PCI Security Standards improve payment security by introducing a formidable framework of all-encompassing security control prerequisites, evaluation methodologies, and ancillary reference materials. These standards delineate security controls and procedural protocols applicable to entities engaged within the payment ecosystem, while also establishing stringent criteria for developers and solution providers to construct and adeptly oversee payment devices, software, and solutions within the domain of the payment industry, ensuring heightened security.
A brief description of PCI Security Standards (PCI SSC) are provided below
PCI Data Security Standard - An actionable framework for developing a robust payment account data security process, including prevention, detection, and appropriate reaction to security incidents.
PIN Transaction Security (PTS) - Security requirements focused on characteristics and management of devices used in the protection of cardholder PINs (personal identification numbers) and other sensitive payment data.
Software Security Framework - A collection of standards and programs for the secure design, development, and maintenance of existing and future payment software.
Point-to-Point Encryption (P2PE) - A comprehensive set of security requirements for validation of P2PE solutions, to protect payment account data via encryption from where it is captured in the payment terminal until it is decrypted in the solution provider's environment.
Mobile Standards - Includes the Contactless Payments on COTS (CPoC) and Software-based PIN Entry on COTS (SPoC) standards for mobile payment-acceptance solutions on commercial-off-the-shelf (COTS) devices in a merchant-attended environment.
Other Standards - Other PCI Standards define controls and testing requirements for PIN security, physical and logical card production and provisioning, token service providers, and access security (3-D Secure).
PCI DSS 12 Requirements and Goals
PCI DSS was formulated with the objective of promoting and elevating the security of payment account data while fostering the widespread adoption of uniform data security measures on a global scale. PCI DSS provides a baseline of technical and operational requirements designed to protect payment account data.
GOALS REQUIREMENTS
Build and Maintain a
Secure Network and
Systems1. Install and maintain network security controls
Build and Maintain a
Secure Network and
Systems2. Apply secure configurations to all system components
Protect Account Data 3. Protect stored account data
Protect Account Data 4. Protect cardholder data with strong cryptography during
transmission over open, public networks
Maintain a Vulnerability
Management Program5. Protect all systems and networks from malicious software
Maintain a Vulnerability
Management Program6. Develop and maintain secure systems and software
Implement Strong Access
Control Measures7. Restrict access to system components and cardholder data by business need to know
Implement Strong Access
Control Measures8. Identify users and authenticate access to system components
Implement Strong Access
Control Measures9. Restrict physical access to cardholder data
Regularly Monitor and Test
Networks10. Log and monitor all access to system components and
cardholder data
Regularly Monitor and Test
Networks11. Test security of systems and networks regularly
Maintain an Information
Security Policy12. Support information security with organizational policies and programs
PCI DSS Implementation Strategies
PCI DSS implementation strategies vary depending on the company's level of risk and the requirements of the standard. Here are the 3 different approaches:
Defined Approach: This is the traditional method for implementing and validating PCI DSS. Entities follow the requirements and testing procedures in PCI DSS, implementing security controls to meet those requirements. If an entity already complies with PCI DSS and is comfortable with its approach, there’s no need for change. It’s helpful for those new to PCI DSS or seeking clear guidance.
Compensating Controls: These are an option within the Defined Approach for entities facing documented constraints preventing them from meeting specific requirements. They implement alternative controls to effectively mitigate the associated risks. This is often used for legacy systems or processes that can’t be updated.
Customized Approach: This approach allows entities to meet Customized Approach Objectives in a way that doesn’t strictly adhere to defined requirements, offering flexibility for innovative or tech-savvy approaches. For instance, organizations might combine legacy vulnerability scanning with advanced techniques like User and Entity Behavior Analytics (UEBA) or AI-based methods to detect complex threats in the Cardholder Data Environment (CDE). It’s suited for those embracing modern security solutions.
Prioritizing PCI DSS Milestones
The Prioritized Approach for PCI DSS compliance consists of six milestones. The subsequent table provides a concise overview of the primary objectives for each milestone.
| Milestones | Goals |
|---|---|
| 1 | Do not store sensitive authentication data and limit cardholder data retention. This milestone targets a key area of risk for entities that have been compromised. Remember – if sensitive authentication data and other account data are not stored, the effects of a compromise will be greatly reduced. If you don’t need it, don’t store it. |
| 2 | Protect systems and networks and be prepared to respond to a system breach. This milestone targets controls for points of access to most compromises and the response processes |
| 3 | Secure payment applications. This milestone targets controls for applications, application processes, and application servers. Weaknesses in these areas are easy prey for compromising systems and obtaining access to cardholder data |
| 4 | Monitor and control access to your systems. Controls for this milestone allow you to detect the who, what, when, and how concerning access to your network and cardholder data environment |
| 5 | Protect stored cardholder data. For those organizations that have analyzed their business processes and determined that they must store Primary Account Numbers, this milestone targets key protection mechanisms for the stored data |
| 6 | Complete remaining compliance efforts, and ensure all controls are in place. This milestone completes PCI DSS requirements and finishes all remaining related policies, procedures, and processes needed to protect the cardholder data environment |
General Changes to PCI DSS Requirements
The list is from the Payment Card Industry Data Security Standard document ‘Summary of Changes from PCI DSS Version 3.2.1 to 4.0’Revision 2 on December 2022
| General Changes Implemented Throughout PCI DSS Requirements | Change Type |
|---|---|
| Reformatted overview sections and added a summary of the sections to the beginning of each principal requirement. | Structure or format |
| Updated overview sections and added guidance at the start of each requirement section. | Clarification or guidance |
| Added numbered requirement description headings throughout each requirement to organize and describe the requirements that fall under it. | Structure or format |
| Renumbered requirements and testing procedures and reorganized requirements due to the addition of numbered requirement description headings | Structure or format |
| Rephrased directive requirements to be objective. | Evolving requirement |
| Moved examples from requirements or testing procedures into the guidance column. | Structure or format |
| Removed references to sampling from testing procedures. | Clarification or guidance |
| Shortened testing procedures by clarifying testing is to be done “in accordance with all elements specified in this requirement” to minimize redundancy between requirements and testing procedures. | Clarification or guidance |
| Updated language in requirements and/or corresponding testing procedures for alignment and consistency. | Clarification or guidance |
| Enhanced testing procedures to clarify level of validation expected for each requirement. | Clarification or guidance |
| Reformatted requirements and testing procedures and made minor wording changes for readability – for example, content from paragraphs reformatted to bullet points. | Structure or format |
| Combined requirements that support the same intent and separated requirements that support different intents. | Structure or format |
| Separated complex requirements / testing procedures and removed redundant or overlapping testing procedures | Structure or format |
| Moved required elements that were included only in testing procedures to requirements, to clarify the requirement and to facilitate shortening of the testing procedures. | Clarification or guidance |
| Moved and reworded policies and procedures requirements from the end to the beginning of each principal requirement | Structure or format |
| Removed notes about SSSL/Early TLSSL/Early TLS from the guidance columns for requirements that referenced those specific protocols. | Clarification or guidance |
| Changed “cardholder data” to “account data” as needed to align with usage and intent. | Clarification or guidance |
| Changed terminology used to refer to frequency throughout the requirements in accordance with Description of Timeframes Used in PCI DSS Requirements. | Clarification or guidance |
| Added titles and reorganized content of the guidance column to aid understanding and merge similar information. | Structure or format |
PCI DSS Remediation
Upon the release of PCI DSS v4.0 in March 2022, a fresh reporting option was introduced to record requirements labeled as “In Place with Remediation.” The intent behind this addition was to encourage a persistent focus on security, offering organizations a mechanism to pinpoint areas requiring enhancement on an annual basis.
PCI DSS Requirement 2: Apply Secure Configurations to All System Components focuses on ensuring that organizations change default passwords and other security parameters before deploying new systems or devices into their network. It emphasizes the need for strong, unique passwords and secure configurations to protect cardholder data. Additionally, organizations must maintain an inventory of all system components and conduct regular vulnerability assessments to identify and address security weaknesses.
You can find the entire document for the PCI DSS Summary of Changes from v3.2.1 to v4.0 – Dec 2022 here.
