GCP Infrastructure for Fintech - Meeting PCI DSS and SOC 2 on Google Cloud

Google Cloud is certified as a PCI DSS Level 1 Service Provider and holds a SOC 2 Type II report. This means GCP infrastructure itself meets these standards. But your application running on GCP does not automatically inherit that compliance.

The Shared Responsibility Model means GCP is responsible for physical security, networking, and the hypervisor. You are responsible for IAM configuration, network isolation, application-level encryption, and audit log collection.

In practice, we see fintech startups making the same mistakes when starting on GCP: flat project structure, no VPC Service Controls, default GKE settings without hardening, and no automated audit evidence collection. This article addresses each of these.

PCI DSS and SOC 2 - How They Differ and When You Need Both

PCI DSS (Payment Card Industry Data Security Standard)

PCI DSS is required when your application processes, stores, or transmits card payment data (PAN, CVV, expiry date). This applies to:

• Payment gateways
• Subscription systems processing card payments
• Marketplaces with card payments
• Digital wallets storing card tokens

Current version: PCI DSS v4.0.1 (mandatory since March 2025). Key changes from v3.2.1: MFA required for all users accessing the CDE, continuous monitoring instead of periodic scans, stricter logging requirements.

SOC 2 (Service Organisation Control)

SOC 2 is not legally mandatory, but it is a de facto requirement from enterprise clients and integration partners. A SOC 2 Type II report confirms that your organisation maintained controls over a 6-12 month period across:

• Security (required)
• Availability
• Processing Integrity
• Confidentiality
• Privacy

For fintech, Security + Availability + Confidentiality are typically required.

When You Need Both

If you are a fintech processing card payments AND delivering services to other companies (B2B or SaaS model), you need both. PCI DSS for the card processing environment (CDE - Cardholder Data Environment). SOC 2 for the entire organisation and infrastructure.

Reference Architecture - GCP Project Structure

Isolation is the foundation of compliance. On GCP, separation happens through projects, which form IAM, billing, and networking boundaries.

Organisation (fintech-company.io)
├── Folder: Production
│   ├── Project: prod-cde          (Cardholder Data Environment)
│   ├── Project: prod-app          (application without card data)
│   ├── Project: prod-data         (BigQuery, analytics)
│   └── Project: prod-networking   (Shared VPC host)
├── Folder: Non-Production
│   ├── Project: staging-app
│   ├── Project: dev-app
│   └── Project: dev-networking
├── Folder: Security
│   ├── Project: security-logging  (central audit logs)
│   ├── Project: security-keys     (Cloud KMS)
│   └── Project: security-scc      (Security Command Center)
└── Folder: CI/CD
    └── Project: cicd-pipeline     (Cloud Build, Artifact Registry)

Why a Separate Project for CDE

PCI DSS requires a clearly defined scope. The smaller the scope, the fewer controls to implement and less to audit. Isolating CDE in a separate GCP project provides:

• Separate IAM policies (minimal number of people with access)
• Separate VPC (no connectivity to out-of-scope systems)
• Separate logs (easier to demonstrate completeness during audit)
• Separate billing (cost visibility for compliance)

Organisation Policy Constraints

At the organisation level, set constraints that enforce security:

# Region restriction - data stays in EU
constraints/gcp.resourceLocations:
  allowedValues:
    - europe-west2   # London
    - europe-west1   # Belgium
    - europe-west3   # Frankfurt

# Disable default service accounts
constraints/iam.automaticIamGrantsForDefaultServiceAccounts:
  enforced: true

# Enforce uniform bucket-level access
constraints/storage.uniformBucketLevelAccess:
  enforced: true

# Block public IPs on VMs
constraints/compute.vmExternalIpAccess:
  deniedValues:
    - ALL

Network Isolation - VPC Service Controls and Private Google Access

VPC Service Controls - Security Perimeter

VPC Service Controls (VPC-SC) create a perimeter around GCP resources that blocks data exfiltration even by authorised accounts. This is a unique GCP capability without a direct equivalent on AWS or Azure.

What VPC-SC blocks:

• Copying data from BigQuery in the CDE project to a project outside the perimeter
• Reading Cloud Storage objects in CDE from an account outside the perimeter
• Exporting logs from the CDE project to an external project

