PCI Data Security Standard compliance

Last reviewed 2023-11-27 UTC

This guide helps you learn how to implement the Payment Card Industry Data Security Standard (PCI DSS) for your business on Google Cloud. The guide goes beyond the PCI SSC Cloud Computing Guidelines (PDF) to provide background about the standard, explain your role in cloud-based compliance, and then give you the guidelines to design, deploy, and configure a payment-processing app using PCI DSS. The tutorial also discusses methods for monitoring, logging, and validating your app.

This document refers to the PCI DSS 4.0 requirements where applicable.

The PCI Data Security Standard, created by the PCI Security Standards Council, is an information security standard for businesses that handle payment card (both credit and debit) information. The PCI Security Standards Council includes every major payment card company. Businesses that take Visa, MasterCard, Discover, American Express, JCB, or UnionPay are expected to comply with PCI DSS, and they can be fined or penalized if they don't.

PCI DSS includes classifications for several merchant types, from merchants that collect payment information in person to merchants that outsource payment processing entirely. This guide covers the SAQ A, SAQ A-EP, and SAQ D merchant types.

Objectives

  • Review the payment-processing app architecture.
  • Set up your payment-processing environment.
  • Deploy and configure your app servers.
  • Set up logging and monitoring.
  • Validate your payment-processing environment.

Definitions

This guide uses many unique phrases. Here are several of the most common. For more information, refer to the PCI DSS glossary.

CDE: Acronym for cardholder data environment. This acronym refers to any part of your app that holds or transfers any cardholder data, including the payment account number or any personally identifiable information related to the card.

Compensating controls: Alternative solutions that can be considered if an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints. Entities must sufficiently mitigate the risk associated with the requirement when they implement these other controls. See "Compensating Controls" Appendixes B and C in PCI DSS Requirements and Security Assessment Procedures for guidance on the use of compensating controls.

PAN: Acronym for primary account number and also referred to as an account number. It is the unique payment card number that identifies the issuer and the cardholder account.

QSA: Acronym for Qualified Security Assessor. QSAs are qualified by the PCI Security Standards Council (SSC) to perform PCI DSS on-site assessments. The Qualification Requirements for Qualified Security Assessors (QSA) provides details about requirements for QSA companies and employees.

SAQ: Acronym for Self-Assessment Questionnaire, the reporting tool that is used to document self-assessment results from an entity's PCI DSS assessment. This only applies for entities that are eligible for self-assessment.

Scope: The systems, procedures, and people to be included in a PCI DSS assessment.

Tokenization: A process that replaces the primary account number (PAN) with a surrogate value called a token. The PAN is then stored in a secure lookup. De-tokenization is the reverse process of looking up a PAN by its token. A token can either be a hash or an assigned value.

Background

PCI DSS provides a list of requirements designed to enhance cardholder security. These requirements are divided into twelve major numbered parts and many subparts. This document references these part numbers to add context, but the section references are not an exhaustive list of applicable requirements.

Your PCI DSS compliance requirements vary depending on how your company handles payment card transactions (type) and how many transactions it performs each year (level).

As your number of transactions increases, your PCI DSS merchant level increases, and the PCI DSS compliance guidelines become stricter. At the highest merchant level, Level 1, PCI DSS requires an audit. Levels vary by the card brand. Level 1 is defined by American Express as 2.5 million annual transactions, and by Visa, Mastercard, and Discover as 6 million annual transactions. Each card brand has additional level requirements that are beyond the scope of this document. Ensure that your payment-processing environment is audited to support your merchant level.

Because Google Cloud is a Level 1 PCI DSS 4.0–compliant service provider, it can support your PCI DSS compliance needs no matter what your company's merchant level is. The Committed to compliance section lays out which areas are covered for you by Google.

The other fundamental variable is your SAQ type. The SAQ outlines criteria that you must address to comply with PCI DSS if you are eligible for self-assessment. Your SAQ type is determined by your app architecture and the precise way you handle payment card data. Most merchants in the cloud are one of the following:

SAQ type Description
A Merchants that have fully outsourced payment card processing to a third-party site. Customers leave your domain (including through an <iframe> web form), complete payment, and then return to your app.

In other words, your company can't touch customer card data in any way.
A-EP Merchants that outsource payment processing to a third-party provider, but who can access customer card data at any point in the process. Merchants that can access card data include merchant-controlled page elements such as JavaScript or CSS that are embedded in the third-party payment page.

In other words, your payment processing app forwards card data to a processor on the client side, or the processor renders any content hosted by you.
D Merchants that accept payments online and don't qualify for SAQ A or SAQ A-EP. This type includes all merchants that call a payment processor API from their own servers, regardless of tokenization.

In other words, if you are not SAQ A or SAQ A-EP, you are SAQ D.

SAQ D differentiates between merchants and service providers. Service providers are not discussed in this document, and all SAQ D references address merchants as defined in PCI DSS.
Venn diagram of SAQ requirements. SAQ A-EP is a superset of SAQ A, and
SAQ D is a superset of SAQ A-EP.
Figure 1. Venn diagram of SAQ requirements. SAQ A-EP is a superset of SAQ A, and SAQ D is a superset of SAQ A-EP.

Committed to compliance

Google uses a variety of technologies and processes to secure information that is stored on Google servers. Google independently validated PCI DSS requirements that apply to Google Cloud technologies and infrastructure that are managed by Google. You can download Google's PCI DSS compliance reports from Compliance Reports Manager. While Google offers merchants a great deal of control over their compute instances that run on Google infrastructure, Google doesn't control security for the operating system, packages, or apps that merchants deploy on Google Cloud. It is your responsibility to comply with PCI DSS requirements for operating system packages and apps that you deploy, in addition to other customizations required by your architecture.

Google Cloud follows the PCI DSS requirements set forth for a Level 1 Service Provider and all applicable service provider requirements. The Google Cloud Shared Responsibility Matrix outlines the compliance obligations of PCI DSS. The responsibility matrix can be a helpful reference as you pursue PCI DSS compliance and conduct your own PCI DSS audits.

Product guidance

This section contains guidance for commonly-used Google Cloud services in architectures used for PCI DSS environments.

App Engine

Use App Engine ingress firewall rules and egress traffic controls.

Cloud Run

Use Cloud Run ingress settings, VPC Service Controls, and egress controls on VPC connectors. If needed, configure a static outbound IP address.

Cloud Functions

Use Cloud Functions ingress and egress network settings.

Cloud Logging

Log interactions with Cloud Logging.

Cloud Monitoring

Monitor interactions with Cloud Monitoring.

Google Kubernetes Engine

For information about using Google Kubernetes Engine for PCI DSS environments, see PCI DSS compliance on GKE.

Cloud Storage

Requirement 3.5 stipulates that a primary account number (PAN) is secured wherever it is stored. While Google automatically offers encryption at rest, it doesn't automatically perform the one-way hashes, truncation, or tokenization that the rules also require.

Example architectures

This section illustrates the approaches to implementing an environment that complies with SAQ A, SAQ A-EP, and SAQ D.

Architecture overview

SAQ A

SAQ A is the most basic payment-processing architecture. Payments are processed by a third party, and no card data is accessed by merchant apps or pages.

At a high level, the payment-processing flow is as follows:

  1. The customer makes their selections and proceeds to check out.

  2. The checkout app redirects the customer to a third-party payment processor.

  3. The customer enters their payment card information into a payment form that the third-party processor owns and maintains.

  4. The third-party payment processor checks the payment card information and then charges or declines the card.

  5. After processing the transaction, the third-party payment processor sends the customer back to the merchant app along with transaction details.

  6. The merchant app sends a verification request to the payment processor to confirm the transaction.

  7. The payment processor responds to verify the transaction details.

