PCI Data Security Standard compliance

Last reviewed 2022-07-29 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 3.2.1 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, or JCB 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.


  • 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.


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: Alternate solutions to any given requirement that meet the intent and rigor of the original requirement and that provide a similar level of defense. The official definition says that compensating controls must be "above and beyond" other PCI DSS requirements and must be commensurate with the additional risk imposed by not adhering to the original requirement.

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.

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.


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 3.2.1–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. 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.
Venn diagram of SAQ requirements. SAQ A-EP is a superset of SAQ A, and SAQ D is a superset of SAQ A-EP.

Merchants can be any combination of level and type, and your compliance requirements will vary greatly, depending on your circumstances.

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. 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

App Engine

Use App Engine ingress firewall rules and egress traffic controls.

Cloud Run

Use Cloud Run ingress settings 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

Approach the nodes and pods in a GKE cluster the same way as any merchant-managed server. Implement logging, instrumentation, and patching at both the node and pod level. Don't keep cardholder data at the node level; however, nodes will still be in scope if they contain or might contain any in-scope pods.

To restrict access to your control plane (cluster master), use authorized networks to block untrusted IP addresses from outside Google Cloud. These CIDR rules are compatible with private clusters and act as an allowlist (also referred to as whitelist).

Implement network policies in the GKE cluster when your in-scope projects contain different types of pods. Network policies work similar to the virtual private cloud (VPC) firewalls that you might already be familiar with. You can allow or deny traffic based on IP rules or labels.

Requirement 2.2.1 stipulates that only one primary function can be implemented per server. This requirement does not prohibit the case of a single GKE cluster hosting more than one pod type. The primary function of GKE nodes is to serve and manage containers. If designed properly, individual pods can also adhere to this primary function rule in a single cluster.

Cloud Storage

Requirement 3.4 stipulates that a PAN must be unreadable anywhere 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 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.


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.


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


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.


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.


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


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.


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/QA environments (requirement 6.4.1). 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.1 and requirement 8.1.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.2.3 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:

  • Compute Engine firewall rules
  • A Compute Engine virtual private network (VPN) tunnel
  • A Compute Engine HTTPS load balancer

For creating your VPC, we 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 firewall rules to restrict inbound traffic to each of your Compute Engine instances (requirements 1.2.1 and 1.3.2). 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. See the section on Firewall Rules Logging below to test your work.

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 balancer Third-party payments form tcp:443 Inbound
Public access to the payment-processing app
Third-party payment form Third-party payment processor tcp:443 Outbound
Forwarding AUTH requests to payment service provider
Third-party payment processor Your payment-processing app tcp:5480 Inbound
Accepting AUTH requests from payment systems (does not contain any cardholder data)
Your company's office network vpn-gateway tcp:8000 Inbound
Access to payment-processing environment for access to logs and development machines

In addition, the following traffic occurs securely in your payment-processing app internal network:

Source Destination Port Reason
Card form PCI proxy tcp:5480 Exchange of encrypted card data for payment instrument token
All hosts Google NTP servers udp:123 Time synchronization
VPN gateway All hosts tcp:22 Secure Shell (SSH) connections

Establishing a secure VPN tunnel

Compute Engine provides a VPN service that you can use to establish a secure VPN tunnel between your on-premises environment and your payment-processing environment (sections 2.3 and 4.1).

Creating an HTTPS load balancer

You can help ensure that incoming customer traffic is secure by creating a Compute Engine HTTP(S) load balancer (sections 2.3 and 4.1). To create an HTTPS load balancer, you need the following:

  • A subdomain of your website that is used for your payment processing form, for example, payments.your-domain-name.com.
  • A valid, signed SSL certificate that has been registered for your subdomain.

Ensure that your domain is valid by looking at its DNS settings in your web registrar domain configuration interface.

Creating a base Linux image

The PCI DSS contains requirements that describe how to set up machines that are part of a compliant payment-processing architecture. You can implement these requirements in several ways, but the easiest approach is as follows:

  1. Create a list of the software and libraries that must be installed on each server that is in scope for your payment-processing app. To avoid introducing unnecessary vulnerabilities to your system (requirement 2.2.2), include only the minimum of software and libraries that you need to run your app. Candidates might include the Google Cloud CLI, language-specific runtimes and libraries, or a web server.

  2. Create a Compute Engine instance that uses one of the Compute Engine preconfigured operating system images.

  3. Install the libraries and software you listed earlier.

  4. Install and configure ntp to keep system clocks in sync. Managing server clocks with the Network Time Protocol ensures the integrity of timestamps in logs (section 10.4).

  5. Ensure that the image follows the best practices for creating a secure Compute Engine image (all of section 2.2).

  6. After you've configured your base image, create a custom Compute Engine disk image from your image. This image allows you to use your base Linux image when you create virtual machine instances.

Using secure package management

Package management is a key component of a security-hardened hosting environment. Per section 2.2, you must implement industry-accepted hardening standards. Unless you use Container-Optimized OS from Google, you likely have a package manager installed such as RPM, Yum, or Apt. Your app might use its own programming language-specific package manager such as NPM, PyPi, or Composer, and download dependencies upon first run.

If your app can fetch updates from the internet, you must treat update sources as a potential security risk. Supply-side, or upstream attacks, that are maliciously included in publicly hosted packages are becoming more common. Imagine the effects of installing an update to SSH that contains malicious code.

You can mitigate the risk of supply-side attacks by creating a safe recipients list for your packages and verifying that they match the list. Keep a list of tested and approved version numbers for each package that you use. Record the version number along with its hash or signature. Ensure that the package manager validates the hash or signature before installing or updating an app.

Most package management systems allow for private hosting. If possible, launch your own private package management server and only host tested and approved software. Lock down the package manager so that it cannot reach out to other servers for updates.

Ideally, your app build process fetches and validates all packages, and then creates a revision of the custom disk image that includes everything that the container needs. This way, your servers launch and scale up with no installer delay, and there is a reduced chance of random errors at launch time. You can also revisit any previous version of your app exactly as it was in production simply by launching its image, which can be helpful for diagnostics and forensics.

Deployment and configuration

Next, set up the deployment and configuration of your instances from your base image.

Deploying your environment

To meet the PCI DSS requirements, ensure that you're deploying the correct app every time, that you're deploying the app securely, and that you aren't installing any other software packages during the deployment. To simplify the deployment process, consider creating an automated deployment for your app by using Cloud Deployment Manager.

Deployment Manager enables you to describe your entire payment-processing environment, including its firewall rules, gateways, load balancers, and instances. Deployment Manager can also help you construct an audit trail that shows how each app environment was created, and allows you to version environments as you improve and modify them.

In an automated deployment, you must verify the integrity of the software being deployed, whether it's from a third party or it's your own. You can verify your software by running an automated hash against each package as the package is installed. After a hash is verified, you can then use an automated testing framework to run security and other tests, and to verify that the tests have passed.

Finally, when deploying Compute Engine instances, design a recovery plan in the event that your instances fail. If your window for acceptable downtime is large enough, a manual recovery plan might be sufficient; if not, you must design an automated recovery plan. See the Disaster recovery planning guide, Designing robust systems, and Building scalable and resilient web apps for guidance.

Configuring your environment

After your instances have been deployed, ensure that they're configured correctly. Install additional software and libraries on top of each instance base image as needed. To avoid the complexity, overhead, and overall risk of manual configuration, use an automated configuration management tool such as Skaffold, Chef, Puppet, Ansible, or Salt.

Supply-chain attacks on upstream sources are becoming a bigger concern, so in addition to using base Linux images, you might want to use a tool such as the Grafeas API to audit upstream code.

Implementing Forseti Security

Forseti Security is a collection of community-driven, open-source tools to help you improve the security of your Google Cloud environments. Its modular architecture allows you to enable individual components, several of which can address specific requirements within the PCI DSS.

Inventory creates an inventory snapshot of your Google Cloud resources so you have a historical record of your architecture.

Scanner uses the information collected by Forseti Inventory to regularly compare role-based access policies for your Google Cloud resources. Scanner applies rules to audit Google Cloud resources like the following:

  • Identity and Access Management (IAM) policies for organizations, folders, and projects
  • Bucket ACLs
  • BigQuery dataset ACLs
  • Cloud SQL authorized networks

With Scanner, you can specify users, groups, and domains that are allowed, mandatory, or excluded from resources, and you can ensure that these access policies stay consistent. If Scanner finds any access policies that do not match your Scanner rules, it can save information about those rule violations to Cloud SQL or to Cloud Storage. This helps protect you against unsafe or unintentional changes.