# VPC-SC perimeter definition (Terraform)
resource "google_access_context_manager_service_perimeter" "cde_perimeter" {
  parent = "accessPolicies/${var.access_policy_id}"
  name   = "accessPolicies/${var.access_policy_id}/servicePerimeters/cde"
  title  = "CDE Perimeter"

  status {
    resources = [
      "projects/${google_project.prod_cde.number}",
      "projects/${google_project.security_logging.number}",
      "projects/${google_project.security_keys.number}",
    ]

    restricted_services = [
      "bigquery.googleapis.com",
      "storage.googleapis.com",
      "cloudkms.googleapis.com",
      "logging.googleapis.com",
    ]

    access_levels = [
      google_access_context_manager_access_level.corp_network.name,
    ]
  }
}

Network Architecture for CDE

┌─────────────────────────────────────────────────────────┐
│  Shared VPC (prod-networking)                           │
│                                                         │
│  ┌──────────────────┐  ┌─────────────────────────────┐  │
│  │ Subnet: app      │  │ Subnet: cde                 │  │
│  │ 10.0.1.0/24      │  │ 10.0.2.0/24                 │  │
│  │ (prod-app)       │  │ (prod-cde)                  │  │
│  │                  │  │ - Private Google Access: ON  │  │
│  │                  │  │ - Flow logs: ON             │  │
│  │                  │  │ - No external IP            │  │
│  └──────────────────┘  └─────────────────────────────┘  │
│                                                         │
│  Firewall rules:                                        │
│  - Deny all ingress (default)                           │
│  - Allow app → cde: port 8443 only (mTLS)              │
│  - Allow cde → Cloud SQL: port 5432 (Private IP)       │
│  - Deny cde → internet (no egress except GCP APIs)     │
└─────────────────────────────────────────────────────────┘

Key elements:

• Private Google Access - communication with GCP services (KMS, Logging, Storage) without traversing the public internet
• Flow Logs on CDE subnet - required by PCI DSS Requirement 10 (traffic monitoring)
• mTLS between application and CDE - mutual certificate authentication, not just TLS

GKE Hardening - Kubernetes Configuration for Fintech

If your fintech application runs on GKE, the default cluster configuration does not meet PCI DSS requirements. Below are the settings required for compliance.

GKE Cluster Configuration (Terraform)

resource "google_container_cluster" "cde_cluster" {
  name     = "cde-gke"
  location = "europe-west2"
  project  = google_project.prod_cde.project_id

  # Private cluster - no public IPs on nodes
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = true
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }

  # Workload Identity - eliminates service account keys
  workload_identity_config {
    workload_pool = "${google_project.prod_cde.project_id}.svc.id.goog"
  }

  # Binary Authorization - only signed images
  binary_authorization {
    evaluation_mode = "PROJECT_SINGLETON_POLICY_ENFORCE"
  }

  # Shielded Nodes - boot integrity
  node_config {
    shielded_instance_config {
      enable_secure_boot          = true
      enable_integrity_monitoring = true
    }
  }

  # Network Policy enforcement
  network_policy {
    enabled  = true
    provider = "CALICO"
  }

  # Automatic security updates
  release_channel {
    channel = "REGULAR"
  }

  # Cloud Logging and Monitoring
  logging_config {
    enable_components = ["SYSTEM_COMPONENTS", "WORKLOADS"]
  }
}

Key Settings Mapped to Requirements

Encryption - Cloud KMS and CMEK

PCI DSS Requirement 3 mandates encryption of card data at-rest. GCP encrypts all data at-rest by default (AES-256), but uses Google-managed keys. For PCI DSS you need Customer-Managed Encryption Keys (CMEK) - keys over which you have full control.

Cloud KMS Configuration

# Key Ring in separate security-keys project
resource "google_kms_key_ring" "cde_keyring" {
  name     = "cde-keyring"
  location = "europe-west2"
  project  = google_project.security_keys.project_id
}

# Key for encrypting card data
resource "google_kms_crypto_key" "card_data_key" {
  name     = "card-data-encryption"
  key_ring = google_kms_key_ring.cde_keyring.id

  rotation_period = "7776000s"  # 90 days - PCI DSS requires rotation

  version_template {
    algorithm        = "GOOGLE_SYMMETRIC_ENCRYPTION"
    protection_level = "HSM"  # Hardware Security Module
  }

  lifecycle {
    prevent_destroy = true
  }
}

