Skip to content

    The big ideas in data compliance: An overview of the 12 PCI DSS requirements

    Overview of the 12 PCI DSS Requirements

    In the early 2000s, the Payment Card Industry (PCI) introduced its Data Security Standard (PCI DSS). Today, the framework outlines 12 requirements that card-accepting merchants must satisfy to process transactions on the card networks. Failure to do so could result in fines or being banned as a merchant or service, rendering you unable to process payments or payment data with the major networks. PCI DSS stands as one of the most popular and respected data security frameworks in the world. 

    Since that time, something else interesting has happened: card usage has exploded. 

    The U.S. Federal Reserve Survey of Consumer Payment Choice shows monthly usage of cards have increased by nearly 33% since the study began in 2009. Since going public, two largest card networks—Visa and Mastercard—have grown over  710% and 1500% respectively. In an increasingly digital economy, it’s hard to deny the role data security has in creating and sustaining meaningful growth. 

    The market may be catching on, too. Today, more businesses are becoming PCI DSS compliant despite not having the prerequisite volume to necessitate it. Why? Because achieving PCI compliance, especially Level 1, tells a powerful story to the market: you take your data and its security seriously.

    So while you may not need PCI Level 1 compliance to secure bank data or personally identifiable information, understanding its levels and 12 requirements will certainly help. 

    What are PCI Levels? Why do they matter?

    PCI Levels offer organizations a way to understand and determine their reporting requirements when processing cards. PCI Levels vary by card brand, but are generally determined by an organization’s current or projected amount of annual card transactions.

    Here's Visa's merchant levels, as a frame of reference:

    • PCI Level 4 Compliant: Less than 20,000 transactions per year.
    • PCI Level 3 Compliant: Between 20,000 and 1 million transactions per year.  
    • PCI Level 2 Compliant: Between 1 million and 6 million transactions per year.
    • PCI Level 1 Compliant: Over 6 million transactions per year.

    As the number of transactions rises, so do the requirements for establishing and maintaining compliance. Those qualifying for Level 4 compliance have a smaller compliance scope, while PCI Level 1 has the largest. The larger the scope, the more obligations (and the more compliance will cost) and the better story. 

    For example, PCI Level 1 requires an annual Report on Compliance (ROC) conducted by an independent Qualified Security Assessor (QSA). The report evaluates an organization’s program against the 12 requirements and its +250 sub-requirements.

    On the other hand, organizations with Levels 2, 3, or 4 use Self-Assessment Questionnaires (SAQs) for auditing their compliance program. Which types of requirements you must self-assess against (i.e., which SAQ to fill out) depends on how your organization stores, processes, or transmits payment card data. 

    An Overview of the 12 PCI DSS Requirements

    With so many paths and considerations to securing your data, familiarizing yourself with the spirit of the 12 PCI DSS requirements serves as a primer to modern data security strategies. 

    1. Install and maintain a firewall configuration to protect cardholder data

    Card data is inherently more valuable than most data; thus, organizations must segment it away from other pieces of information in a system. In doing so, organizations create a Cardholder Environment (CDE). The CDE provides organizations and assessors with clear blue lines and a solid foundation to build the other 11 requirements. 

    Identifying all the data and systems using card data is the first step. To create a CDE, PCI requires a combination of firewalls and network segmentation to control transmission of cardholder data between an organization’s networks (internal) and untrusted ones (external). In addition, documenting configurations, settings, and policies ensures future compliance for the CDE. 

    Learn more about PCI DSS Requirement 1.

    2. Do not use vendor-supplied defaults for system passwords and other security parameters

    Bad actors, which could be an individual or a software program, love out-of-the-box system configurations, like default passwords, wireless environments, and unnecessary functionality. If left, organizations open themselves to fairly predictable and practiced attack vectors that hackers can exploit at a relatively low cost. 

    PCI helps by outlining some standard best practices to be followed. These include but are not limited to changing passwords and disabling default accounts before implementation, using hardened industry configuration standards, and consistent enforcement of preventative policies, like vendor reviews.

    Learn more about PCI DSS Requirement 2.

    3. Protect stored cardholder data

    Both organizations and bad actors want to use the card numbers. While capturing this information can happen in transit (see: #4), most of all data spends 99.9% of its life on your servers in an “at-rest” state. 

    PCI outlines many requirements on how organizations must protect their data when not in use, but encryption is one of the most popular methods.

    simple encryption and decryption

    Data encryption uses math to convert plaintext values—like the 16-digit personal account number (PAN) on your card—into ciphertext, an unrecognizable jumble of characters. Instead of storing the PAN in plaintext, organizations store it as ciphertext. So even if an intruder were to gain access to the CDE and take all the encrypted data, they’d be unable to view it. To decrypt the ciphertext back into plaintext, an actor must use a unique cryptographic key. To ensure the keys themselves aren’t compromised, PCI provides guidance for key management (generation, storing, TTL, retirement, etc.) and also requires organizations to document, and adhere, to their encryption key management policy. 

    Another popular approach, data tokenization, complements encryption and helps address some of its developer challenges. Unlike encryption, tokenization creates a net new value, called a token. With the right tokenization provider, organizations can use tokens to simultaneously leverage part or all of the underlying data without bringing a system into scope. This allows the sensitive data to stay encrypted and secured at rest.

    Learn more about PCI DSS Requirement 3.

    4. Encrypt transmission of cardholder data across open, public networks

    Bad actors commonly target public networks to intercept card data. To prevent this, PCI mandates some security requirements to be in place when transmitting data, such as maintaining data encryption standards and up-to-date certificates.

    Scaling encryption is extremely difficult and risky for developers. To automate this process, reduce risk, and maintain compliance, many tokenization providers, like Basis Theory, manage data encryption as part of their services.

    Learn more about PCI DSS Requirement 4.

    5. Maintain a Vulnerability Management Program

    Bad actors have many tools to help them compromise systems, including malware and viruses. Therefore, PCI requires anti-malware and anti-virus software to be deployed on almost all systems and that it be updated, run, and evaluated frequently.

    Learn more about PCI DSS Requirement 5

    6. Develop and maintain secure systems and applications

    Bad actors prey on organizations unable to maintain their data security posture during its software development and data lifecycles. It only takes one weak link, like a missed system patch, for a bad actor to harm a system.

    Taking a holistic approach to the System Development Lifecycle (SDLC) security is key. To do this, PCI requires organizations to document their patching, software delivery, and data lifecycles. This allows organizations to create internal policies, processes, and standards at different touchpoints, ensuring proper preventative measures are met and routinely updated. PCI additionally provides requirements and guidance around separation of development and production environments, change management procedures, and common application vulnerabilities.

    Pro-tip: Use external guidance, like OWASP’s top 10 to help identify and prioritize common threats during different stages of the software development lifecycle.

    Learn more about PCI DSS Requirement 6.

    7. Restrict access to cardholder data by business need to know

    Like in the real world, only authorized personnel should access all or part of the card data. Of course, with the proliferation of data in today’s organizations, this is easier said than done. Without it, however, bad actors have many threat vectors to exploit. 

    Role-based access controls (RBAC) and other models satisfy PCI’s requirement by ensuring actors only have access and visibility to the sensitive data and systems they need to do their job. In addition, limiting access to those with a legitimate business reason helps an organization prevent mishandling cardholder data through inexperience or malice.

    Learn more about PCI DSS Requirement 7.

    8. Identify and authenticate access to system components

    Bad actors can appear as good actors in any system. Also, and not to complicate matters, good actors can turn bad or simply make mistakes. Understanding who did what and when helps prevent and remediate incidents. 

    To do that, PCI requires system administrators to assign unique identifiers (i.e. user accounts) for each actor with access to the CDE. When combined with logging (#10), this identifier creates the data trail needed to help remediate an issue, identify the threat vector, and much more. PCI additionally outlines requirements for user management procedures and rules.

    Another precaution worth highlighting is the use of multi-factor authentication (MFA). Authentication confirms an actor’s identity to another system through trusted secret handshakes—the more unique steps in the handshakes, the stronger the security.

    Learn more about PCI DSS Requirement 8.

    9. Restrict physical access to cardholder data

    Poor physical safeguards provide bad actors with another vector to capture data. The scope includes digital, like disks; analog, like scratch paper; or physical areas where card account data is stored, processed or transmitted, like data centers.

    PCI outlines a handful of sub-requirements for organizations to use when creating internal controls and policies, from system access controls (see: #8) to visitor logs and device management to the destruction of materials. 

    Learn more about PCI DSS Requirement 9.

    10. Track and monitor all access to network resources and cardholder data

    As you might’ve guessed, most of these requirements build on top of or fold into each other. Number 10 is no exception. 

    By creating clear blue lines around your cardholder environment (#1) and identifying the who, what, when, where, and how data is being accessed (#7 and #8), we can track and monitor activities critical to preventing, detecting, or minimizing security risks to card data. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Without system activity logs, determining the cause of an incident is very difficult—if not impossible.

    Learn more about PCI DSS Requirement 10.

    11. Regularly test security systems and processes

    Bad actors constantly probe high-value targets for weaknesses, frequently simulating normal-looking activities or actors on networks. 

    To prevent compromise, PCI requires regular software testing of known weak points in your systems and training of employees that regularly interface with sensitive data. This includes but is not limited to network scans, intrusion detection systems, and external penetration testing. Together, these contain and identify threats that might otherwise slip through unknowingly. 

    12. Maintain a policy that addresses information security for employees and contractors

    Most companies don’t see sensitive data, like card data, as a value-driving asset needing investment. To most, it’s a risk to be managed with the bare minimum done to protect it. Bad actors exploit bad security cultures. 

    While the final PCI requirement may come off as rigid, it plays a vital role in creating a security culture for an organization. What is sensitive data? What should we do? An appreciation for security is one of the best defensive measures an organization can face. 

    Let’s Recap: 

    • PCI Compliance provides payment network partners with proof or good faith that your organization has an effective information security program.
    • Whether it is SSNs or credit cards, PCI DSS tells your customers that you take security seriously.
    • The 12 PCI DSS requirements provide a strong foundation for securing any data type.

    With Basis Theory’s data tokenization platform, you can reduce your PCI Level 1 scope nearly 90% in just 30 seconds—for free and without a credit card on file. Check out our developer docs or talk to an expert today.

    Want Product News & Industry Updates?

    Subscribe to the Basis Theory blog to get updates right in your inbox