Enforcer uses policies you create to compare the current state of your Compute Engine firewall to a specified state. Enforcer is an on-demand, command-line tool that compares policies in batch mode over all managed projects or against selected projects. If Enforcer finds any differences in policy, it uses Google Cloud APIs to make changes and display the output of the results.

The Explain add-on module provides visibility into your IAM policies. Explain can help you understand:

  • Who has access to what resources and how that user can interact with the resource.
  • Why a principal has permission on a resource, or why they do not have a permission and how to fix it.
  • Which roles grant a permission, and which roles are not in sync with recent changes.

After you've configured it, Email notifications can send email notifications for Inventory and Scanner.

Implementing immutable audit logging

Logging produces audit logs automatically for a wide variety of activities across many products. Long-term, you can securely store immutable logs by using Cloud Storage bucket locks (section 10.5). Bucket locks let you set a policy to make all objects immutable and non-deletable for an amount of time that you specify, from seconds to years. If you require access to the early-access program, contact your Google Cloud representative.

Implementing Virtual Private Cloud Flow Logs

The VPC Flow Logs service is designed to record network flows sent from or received by virtual machine instances. You can use these logs for network monitoring (section 10.2), forensics (requirement 10.6.3), and real-time security analysis.

Installing the Logging agent

After you set up iptables on your servers, each server logs every activity to the server's block storage. Check out the Logging pricing page for details on the free allotment and data transfer pricing. To retain these logs and to generate alerts based on abnormal activity, stream them to Logging and Monitoring by installing the Logging agent on each server (requirement 10.5.3).

Integrating an intrusion detection system

To help ensure the security of your payment-processing environment, described in section 11.4, use an intrusion detection system (IDS), so you know when bad actors try to attack the system. There are two ways to place an IDS in a payment-processing environment: place an IDS at every entry point, or install an IDS on every server.

To reduce the complexity of your environment architecture and to simplify compliance with 11.5, install an IDS on each server. After you research and choose the IDS software to use, make IDS installation part of the startup installation script for each server.

Cloud Intrusion Detection System (Cloud IDS), an intrusion detection service, provides threat detection for intrusions, malware, spyware, and command-and-control attacks on your network. Cloud IDS provides full visibility into network traffic, including both north-south and east-west traffic, letting you monitor VM-to-VM communication to detect lateral movement. You can also use Cloud IDS to simplify compliance with requirement 11.4.

IDS logs fall in the scope of PCI DSS compliance, and must be sent to Logging and Monitoring for reporting, alerting, and auditing.

Implementing Security Command Center

Security Command Center helps security teams gather data, identify threats, and respond to threats before they result in business damage or loss. It offers deep insight into app and data risk so that you can quickly mitigate threats to your cloud resources and evaluate overall health. With Security Command Center, you can view and monitor an inventory of your cloud assets, scan storage systems for sensitive data, detect common web vulnerabilities, and review access rights to your critical resources, all from a single, centralized dashboard. It can help you comply with several requirements, including sections 5 and 6.6.

Automating your app deployment

Build your configuration management tool to securely retrieve and launch the latest version of your app. Your app can be retrieved from any location, such as Cloud Storage, as long as that location is secure.

Many of the configuration management tools mentioned above support continuous integration and deployment (CI/CD) workflows, which can also be used to perform automated scanning (requirement 11.2.3) and to ensure that code is reviewed (requirement 6.3.2).

Capturing configuration manager logs

When setting up your configuration manager, ensure that it logs all installation details. After completing the configuration process, ensure that it delivers the logs to Logging and Monitoring.

Logging and monitoring

To ensure PCI DSS compliance under section 10, ensure that every step taken in your payment-processing environment is monitored and recorded. Every server activity on every instance must be logged, and every user action must be able to be examined at a later time.

Enabling Access Transparency

Through Access Transparency, Logging now offers near real-time logs when Google Cloud admins access your content. Cloud Audit Logs logs already provide visibility into the actions of your own admins. However, this audit trail typically excludes actions taken by your cloud provider's support or engineering team. For example, before Access Approval logging, if you opened a ticket with Google Support that required data access, it wouldn't have been tracked in Cloud Audit Logs. Access Approval closes that gap, capturing near real-time logs of manual, targeted access by either support or engineering.

Access Approval lets you explicitly approve access to your data or configurations on Google Cloud before that access occurs. Access Approval also provides insight into accesses by Google Support and Engineering.

Enabling Firewall Rules Logging