Application-Level Encryption (Tokenisation)

CMEK encrypts data at-rest at the infrastructure level. But PCI DSS v4.0 recommends an additional layer - tokenisation at the application level:

Client → [PAN: 4111...1111] → Payment Service → Tokenizer
                                                      ↓
                                              [Token: tok_abc123]
                                                      ↓
                                              Card Vault (encrypted with CMEK)
                                                      ↓
Rest of system sees ONLY the token → [tok_abc123]

Tokenisation reduces PCI DSS scope. If the rest of your system never sees the real PAN (only tokens), the CDE is limited to Tokenizer + Card Vault only.

Logging and Monitoring - Audit Evidence

PCI DSS Requirement 10 mandates complete logging of all access to card data. SOC 2 CC7.2 requires continuous security monitoring. On GCP you implement this through three mechanisms.

1. Cloud Audit Logs

GCP automatically generates audit logs for all administrative operations. Ensure you have enabled:

• Admin Activity logs (ON by default, cannot be disabled)
• Data Access logs (OFF by default - must enable for CDE)
• System Event logs (ON by default)

2. Log Centralisation (Log Sink)

Logs from the CDE project must be stored in a separate project (security-logging) to which CDE administrators do not have access. This ensures log integrity (PCI DSS Req 10.5).

3. Security Command Center (SCC)

SCC Premium is GCP’s central security platform. For fintech it provides:

• Threat Detection - detecting access anomalies
• Vulnerability scanning - automatic configuration scanning against CIS Benchmarks
• Compliance monitoring - ready-made reports mapping infrastructure state to PCI DSS and SOC 2 requirements
• Event Threat Detection - detecting suspicious activities (brute force, privilege escalation)

IAM - Least Privilege for Fintech

PCI DSS Requirement 7 mandates restricting access to card data exclusively to personnel who need it for their duties. On GCP you implement this through:

Role Hierarchy

Custom IAM Roles

Instead of using predefined roles (which often grant overly broad permissions), create custom roles with a precise set of permissions:

# Custom role for payment-service service account
resource "google_project_iam_custom_role" "payment_service_role" {
  project     = google_project.prod_cde.project_id
  role_id     = "paymentServiceRole"
  title       = "Payment Service CDE Access"
  permissions = [
    "cloudkms.cryptoKeyVersions.useToEncrypt",
    "cloudkms.cryptoKeyVersions.useToDecrypt",
    "cloudsql.instances.connect",
    "logging.logEntries.create",
  ]
}

Enforcing MFA

PCI DSS v4.0 requires MFA for all users with CDE access. On GCP you enforce this through:

1. Cloud Identity / Workspace - setting MFA as mandatory for the cde-admins@ group
2. IAM Conditions - adding a condition checking request.auth.claims.amr to verify the session uses MFA
3. Context-Aware Access - access policies requiring a specific authentication level

CI/CD for PCI DSS Environments

PCI DSS Requirement 6 mandates a secure software delivery process. SOC 2 CC8.1 requires change controls. The CI/CD pipeline must ensure:

• Vulnerability scanning in container images
• Artefact signing (Binary Authorization)
• Environment separation (dev has no access to prod-cde)
• Full auditability (who applied a change, when, what it contained)

Pipeline with Binary Authorization

Developer > Push to Git > Cloud Build (scan + build + sign) > Artifact Registry
                                                                      |
                                                            Binary Authorization
                                                            (signature verification)
                                                                      |
                                                              GKE CDE Cluster
                                                            (deploy signed image)

CDE Pipeline Separation

The pipeline delivering code to CDE must be separate from the general pipeline. In practice:

• Separate Cloud Build trigger for the CDE repository
• Separate service account with permissions only to the prod-cde project
• Required code review + approval before merge to main (Branch Protection Rules)
• Automatic SAST/DAST scan before deployment

Automated Audit Evidence Collection

The biggest pain point for fintech during PCI DSS and SOC 2 audits is collecting evidence. The auditor asks: “Show me that encryption was active on all databases for the past 6 months.” Manually preparing screenshots takes weeks.

Automation with GCP:

• IAM Policy snapshots - monthly export of who has what roles in the CDE project
• KMS key rotation history - prove keys are rotated every 90 days
• Audit Log retention proof - demonstrate logs are retained for minimum 1 year
• Vulnerability scan results - history from Artifact Analysis
• Network configuration - export of firewall rules and VPC-SC perimeter config

