Version 3.2.1 of the PCI DSS standard, which was created to ensure the security of credit card data used in financial transactions, expired on March 31, 2024 and was replaced by version 4.0. Change in PCI DSS version; It covers all sectors that accept payment by payment cards, such as stores, businesses, and e-commerce sites. With the new version, the audits of version 3.2.1 have ended as of March 31, but the audits performed before this date are still valid. Version 4.0 uses methods adapted to changing threats, making security a continuous process and providing greater flexibility for organizations to achieve their security goals. In this article, we touch upon the controls that must be implemented according to the PCI DSS standard.
Vendor vs Service Provider
For purposes of the PCI DSS, a Merchant is defined as any entity that accepts payment cards bearing the logo of any of the five members of the PCI SSC (American Express, Discover, JCB, MasterCard or Visa) for the purpose of payment for goods and/or services. It is important to note that a merchant that accepts payment cards as payment for goods and/or services may also be a service provider if the services sold result in the storage, processing or transmission of cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but it is also a service provider if it hosts merchants as customers.
Service Provider is a commercial organization that is not a payment brand and is directly involved in the processing, storage or transmission of cardholder data on behalf of another organization. This includes companies that control or provide services that may affect the security of cardholder data. Examples include managed service providers (MSSPs) as well as hosting providers and other entities that provide managed firewalls, IDS, and other services. If an entity provides a service that involves only providing public network access (for example, a telecommunications company that only provides communications connectivity), that entity will not be considered a service provider under PCI DSS, although it may be considered a service provider for other services.
While merchants often consider the service/solution provider responsible for compliance, any merchant that accepts payment cards is responsible for, at a minimum, monitoring their service provider's compliance and responsibilities with requirement 12.8 and having an incident response plan in accordance with requirement 12.10.1. Unless the merchant completely outsources all card processing to a third party, it will have applicable PCI DSS requirements to implement.
Business Levels
Tier 1 merchants process more than 6 million transactions annually across all channels.
Level 2 merchants process between 1 million and 6 million transactions per year across all channels.
Level 3 businesses process between 20,000 and 1 million online transactions per year.
Level 4 merchants process fewer than 20,000 online transactions per year, or fewer than 1 million transactions per year overall.
Control Types
Any business that processes, stores or transmits cardholder data must comply with the framework and undergo an annual PCI DSS assessment to verify compliance.
The nature of the assessment ranges from a Self-Assessment (SAQ) to a full PCI DSS audit performed on-site by a Qualified Security Assessor.
There are three main parts to a PCI DSS assessment:
- Self-Assessment Questionnaire (PCI SAQ- Self-Assessment Questionnaire)
- Attestation of Compliance (PCI AoC)
- Compliance Report (PCI RoC- Report on Compliance)
Business Level | SAQ | AoC | RoC |
1 | Not typically required | Required (accompanies RoC) | Required (Annual on-site assessment by a QSA. |
2 | Required (Annually) | Required (With SAQ) | Not usually required |
3 | Required (Annually) | Required (With SAQ) | Not usually required |
4 | Required (Annually, type varies based on payment environment) | Required (With SAQ) | Not usually required |
SAQ TYPES
A | It is for companies that outsource the processing of cardholder data entirely to a third party. These include e-commerce stores, telemarketing, and mail order companies. SAQ A can only be used if a company does not store, process or transmit cardholder data on its own systems or facilities. Does not apply to face-to-face channels. |
A-EP |
The e-commerce business does not store, process or transmit cardholder data in its systems. SAQ A-EP is superficially similar to SAQ A; Both apply to e-commerce businesses that outsource the payment process. The critical difference is the flow of cardholder data from the merchant to the payment processor and who collects that data. SAQ A may be eligible if cardholder data is collected by the payment processor. For example, your site directs customers to a page on the payment provider's site to enter information or displays the provider's page in an iframe. By contrast, if your store collects cardholder data through an on-site form and then sends it to the payment processor via JavaScript code or another tool, SAQ A-EP may be appropriate. |
B | SAQ B is for merchants who use POS devices or terminals to collect credit card data. The merchant does not store or process cardholder data. SAQ B does not apply to e-commerce channels and is not relevant to most other credit card transactions that occur solely on the web. |
B-IP | SAQ B-IP is a variation of SAQ B that applies to merchants using PTS certified terminals with IP connectivity to the payment provider. SAQ B-IP does not apply to most businesses that conduct electronic transactions over the web. |
C | Applicable to merchants using cardless credit card payments via phone or mail and card payments via point-of-sale terminals. The merchant does not store cardholder data electronically but may have paper records. It is not relevant to e-commerce businesses. SAQ C applies if the business does not store cardholder data electronically, but transmits that data to a payment processor through a payment application system and internet connection on the same device or LAN that is not connected to its other systems. |
C-VT | For businesses that manually enter one transaction at a time via the interface (keyboard) into a virtual terminal solution on an Internet-based device provided and hosted by a PCI DSS-approved third-party service provider and used solely for credit card transactions. Electronic card holder data is not stored. It does not apply to e-commerce channels. |
P2PE-HW | For businesses using only verified, PCI SSC certified P2PE (point-to-point encryption) hardware payment terminals without electronic cardholder data storage, managed through this solution. It does not apply to e-commerce channels. |
D | SAQ D for Vendors: All vendors not included in the descriptions of SAQ types above. SAQ D for Service Providers: All service providers identified by a payment brand as eligible to complete the SAQ. While only Vendors can use narrowed-down SAQs, Service Providers must always use the proprietary service provider version of SAQ D, even if they meet all other criteria for a narrowed-down SAQ. |
What is PCI SAQ SPOC?
The PCI DSS 4.0 transition deadline of April 1, 2024 has arrived and an accompanying new type of reduced-scope self-assessment survey, SAQ SPoC, is now on the agenda. If businesses accept payment cards through a device connected to a smartphone or tablet, then this SAQ must be used.
SPoC is the abbreviation of Software-based PIN entry on COTS. In COTS, it stands for software-based PIN entry via off-the-shelf commercial products. This refers to Secure Card Reader-PIN (SCRP) devices that connect to commercial off-the-shelf (COTS) devices—special types of card-reading devices used with a device such as a tablet or smartphone. There are few requirements for merchants using SPoC devices, but they must still be met.
For multiple payment channels, it may be possible for a merchant to complete a different SAQ for each payment channel or to use a single SAQ (D) that addresses all requirements of all channels combined. If different SAQs are used, each channel must meet the eligibility criteria for the relevant SAQ and sufficient network segmentation must be in place to isolate the different channels. Merchants with multiple payment channels should use SAQ D even if they have a SPoC solution. Findings from all SAQs can then be combined into SAQ Ds.
While SAQ P2PE is the standard for minimizing the scope of card transactions, there is one additional requirement in SAQ SPoC that is not in SAQ P2PE, and that relates to passwords on the COTS device. The remaining requirements in both SAQ SPoC and SAQ P2PE relate to monitoring devices for tampering, monitoring and management of third-party service providers, Incident Response, and handling of paper records (which most vendors do not have).
The qualification criteria for a vendor to use SAQ SPoC are:
- All payment transactions are processed only through a payment channel where the card is present.
- All cardholder data entry is done through a SCRP that is part of a validated SPoC solution approved and listed by the PCI SSC;
- The only systems that store, process, or transmit account data in the merchant's SPoC environment are those used as part of a validated SPoC solution approved and listed by the PCI SSC;
- Merchant does not receive, transmit or store account data electronically;
- This payment channel is not connected to any other system/network in the merchant environment;
- Any account data the seller may retain is on paper (e.g., printed reports or receipts) and is not received electronically;
- Vendor has implemented all controls in the SPoC user guide provided by the SPoC Solution Provider.
What is PCI AOC?
PCI Attestation of Compliance (AoC) is a documented confirmation of an organization's adherence to PCI DSS standards. After completing a Self-Assessment Survey, the organization completes the relevant version of the AoC to verify the accuracy of the self-assessment and compliance status.
Like SAQ, AoC has multiple versions. Organizations complete the AoC corresponding to the specific SAQ they have completed.
While Level 2-4 merchants may complete their own AoC, they may choose to have it verified or guided by an experienced PCI DSS professional. For Tier 1 vendors, a QSA typically verifies compliances and prepares the Compliance Report.
What is PCI RoC?
A PCI Compliance Report (RoC) is a comprehensive document prepared by a QSA that evaluates an organization's systems, security measures, and protection of cardholder data. Required for Level 1 sellers.
QSA examines and documents controls through a comprehensive on-site inspection. The evaluation results in a summarized findings report and final RoC.
Each RoC must comply with PCI SSC's RoC Reporting Template.
In conclusion;
The new security measures that come with PCI DSS version 4.0 are an updated and more comprehensive standard to protect the security of payment card information against changing and evolving threats. It is important that institutions and organizations take the necessary steps to comply with the new standard and make continuous efforts to maintain their compliance.
There are some important benefits brought by PCI DSS V4.0. Provides stronger authentication and data security controls, helping protect cardholder data. At the same time, with its risk-focused approach, it helps organizations focus on protecting their most critical assets. Along with these, it provides more flexibility. It suggests different compliance methods, allowing organizations to choose the solution that best suits their needs.
This document provides general information about the key elements of PCI DSS 4.0 and the changes affecting businesses. For more detailed information, you can refer to the following sources:
