The 12 Requirements of PCI DSS Compliance

Maintaining PCI DSS compliance in the cloud is no easy task. It requires continuous (or at least periodic) monitoring, maintenance, and documentation to demonstrate you’re doing everything right in all the right places.

Compliance in the cloud isn’t quite the same as legacy on-prem because your hardware is different from generic cloud-based infrastructure. You can’t just lift-and-shift PCI compliance out of a data center and into the cloud. It needs to be tailored to the new infrastructure and observability and remediation need to be built in to maintain control without owning the environment.

What is PCI DSS compliance and why is it important?

PCI DSS stands for “Payment Card Industry Data Security Standard,” or “PCI compliance” for short. It is a regulation created by the major credit card brands (e.g. Visa, MasterCard, AmEx, Discover, and others) with the primary purpose of protecting against credit card fraud.

The 12 requirements of PCI DSS

There are 12 PCI DSS requirements, all of which help companies to meet baseline PCI security standards. The requirements apply to any company whether they’re doing business entirely on-premise or using public cloud services like AWS, GCP, or Azure. Failing to comply with PCI DSS can result in fines, loss of ability to process credit card transactions, and damage to the organization’s reputation.

The 12 requirements are:

  • Install and maintain network security controls
    • Implement network segmentation to isolate critical systems and limit the scope of potential security breaches.
    • Use network security groups, firewalls, and virtual private networks (VPNs) to control access to systems and resources in the cloud and Kubernetes.
  • Apply secure configurations to all system components
    • Use secure images and templates to create cloud instances and Kubernetes containers.
    • Implement security baselines and standards, such as the CIS Benchmarks, to ensure secure configuration of cloud instances and Kubernetes clusters.
  • Protect stored account data
    • Use data encryption to protect stored account data in the cloud and Kubernetes.
    • Implement access controls and audit logs to monitor access to stored account data and detect any suspicious activities.
  • Protect cardholder data with strong cryptography during transmission over open, public networks
    • Implement SSL/TLS encryption to protect cardholder data during transmission over open, public networks in the cloud and Kubernetes.
    • Use secure communication protocols, such as HTTPS and SSH, to securely transmit cardholder data over the internet.
  • Protect all systems and networks from malicious software
    • Implement anti-virus and anti-malware software in the cloud and Kubernetes to protect against viruses, worms, and other malicious software.
    • Use container security solutions, such as image scanning and runtime protection, to detect and prevent container-based attacks.
  • Develop and maintain secure systems and software
    • Use secure coding practices, such as input validation and error handling, to develop secure software for the cloud and Kubernetes.
    • Implement container security best practices, such as immutable infrastructure and least-privilege access, to maintain secure container environments.
  • Restrict access to cardholder data by business need-to-know
    • Implement access controls and role-based authentication to restrict access to cardholder data in the cloud and Kubernetes.
    • Use Kubernetes RBAC (Role-Based Access Control) to enforce least-privilege access to Kubernetes resources and APIs.
  • Identify users and authenticate access to system components
    • Implement strong authentication mechanisms, such as multi-factor authentication and OAuth, to verify the identity of users accessing cloud and Kubernetes resources.
    • Use Kubernetes secrets to securely store and manage authentication credentials for containerized applications.
  • Restrict physical access to cardholder data
    • Implement physical security controls, such as access controls and surveillance cameras, to prevent unauthorized physical access to cloud and Kubernetes resources.
    • Use container isolation and network segmentation to limit the exposure of containerized applications and data to potential attackers.
  • Log and monitor all access to system components and cardholder data
    • Implement a centralized logging system and log aggregation tools to collect and analyze logs from all cloud and Kubernetes resources.
    • Use container logging and monitoring solutions, such as Kubernetes Event API and Prometheus, to detect and respond to potential security incidents in real-time.
  • Test security of systems and networks regularly
    • Conduct regular vulnerability assessments and penetration testing to identify and address security vulnerabilities in cloud and Kubernetes resources.
    • Use Kubernetes security testing tools, such as kube-bench and kube-hunter, to automate security testing and improve security posture.
  • Support information security with organizational policies and programs
    • Develop and implement an information security policy that outlines the organization’s security goals, objectives, and responsibilities in the cloud and Kubernetes.
    • Provide regular security awareness training to employees and users of cloud and Kubernetes resources to help them understand their roles and responsibilities in maintaining the organization’s security posture.

Some security experts suggest a 13th requirement: “compensating controls.” These are additional or alternative security measures that may help a company to achieve compliance. They’re particularly helpful for businesses that may be unable to meet every aspect of the 12 requirements.

The PCI Security Standards Council explains the 12 requirements in depth in their Merchant Resources.

The 4 levels of compliance for PCI DSS

In addition to the 12 requirements, there are four levels of compliance based on the number of credit transactions processed in a year:

  • Level 1: > 6M transactions per year. Requires an annual onsite assessment by a Qualified Security Assessor (QSA)
  • Level 2: 1M-6M transactions per year. Requires an annual self-assessment and may lead to a QSA audit
  • Level 3: 20K-1M e-commerce transactions per year. Requires an annual self-assessment and may lead to a QSA audit
  • Level 4: < 20K e-commerce transactions per year or <1M transactions per year. Requires an annual self-assessment

Like the 12 requirements, the 4 levels of compliance apply regardless of whether infrastructure is on-premise or built with cloud computing services.

Cloud PCI DSS compliance

The cloud PCI compliance requirements are not too different from on-premise PCI compliance but the infrastructure is different. Compliance in the cloud comes down to implementing the 12 requirements across your cloud-based infrastructure. Whereas your on-prem data center might have a physical firewall, your cloud infrastructure will have a virtual firewall. Both need to be appropriately configured to meet the requirements. (Though, on-prem data centers are likely to need physical protections to adequately meet the 12 requirements.)

Cloud security experts spend a lot of time securing their cloud environments because they have less control over the underlying infrastructure. It’s important to understand whether your organization’s cloud provider can support PCI-compliant infrastructure. The biggest providers like Microsoft Azure and Amazon Web Services provide reference architectures, but they may not be fully PCI compliant in hybrid cloud environments or customized to your processes. Customization and configuration are required.

Automating PCI DSS compliance

PCI cloud compliance is difficult to establish and maintain. Many large organizations have dedicated teams running multiple spreadsheets. Use ComplianceCow to collect all evidence and to be the single source of truth for PCI.

ComplianceCow uses automation and collaboration to cover 100% of the control requirements. What can be automated is automated with the HI to No-Code rules engine. Process and other manual checks are facilitated through chat collaboration and guided workflows. A member of the HR team can attest that training was given and upload the actual deck. PCI controls are mapped and bound to scope and evidence is collected for audit or remediation purposes.

ComplianceCow
  • Built specifically for cloud and kubernetes as different from legacy on prem
  • More than just check-the-box compliance
  • More about making sure that everything else you have is configured properly than we are about doing any one thing ourselves
  • You are using a whole bunch of things to execute on PCI DSS and we are making sure they are working properly while also producing the paper trail that will be necessary for the audit.
  • Primary motivation is making sure everything is working properly or fixing it. Paperwork for audit is distant second.
  • The product allows you to make an Assessment (set of questions or statements, are passwords rotated), then to ask the questions of the system getting back results or evidence. Could be run annually or everyday We think you should do it everyday.
  • Audits are once a year outside requirements. PCI DSS is a compliance requirement. It is also a set of rules or ideas that can be applied more continuously. Then you can tell the world and your potential customers (who might have questions) how trustworthy you are with their data. We use the word “governance.” Or, limiting risk of negative things.
Cloud vs On Prem
  • We are built for the cloud and kubernetes. There are a lot of little things you need to do and check especially across different cloud providers. That is where ComplianceCow comes in.
  • We check to make sure that you have done all the different little things you have done and let you know what is out of whack. We can do so continuously or on a set schedule, programatically.
  • Additionally, unlike other products where developers have to make revisions after the fact and do extra work to allow for the evidence to be collected after the fact, we help the developers do it right the first time by making it easy for them to let us collect the evidence.
  • We make compliance an easy afterthought because you already have the evidence.
  • You are getting the evidence (data on your security posture, who has mfa enabled) so that you can take action and remediate. Firewall is out of whack, fix it. Someone does not have mfa, make them get it. Find something not in keeping with PCI DSS, fix it. Not to avoid fines but because it is in PCI DSS for a reason and could cause a problem.

Working together

  • Everyone is going to have to work together: security, security assurance, GRC (compliance) and developers to efficiently produce good secure and compliant code.
  • Use your existing tools with us and hook us into whatever you already have. We even run on teams and slack. Like I can tell ComplianceCow to do things from Slack.