Use a scheduled Cloud Function that checks critical controls hourly and reports violations to Security Command Center as custom findings.

Implementation Checklist

Phase 1: Foundation (week 1-2)

• GCP project structure (separate project for CDE)
• Organisation Policy Constraints (regions, public IPs)
• VPC with CDE subnet isolation
• Private Google Access on CDE subnet
• Cloud KMS with HSM keys

Phase 2: Compute and deployment (week 3-4)

• GKE cluster with hardened configuration (private, Workload Identity, Shielded Nodes)
• Network Policies (default deny + explicit allow)
• Binary Authorization
• CI/CD pipeline with vulnerability scanning

Phase 3: Monitoring and audit (week 5-6)

• Data Access Audit Logs enabled
• Log Sink to central project
• Security Command Center Premium
• VPC Service Controls perimeter
• Automated compliance checking (Cloud Function)

Phase 4: Documentation and audit preparation (week 7-8)

• PCI DSS scope map (network diagram, data flow diagram)
• Policies and procedures (access control, incident response, patch management)
• Automated evidence export
• Penetration testing (ASV scan + internal pentest)

UK-Specific Considerations

FCA Regulatory Requirements

UK fintech firms regulated by the FCA must consider additional requirements when deploying on cloud infrastructure:

• Operational resilience - FCA expects firms to identify Important Business Services and set impact tolerances
• Third-party oversight - cloud providers are considered material outsourcing arrangements requiring board-level oversight
• Data sovereignty - while not strictly requiring UK-only hosting, FCA expects clear documentation of data locations and access controls

Region Selection

For UK-regulated fintech, europe-west2 (London) is the natural choice:

• Data remains physically in the UK
• Simplifies FCA reporting on data location
• Sub-5ms latency to UK users and payment networks
• PCI DSS scope documentation is clearer with a single-region deployment

Compliance Costs on GCP

For a typical UK fintech (50-100 employees, one SaaS product with payments):

Compliance infrastructure on GCP costs $2,000-6,000 annually. This is negligible compared to the cost of a PCI DSS breach (fines of $5,000-100,000/month) or losing SOC 2 certification (loss of enterprise clients).

How We Can Help

At Devopsity we design GCP infrastructure for fintech companies - from initial setup through PCI DSS and SOC 2 audit preparation. Typical engagement:

• Assessment (2-3 days) - evaluate current infrastructure, identify compliance gaps
• Implementation (4-6 weeks) - reference architecture with Terraform, GKE hardening, VPC-SC, monitoring
• Audit preparation (2-3 weeks) - documentation, evidence collection automation, auditor support
• Maintenance (ongoing) - quarterly compliance reviews, incident response

Building fintech on GCP?

Book a free consultation. We will discuss your architecture against PCI DSS and SOC 2 requirements.

Book a call

Frequently Asked Questions

Is GCP certified for PCI DSS?

Yes. Google Cloud is a certified PCI DSS Level 1 Service Provider. Certification covers infrastructure (compute, storage, networking) and selected managed services (GKE, Cloud SQL, BigQuery). But GCP’s certification does not exempt you from certifying your own application - the shared responsibility model applies.

How long does it take to prepare a fintech for PCI DSS audit on GCP?

For new infrastructure built from scratch with compliance in mind: 8-12 weeks. For existing infrastructure requiring adjustment: 12-20 weeks. Timeline depends on system complexity and scope (how many components touch card data).

Are VPC Service Controls mandatory for PCI DSS?

They are not explicitly required by the standard, but they satisfy the network segmentation requirement (Req 1) and protect against data exfiltration. In practice, every QSA auditor will appreciate their presence as they significantly reduce data breach risk.

Can I run prod-cde and prod-app in a single GKE cluster?

Technically yes (with namespace isolation and Network Policies), but it is not recommended. Separate GKE clusters for CDE and the rest of the application provide stronger isolation and a simpler audit scope. The additional cost (~$75/month for control plane) is marginal compared to the benefit.

Should I start with SOC 2 Type I or go straight to Type II?

Type I confirms controls exist at a point in time. Type II confirms they operated over a 6-12 month period. You can go directly to Type II, but the auditor needs evidence from at least 6 months. Many firms start with Type I (faster to obtain) and transition to Type II after six months.