...

PCI DSS: Home

PCI Security Standards Council

Objective

The PCI DSS v4.0 (Mar 2022) is an overwhelming document of 360 pages. In this blog series, we will break it down into bite-sized chunks and try to understand what it is, why it matters and how to become PCI DSS compliant.

  • To simplify the Payment Card Industry Data Security Standard for new learners
  • To guide organizations in need
  • To showcase the skills in the house

History

Source: Wikipedia
The major card brands had five different security programs:

  • Visa’s Cardholder Information Security Program
  • Mastercard’s Site Data Protection
  • American Express’s Data Security Operating Policy
  • Discover’s Information Security and Compliance
  • JCB’s Data Security Program

The intentions of each were roughly similar: to create an additional level of protection for card issuers by ensuring that merchants meet minimum levels of security when they store, process, and transmit cardholder data. To address interoperability problems among the existing standards, the combined effort by the principal credit-card organizations resulted in the release of version 1.0 of PCI DSS in December 2004. PCI DSS has been implemented and followed worldwide. The latest version is PCI DSS v4.0 which was released in March 2022.

Penalties for Non-Compliance

The PCI DSS is a standard rather than a law, and it’s enforced through contracts between merchants, acquiring banks that process payment card transactions and the payment brands.

As a result, the way penalties work differs from many other data protection regulations.

Notably, the standard doesn’t simply levy a one-off fine for non-compliance. Instead, organizations can be penalized between $5,000 and $100,000 a month until they achieve compliance.

PCI DSS Breakdown

Build and Maintain a Secure Network and Systems
Protect Account Data
Maintain a Vulnerability Management Program
Implement Strong Access Control Measures
Regularly Monitor and Test Networks
Maintain an Information Security Policy
Additional Requirements

Important Terms, Abbreviations, and Acronyms

Account Data

Account data consists of cardholder data and/or sensitive authentication data.

Cardholder Data (CHD)

At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code.

Sensitive Authentication Data (SAD)

Security-related information used to authenticate cardholders and/or authorize payment card transactions. This information includes, but is not limited to, card validation verification codes/values, full track data (from magnetic stripe or equivalent on a chip), PINs, and PIN blocks.

Cardholder Data Environment (CDE)

The CDE is comprised of:

  • The system components, people, and processes that store, process, or transmit cardholder data 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.
Applicability

PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE). This includes all entities involved in payment card account processing including merchants, processors, acquirers, issuers, and other service providers.

Validated Software

Payment software listed on the PCI SSC website as a Validated Payment Application (PA-DSS) or Validated Payment Software (the Secure Software Standard) has been evaluated by a qualified assessor to confirm the software meets the security requirements within that standard.

Validated Software Vendors

The Secure SLC Standard defines security requirements for software vendors to integrate secure software development practices throughout the entire software lifecycle.

Segmentation

Segmentation (or isolation) of the CDE from the remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly recommended as a method that may reduce the:

  • Scope of the PCI DSS assessment
  • Cost of the PCI DSS assessment
  • Cost and difficulty of implementing and maintaining PCI DSS controls
  • Risk to an organization relative to payment card account data (reduced by consolidating that data into fewer, more controlled locations)
Encryption

Encryption of cardholder data with strong cryptography is an acceptable method of rendering the data unreadable according to PCI DSS requirements. However, encryption alone is generally insufficient to render the cardholder data out of scope for PCI DSS and does not remove the need for PCI DSS in that environment. The entity’s environment is still in scope for PCI DSS due to the presence of cardholder data.

Third-Party Service Providers (TPSP)

Where a third-party service provider (TPSP) receives and/or stores only data encrypted by another entity, and where they do not have the ability to decrypt the data, the TPSP may be able to consider the encrypted data out of scope if certain conditions are met. This is because responsibility for the data generally remains with the entity, or entities, with the ability to decrypt the data or impact the security of the encrypted data. Determining which party is responsible for specific PCI DSS controls will depend on several factors, including who has access to the decryption keys, the role performed by each party, and the agreement between parties. Responsibilities should be clearly defined and documented to ensure both the TPSP and the entity providing the encrypted data understand which entity is responsible for which security controls.

Business-as-Usual Processes

Some PCI DSS requirements are intended to act as BAU processes by monitoring security controls to ensure their effectiveness on an ongoing basis. This oversight by the entity assists with providing reasonable assurance that the compliance of its environment is preserved between PCI DSS assessments. While there are currently some BAU requirements defined within the standard, an entity should adopt additional BAU processes specific to their organization and environment when possible. BAU processes are a way to verify that automated and manual controls are performing as expected. Regardless of whether a PCI DSS requirement is automated or manual, it is important for BAU processes to detect anomalies, and alert and report so that responsible individuals address the situation in a timely manner.

Sampling

While sampling allows assessors to test less than 100% of a given sampling population, assessors should always strive for the most complete review possible. Assessors are encouraged to use automated processes or other mechanisms if the complete population, regardless of size, can be tested quickly and efficiently with minimal impact on the resources of the entity being assessed. Where automated processes are not available to test 100% of a population, sampling is an equally acceptable approach.

Timeframes

Certain PCI DSS requirements have been established with specific timeframes for activities that need to be performed consistently via a regularly scheduled and repeatable process. The intent is that the activity is performed at an interval as close to that timeframe as possible without exceeding it. The entity has the discretion to perform an activity more often than specified (for example, performing an activity monthly where the PCI DSS requirement specifies it be performed every three months).

Assessment Process

The PCI DSS assessment process includes the following high-level steps:

  • Confirm the scope of the PCI DSS assessment.
  • Perform the PCI DSS assessment of the environment.
  • Complete the applicable report for the assessment according to PCI DSS guidance and instructions.
  • Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Official Attestations of Compliance are only available on the PCI SSC website.
  • Submit the applicable PCI SSC documentation and the Attestation of Compliance, along with any other requested documentation such as ASV scan reports to the requesting organization (those that manage compliance programs such as payment brands and acquirers (for merchants), or other requesters (for service providers)).
  • If required, perform remediation to address requirements that are not in place and provide an updated report.

Resources

Scroll to Top
Seraphinite AcceleratorOptimized by Seraphinite Accelerator
Turns on site high speed to be attractive for people and search engines.