American Express issued the first plastic credit card in 1959. And while individual banks had established their own various security standards along the way, it wasn’t until December 2004, nearly 55 years after the cardboard Diner’s Club card debuted in 1950, that an industry-level standard emerged: the Payment Card Industry Data Security Standard (PCI DSS).
Background for PCI DSS
PCI DSS isn’t quite the same as a government regulation—such as GLBA—because violations are not criminal offenses. Rather, the Payment Card Industry Security Standards Council (PCI SSC) is an international trade group that administers the standard, qualifies assessors, and carries out other regulatory activities. PCI DSS is a voluntary certification supported by most of the credit and banking industry, aimed at protecting global payment transactions and account data. PCI certification means that an organization such as a retailer or credit card processor / technology provider has implemented security systems and safeguards to prevent the theft, forgery, or other alteration of digital payments.
Note that the DSS isn’t the only standard or requirements that the PCI SSC has laid out for protecting payments and cardholders, depending on whether your business is a merchant, service provider, manufacturer, or software developer. Of the fifteen standards, a few highlights are:
- PIN Transaction Security (PTS) Requirements is a set of security requirements focused on characteristics and management of devices used in the protection of cardholder PINs and other payment processing related activities.
- Payment Application Data Security Standard (PA-DSS) is for software vendors and others who develop payment applications that store, process, or transmit cardholder data and/or sensitive authentication data as part of authorization or settlement.
- PCI Point-to-Point Encryption Standard (P2PE) provides a comprehensive set of security requirements for P2PE solution providers to validate their P2PE solutions and may help reduce the PCI DSS scope of merchants using such solutions.
Two others are specific to card production and tokenization:
- PCI Card Production Logical Security Requirements and Physical Security Requirements
- PCI Token Service Provider Security (TSP) Requirements
What are the policy requirements for PCI DSS?
DSS v1.0 laid out twelve security and process requirements structured by six control objectives, and four reporting levels based on transaction loads. To bring clarifications and be responsive to evolving technologies and threats, in v4.0 these have been substantively updated to:
- Install and maintain network security controls
- Apply secure configurations to all system components
- Protect stored account data
- Protect cardholder data with strong cryptography during transmission over open, public networks
- Protect all systems and networks from malicious software
- Develop and maintain secure systems and software
- Restrict access to system components and cardholder data by business need to know
- Identify users and authenticate access to system components
- Restrict physical access to cardholder data
- Log and monitor all access to system components and cardholder data
- Test security of systems and networks regularly
- Support information security with organizational policies and programs
To help businesses understand and address these requirements, they are grouped according to guiding principles (objectives) that align to generally accepted best practices for securing any network environment (not just payment systems):
- Build and maintain a secure network and systems (reqs 1 and 2)
- Protect account data (reqs 3 and 4)
- Maintain a vulnerability management program (reqs 5 and 6)
- Implement strong access control measures (reqs 7, 8, and 9)
- Regularly monitor and test networks (reqs 10 and 11)
- Maintain an information security policy (req 12)
Merchants that process transactions must meet an assessment level based on annual business volume, and the “acquiring” bank (e.g., Visa) may put you in a higher category at their discretion. Each level (view here via Mastercard) defines how comprehensive merchant assessments and reporting practices must be, which also impacts the investments needed to comply with the standards:
- Merchant Level 1: >6M transactions
- Merchant Level 2: 1M – 6M transactions
- Merchant Level 3: 20,000 – 1M transactions
- Merchant Level 4: <20,000 transactions
Service providers are also subject to assessments, and must certify at either Level 1, defined as >300,000 transactions, or Level 2, defined as <300,000 transactions.
What are the consequences of non-compliance?
PCI DSS is like ISO and other information security standards in that it confers liability for failures (and fines on the member credit companies which can also be levied against the merchants, reaching as high as $100K per month) but isn’t a legal framework itself—although that doesn’t mean violations won’t result in lawsuits.
Equifax experienced a data breach in 2017 that compromised the data of over 145 million Americans. Among the stolen data were credit card numbers. Those impacted filed claims against the company, resulting in settlements that cost Equifax over $425 million dollars to date.
After Adobe lost credit card numbers and login information of over 38 million Adobe users in 2013, the company dealt with lawsuits from 15 different states and settled for $1 million dollars, in addition to undisclosed settlement amounts.
What’s new in PCI DSS v4.0?
PCI DSS v4.0 was publicly released in March 2022, but doesn’t come into full effect until March 2025. In 2024 v3.2.1 will be deprecated and organizations must start implementing the requirements in v4.0. The change document located here provides details, but updates include everything from minor text clarifications to new guidance on account number encryption. Additionally, more rigor is applied to establishing roles and responsibilities in an organization, defending against malware, cyber response policies, scope, and much more. Given that the last truly comprehensive release was v3.2 in 2016, v4.0 needs your immediate attention.
What data is regulated by PCI DSS?
As technology in the financial services industry has progressed, so has the number and types of data processed. Thus, version 4.0 has expanded to include not just account data and other personal information, but also sensitive authentication data (SAD), administrative access, logs / reviews, certificate management, etc. These gaps have previously been addressed by other information security groups such as the Cloud Security Alliance with the Cloud Control Matrix but codifying them in PCI DSS will put more rigor into merchants’ compliance efforts, particularly since PCI DSS is not dependent on other certifications.
Certain data must never be stored after the completion of a transaction (even if obfuscated) and represents an extreme risk when breached. SAD includes “the 3- or 4- digit security code printed on the front or back of a card, the data stored on a card’s magnetic stripe or chip (also called “Full Track Data”), and personal identification numbers (PIN) entered by the cardholder” (see page 11 of the PCI DSS Quick Reference Guide).
How Cyera supports PCI DSS compliance
Complying with any standard requires a comprehensive understanding of the data you hold and process—PCI DSS makes it comparatively easy to identify certain information because transactions can only be processed if data is in a certain format (e.g., a 16-digit card number). As a result, and perhaps indicating its own inherent risk, payment account data is likely stored in applications and databases spread around your organization, on both internally and externally facing endpoints. You can mitigate these risks by discovering, classifying, and identifying potential data exploit scenarios that exist in distributed systems and taking corrective actions.
For merchants, service providers, manufacturers, or software developers, Cyera can help you strengthen PCI data compliance by:
- Discovering, classifying, and inventorying cardholder and authentication data which may have been lost, forgotten, or mismanaged
- Auditing whether PCI data has been obfuscated and by what methods. For example, if a credit card number is encrypted, tokenized, hashed, or exposed as plaintext.
- Assessing the security resiliency of your datastores that house PCI data. Cyera will alert you to missing backups, insufficient logging, or known misconfigurations that can expose the data.
- Flagging overly permissive access to PCI data. With Cyera, you can see who has access to the datastores, including individual users.
- Flagging specific PCI violations. For example, when SAD is stored in a datastore, in violation of PCI DSS requirement 3.2 for this type of data to not be stored.
- Detecting indicators of compromise. For example, when PCI data moves from a secure, approved environment to a less secure, unapproved environment, Cyera can alert you to such activities.
Comply with Confidence
The world’s economy and supporting businesses are so interconnected that a breach in even the smallest franchise can lead to a massive leak impacting millions of individuals. PCI DSS is meant to help secure transaction processing and enable global ecommerce. But participating in payment systems and processes means taking the necessary steps to protect not just your data, but that of your customers and partners.
Cyera takes a data-centric approach to security, assessing the exposure to your data at rest and in use and applying multiple layers of defense. Because Cyera applies deep data context holistically across your data landscape, we are the only solution that can empower security teams to know where their data is, what exposes it to risk, and take immediate action to remediate exposures and assure compliance without disrupting the business.
To learn more about how Cyera can help you address PCI compliance, schedule a demo today.