Processing information between the customer's browser, the merchant's site, the payment processor, and the payment gateway.
Architecture of an SAQ A third-party payment-processing environment.

SAQ A-EP

The SAQ A-EP payment-processing architecture is centered around a payment-processing app that runs on Compute Engine virtual machine instances. These instances are in a secure private network, and they use secure channels to communicate with services that are outside the network.

At a high level, the payment-processing flow is as follows:

  1. The customer enters their payment card information into a payment form that your company owns and maintains.

  2. When the customer submits their information, the form information is securely passed on to a third-party payment processor.

  3. The third-party payment processor checks the payment card information and then charges or declines the card.

  4. The payment processor sends a response back to your payment app, which then passes a message to your core app.

All of these interactions are logged and monitored with Cloud Logging and Cloud Monitoring.

Architecture of an SAQ A-EP payment-processing environment
Architecture of an SAQ A-EP payment-processing environment.

SAQ D

The SAQ D payment–processing architecture centers around a payment-processing app that runs on Compute Engine virtual machine instances. These instances are in a secure private network and use secure channels to communicate with services that are outside the network.

At a high level, the payment-processing flow is as follows:

  1. The customer enters their payment card information into a payment form that your company owns and maintains.

  2. When the customer submits their information, your payment app receives the form information.

  3. Your payment app validates the payment information and securely passes it on to a third-party payment processor through a backend API.

  4. The third-party payment processor checks the payment card information and then charges or declines the card.

  5. The payment processor sends a response back to your payment app, which then passes a message to your core app.

All of these interactions are logged and monitored with Logging and Monitoring.

Architecture of a SAQ D payment-processing environment
Architecture of a SAQ D payment-processing environment.

Payment processing customer-facing flow

SAQ A

This section describes the third-party payment processing flow from the perspective of the customers using your app.

Customer-facing flow of SAQ A third-party payment processing
Customer-facing flow of SAQ A third-party payment processing.

When your customer accesses your payment form, the app presents an <iframe> hosted by the payment processor. Your app cannot access or monitor the contents of the <iframe> because of cross-origin resource sharing limitations. When the customer submits their payment card information, the payment processor accepts or declines the card, then sends the customer back to your app. Your app then checks the transaction response from the payment processor and acts accordingly. Your app didn't access or handle any payment card information.

SAQ A-EP

This section describes the same internal payment processing flow as previously described, but from the perspective of the customers using your app.

Customer-facing flow of SAQ A-EP third-party payment processing
Customer-facing flow of SAQ A-EP third-party payment processing.

When your customer accesses the URL for your payment form, the site presents a form hosted by your payment app. When the customer submits their payment card information, the form goes directly to the payment processor. The processor accepts or declines the card, then sends the customer back to your app. Your app then checks the transaction response from the payment processor and acts accordingly. The customer might not see the third-party payment processor, but your app didn't access any payment card information on the server side.

SAQ D

This section describes the internal payment processing flow from the perspective of the customers using your app.

Customer-facing flow of SAQ D third-party payment processing
Customer-facing flow of SAQ D third-party payment processing.

When your customer accesses the URL for your payment form, they are securely routed to the form through an HTTPS load balancer. When the customer submits their payment card information, your payment-processing app securely sends the information to a third-party payment processor. The third-party payment processor accepts or declines the card, then returns a response to your payment-processing app.

Payment-processing internal flow

SAQ A & A-EP

This section describes the payment-processing flow from the perspective of the servers running your app.

SAQ A and SAQ A-EP internal flow
SAQ A and SAQ A-EP internal flow.

Your payment-processing app receives and parses the response returned by the third-party payment processor, and then sends some or all of the response data to the core app. At this point, your payment-processing app is finished with the transaction. The core app handles the task of notifying your customers.

SAQ D

This section describes the internal payment processing flow from the perspective of the servers running your app.

SAQ D internal flow
SAQ D internal flow.

Your payment-processing app validates the payment card information submitted by the customer, and then sends it to the payment processor through a backend API. The processor attempts the charge and responds with transaction details. Your app receives and processes the response and then sends some or all of the response data to the core app. At this point, your payment-processing app is finished with the transaction. The core app handles the task of notifying your customer and delivering product.

Monitoring and logging data flow

The monitoring and logging flow is designed as follows:

Monitoring and logging flow
Monitoring and logging flow.

Setting up your payment-processing environment

This section describes how to set up your payment-processing environment. Setup includes the following:

  • Creating a new Google Cloud account to isolate your payment-processing environment from your production environment.
  • Restricting access to your environment.
  • Setting up your virtual resources.
  • Designing the base Linux image that you will use to set up your app servers.
  • Implementing a secure package management solution.

Setting up a new account

To simplify access restriction and compliance auditing, create a production-quality, payment-processing environment that is fully isolated from your standard production environment and any dev and QA environments (requirement 6.5.3). To ensure isolation, create and use a Google Cloud account that is separate from your core production environment account. Users experienced with Identity and Access Management (IAM) configuration can accomplish equivalent isolation by using separate projects for in-scope work.

Restricting access to your environment

Allow payment-processing environment access only to individuals who deploy your payment system code or manage your payment system machines (section 7.2 and requirement 8.2.1). This is known as the principle of least privilege. Use IAM roles to restrict access. Best practices include using roles wherever possible, granting only the permissions required to perform expected work, and only granting the Owner role to principals who legitimately need full root access to your services. Refer to the IAM security guide for more information.

Automated access to any managed service should rely on service accounts. Service accounts simplify the app management lifecycle by giving you a way to manage app authentication and authorization. These accounts give you a flexible, yet secure way to group virtual machine instances with similar apps and functions that have a common identity. You can enforce security and access control at the service-account level through IAM roles and VPC firewall rules.

IAM rules that you apply to folders are inherited by all items contained in that folder. Default permissions are deny-all (requirement 7.2.3), and every rule that you apply only adds permissions.

Requirement 8.3.6 provides some basic rules for user passwords. The National Institute of Standards and Technology (NIST) defines a more secure set of rules for secure passwords in section 5.1.1 of NIST SP800-63B. Google recommends following the NIST Digital Identity guidelines whenever possible.

PCI DSS SAQ D section 12.7 requires individuals with access to your in-scope environment to pass a background check, in compliance with local laws, before they are granted access to the environment. To reduce the risk of compliance violations, consider performing these criminal background checks and reference checks on each individual regardless of your compliance type.

Securing your network

To secure inbound and outbound traffic to and from your payment-processing app network, you need to create the following:

  • Cloud Next Generation Firewall policies or Compute Engine firewall rules
  • A Cloud VPN tunnel
  • An External Application Load Balancer

For creating your VPC, we also recommend Cloud NAT for an additional layer of network security. There are many powerful options available to secure networks of both Compute Engine and GKE instances.

Creating firewall rules

Use Cloud Next Generation Firewall policies or VPC firewall rules to restrict inbound traffic to each of your Compute Engine instances (requirements 1.3 and 1.4). Allow inbound traffic only from the following three sources:

  • Public HTTPS, so that customers can reach your payment page.
  • Your app network, so that your payment-processing app can receive responses from your third-party payment processor.
  • Your internal office network, so that you can access the instances for auditing and management purposes.

Use firewall rules on individual instances to restrict outbound traffic. You can implement these rules locally with iptables or, more broadly, by using VPC firewall rules and network tags. Allow outbound traffic only from your payments form to the third-party payment processor. This connection must be HTTPS-only. To test your work, see the section on Firewall Rules Logging later in this document.

Cloud DNS offers private DNS zones so you can securely name hosts within your CDE without the potential of leaking sensitive network topology data to the public.

Restrict traffic as follows:

Source Destination Port Direction and reason
Public load bala