Firewall Rules Logging allows you to enable logging at the individual rule level. It can record TCP and UDP connections inside a VPC for any rules you create yourself. These can be useful for auditing network access or providing early warning that the network is being used in an unapproved manner.

Using VPC Service Controls

VPC Service Controls allows you to define a security perimeter around Google Cloud resources such as Cloud Storage buckets, Cloud Bigtable instances, and BigQuery datasets to constrain data in a VPC network and help mitigate data exfiltration risks (requirements 1.2.1 and 1.3.4). With VPC Service Controls, you can keep your sensitive data private as you take advantage of the fully managed storage and data processing capabilities of Google Cloud.

Setting up VPC Flow Logs

Cardholder Data Environment with VPC Flow Logs enabled
CDE with VPC Flow Logs enabled.

VPC Flow Logs record network traffic flows sent or received by VM instances. The logs are useful under PCI DSS for monitoring, auditing, forensics, and real-time security analysis. Each VPC network subnet can have Flow Logs enabled or disabled independently. You can minimize the amount of log data by only enabling Flow Logs on your in-scope CDE.

Flow Logs, combined with egress firewall rules, enable you to limit outbound traffic to authorized endpoints in a way that is auditable and difficult to circumvent (requirements 1.2.1 and 1.3.4).

If you require more detailed data than Flow Logs can provide, such as individual HTTP request logging, you can implement controls in your app or proxy outbound requests. You do this through your own reverse proxy server configured to forward access logs to Logging. For instructions on setting up a Squid proxy server on Compute Engine, see Setting up a network proxy. To avoid bottlenecks, set up at least two redundant proxy servers.

Logging internal access data

In addition to logging external threats, also monitor and log the activity of individuals who have admin access to your payment-processing environment (section 10.2). To do this, you can log shell commands. Several open source tools can audit shell commands and send them to logging. Popular choices for this task include OSSEC or Tripwire.

Setting up monitoring alerts

Configure Monitoring to send alerts if something goes wrong in your payment-processing environment (section 10.6). Ensure that your alerts cover environmental, audit, and internal app events. Base your alerting strategy on the potential risk or attack vectors for each component of your payment-processing app. For example, trigger Monitoring alerts if your IDS detects any intrusion attempts, whether they are successful or unsuccessful. You can also use Firewall Rules Logging to trigger alerts in response to attempts to violate specific network policies.

Streaming logs to BigQuery

Logging streaming logs to both
Cloud Storage and BigQuery
Logging streaming logs to both Cloud Storage and BigQuery.

Optionally, you can route Logging logs to BigQuery to analyze later; see Routing and storage overview: Sinks for details. Because BigQuery is optimized to query large datasets, it is an ideal tool for large-scale logs analysis. Logging can even log directly to BigQuery for logs that require near real-time analysis (requirement 10.6.1).

Using Sensitive Data Protection to sanitize data

There are many reasons to use parts of the data contained in your in-scope app that are not themselves in scope, such as for analytics or development. Grant apps access to PCI data only after it has been sanitized with Sensitive Data Protection (requirement 6.4.3).

App security

To help secure your app, you first need to evaluate the admin interface. You might also want to use Cloud Key Management Service.

Evaluating the admin interface

Most ecommerce apps have their own non-console admin interface, such as a customer service billing portal. Such a tool must have robust access controls; it must have individualized access that uses multifactor authentication (section 8.3); and it must be instrumented with audit logging (section 10.2).

Any logs you create should answer these questions: Who did what? Where did they do it? When did they do it? Per section 2.3, all access to such a tool must use strong transport encryption. Use Sensitive Data Protection to filter sensitive information before displaying it in any admin tool.

Using Cloud Key Management Service (Cloud KMS)

Cloud KMS is a service that lets you manage encryption keys. It can generate, use, rotate, and destroy AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 encryption keys. Cloud KMS allows you to remove plain-text passwords stored in code or config files, which simplifies compliance with requirements 3.5, 3.6, 6.3.1, and 8.2.

Validating your environment

After your environment is implemented, but before any production traffic flows through it, you must have the environment validated:

  • If you're a Level 1 merchant, your environment must be validated by a Qualified Security Assessor (QSA). A QSA is a firm or an individual that is approved by the PCI Security Standards Council to validate PCI environments and give the seal of approval.
  • If you're a Level 2 merchant or lower, you can validate your environment by filling out the Self-Assessment Questionnaire.

What's next