PCI DSS: Definition, 12 Requirements, and Compliance
In light of recent high-profile data breaches, costly hacking incidents, and reports of deficient cybersecurity, customers have a right to be weary. The sheer amount of personally identifiable information now stored in databases and in the cloud poses substantial risks to consumers concerned about the privacy of their data. All these factors and more are pushing data security to the forefront for modern business, especially those in the financial industry.
Creating safe payment networks that allow consumers to easily make payment card transactions without risking the privacy of their personal data is a critical part of financial data security. PCI DSS was designed to address these concerns by imposing requirements to safeguard credit and debit card information. These requirements have spurred improvements in information security around the world.
What is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is an established information security standard which applies to any organization involved in the processing, transmission, and storage of credit card information. Created and overseen by an independent agency, the PCI Security Standards Council (PCI SSC), PCI DSS is designed to improve the security of payment card transactions and to reduce credit card fraud.
The PCI SSC was founded in 2006 as a joint venture between the five largest payment card brands (Visa, MasterCard, American Express, Discover, and JCB). Its goal was to create a clear and interoperable set of standards for protecting consumer information. Although the SSC does not enforce compliance itself, the PCI DSS is now widely accepted and applies to all organizations dealing with credit, debit, or cash card information, regardless of size or industry.
Some key terms come into play when discussing PCI DSS:
- A merchant is any business or individual that accepts payment through a branded card provided by the five major payment card companies. Regardless of whether a physical card is used or the consumer merely provides the necessary cardholder information to pay for goods or services, the entity accepting payment is considered a merchant.
- A service provider is any business that stores, processes, or transmits cardholder data on behalf of another business or individual. Service providers can be considered middlemen, providing various payment-related services to merchants. Businesses like telecommunication companies may be considered both merchants and service providers because they both receive payment directly (for providing internet access) while also enabling payment (by transmitting cardholder information over the internet).
- PA-DSS stands for Payment Application Data Security Standard. It is a complementary standard created to ensure that vendors and service providers adopt policies which make it easier for merchants to comply with PCI DSS requirements. The two standards are distinct, but PA DSS is designed to support the enforcement of PCI DSS.
The 12 PCI DSS requirements
PCI DSS consists of twelve requirements, organized under six major objectives delineated by the PCI SSC. Every requirement is a specific common sense security step that helps businesses satisfy the relevant objective. The objectives and associated requirements are as follows:
- Build and maintain a secure network
- Install and maintain a firewall configuration to protect cardholder data
- Do not use vendor-supplied defaults for system passwords and other security parameters
- Protect cardholder data
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open, public networks
- Maintain a vulnerability management program
- Use and regularly update anti-virus software or programs
- Develop and maintain secure systems and applications
- Implement strong access control measures
- Restrict access to cardholder data by business need to know
- Assign a unique ID to each person with computer access
- Regularly monitor and test networks
- Restrict physical access to cardholder data
- Track and monitor all access to network resources and cardholder data
- Maintain an information security policy
- Regularly test security systems and processes
- Maintain a policy that addresses information security for all personnel
Understanding PCI DSS compliance levels
There are four PCI DSS compliance levels that categorize merchants by the volume of transactions they process each year. As larger merchants are responsible for more individual transactions, they also represent bigger targets and potentially expose more people to risk. As a result, the compliance levels for higher transaction volumes correspond to more stringent compliance requirements.
Every compliance level involves some permutation of just four specific requirements. The Self-Assessment Questionnaire (SAQ), vulnerability scan, Attestation of Compliance (AOC), and Report on Compliance (ROC) are all procedures used by third-party assessors or by businesses themselves to assess PCI DSS compliance.
Self-Assessment Questionnaire (SAQ)
The SAQ consists of a variety of yes or no questions that are intended to evaluate whether an entity is complying with PCI DSS. It must be completed by all merchants who do not require a Report on Compliance.
A variety of questionnaires exist, so merchants and service providers must determine which of the specific forms applies to them before completing the SAQ. This selection is primarily based on how the business accepts and processes card payments. For example, merchants who use online payment applications but do not store cardholder data should fill out SAQ-C specifically. Businesses can use the resources on the PCI website to make sure they pick the correct SAQ form.
Depending on the specific questionnaire used, the SAQ can vary in size from about 20 to over 300 questions. Merchants should answer the questions on the SAQ carefully and candidly to correctly determine whether they are complying with PCI DSS.
A vulnerability scan is an external scan of a merchant or service provider’s public internet and consumer-facing payment applications and portals. These scans are performed by an Approved Scanning Vendor (ASV) appointed by the PCI SSC to evaluate compliance with PCI DSS at a practical level.
ASVs use a remote tool to detect any vulnerabilities or data security risks in the scanned organization’s systems. These scans must be performed on a quarterly basis (once every 90 days).
Almost all merchants must undergo a scan, regardless of applicable compliance level. However, some merchants who complete an SAQ might be exempt, based on the same subclassification used to select the appropriate SAQ form. Specifically, entities qualifying for SAQ A-EP, B-IP, C, and D (merchant or service provider) are all obligated to pass the vulnerability scan requirement while SAQ A, B, C-VT, and PEPE-HW are not.
Attestation of Compliance (AOC)
The AOC requirement applies to all merchants seeking to adhere to PCI DSS, regardless of compliance level. This document is signed and submitted by the merchant or service provider if they are completeing their own questionnaire, or by an assessor in the case of merchants with the Report on Compliance requirement.
There is one version of the AOC for each type of SAQ form. A merchant completing an SAQ ‘A’ questionnaire should then use the corresponding AOC ‘A’ document, for example.
The AOC is simply a declaration of the final results of any PCI DSS assessment. The document ultimately serves as evidence of PCI DSS compliance.
Report on Compliance (ROC)
Unlike the SAQ, a ROC is completed by a Qualified Security Assessor (QSA), rather than the merchant. QSAs, like scanning vendors, are third parties approved by the PCI SCC to independently assess PCI DSS compliance.
After completion, the QSA submits the report directly to the assessed merchant’s bank. ROCs are required of only the largest, highest-risk merchants and vendors. They are a more stringent equivalent to the self-reporting questionnaires completed at other compliance levels.
The need for PCI DSS compliance in the cloud
As businesses — like established merchants and most large service providers — continue to move from on-premises systems to the cloud, data security in general has become an increasing concern. E-commerce and online financial services are booming alongside a rise in more sophisticated online fraud and hacking practices, a dangerous combination.
Standards like PCI DSS are more important than ever for protecting these businesses’ consumers and their private data. Designed around modern data privacy concerns, PCI DSS have become critical and established guidelines for enterprises dealing with more and more payment data in the cloud.
The importance of PCI DSS compliance
PCI DSS is a voluntary standard, and it is not enshrined in law by any agency or government. Nevertheless, it has been widely adopted, and there are significant potential penalties for merchants and service providers who fail to comply with its requirements.
Monetary penalties include significant fines and costs borne by the merchant. These fines and increased transaction fees are usually applied by banks, but businesses shirking PCI DSS compliance also expose themselves to potential punitive action and litigation by the government, individuals, and other entities.
Non-monetary penalties include forced audits and monitoring, imposed by the major card brands on non-compliant merchants and service providers. This negatively affects public relations and costs the enterprise significant time and resources.
Talend provides a comprehensive suite of apps focused on data integration and data integrity that can help simplify the task of PCI DSS compliance for businesses of any size. With unique offerings like restricted business user access to cardholder data, Talend Data Fabric can better manage your customers data and inspire confidence in your payment networks. Try Talend Data Fabric today to safeguard your trusted data.
Ready to get started with Talend?
More related articles
- Pillars to GDPR Success (2 of 5): Data Capture and Integration
- Pillars to GDPR Success (4 of 5): Self-Service Curation and Certification
- Pillars to GDPR Success (3 of 5): Anonymize and Pseudonymize for Data Protection with Data Masking
- Pillars to GDPR Success (5 of 5): Data Access and Portability
- Preparing for GDPR
- [GDPR Step 14] How to Govern the Lifecycle of Information
- Pillars to GDPR Success (1 of 5): Data Classification and Lineage
- [GDPR Step 15] How to Set Up Data Sharing Agreements
- [GDPR Step 16] How to Enforce Compliance with Controls
- [GDPR Step 13] How to Manage End-User Computing
- [GDPR Step 11] How to Stitch Data Lineage
- [GDPR Step 09] How to Conduct Vendor Risk Assessments
- [GDPR Step 12] How to Govern Analytical Models
- [GDPR Step 10] How to Improve Data Quality
- [GDPR Step 08] How to Conduct Data Protection Impact Assessments
- [GDPR Step 07] How to Establish Data Masking Standards
- [GDPR Step 3] How to Confirm Data Owners
- [GDPR Step 06] How to Define Acceptable Use Standards for GDPR
- [GDPR Step 2] The Importance of Creating Data Taxonomy
- [GDPR Step 4] How to Identify Critical Datasets and Critical Data Elements
- What is Data Portability?
- [GDPR Step 01] How to Develop Policies, Standards, and Controls
- What is Data Privacy?
- [GDPR Step 5] How to Establish Data Collection Standards