PCI-DSS v4.0 Compliance Mapping for CleanStart Container Infrastructure

1.1

Maintain accurate network diagram

N/A - Customer scope

Network topology document (customer maintains)

Diagram must show all systems processing/storing PII; update annually

1.1.1

Diagram includes cardholder data flows

N/A

Same as above

Identify all containers handling card data

1.2

Restrict access to cardholder data systems

Kubernetes NetworkPolicy

Default-deny egress policy; only approved destinations

Customer defines which pods need network access

1.2.1

Restrict inbound traffic to system components

Kyverno policy: deny ingress from non-whitelisted namespaces

Policy rules visible in kube-system; audit logs

Customer configures ingress rules for apps

1.2.3

Prohibit direct public routes

Network policies + service type (ClusterIP vs NodePort)

NetworkPolicy blocks external access by default

Customer ensures services are not NodePort/LoadBalancer unless needed

1.2.4

Restrict outbound traffic from payment systems

NetworkPolicy with egress rules

Only allow outbound to payment gateway IPs/domains

Customer configures egress whitelist per app

1.3.1

Inventory of firewall devices and rules

Kyverno policies listed in cluster

kubectl get networkpolicies -A

Customer documents custom policies

1.3.2

Describe traffic flow between systems

N/A

Network diagram (customer)

Customer maintains

1.3.3

Describe protection of all systems

Admission control + network policies

Policy violations logged; audit trail

Customer implements logging

1.3.4

Restrict protocols to necessary ones

Kyverno rule: require protocol in NetworkPolicy (TCP/UDP only)

Policy enforcement in admission control

Customer specifies ports/protocols

1.3.5

Restrict ICMP

NetworkPolicy: no ICMP by default

Policy rules

Customer confirms no ICMP needed

1.3.6

Restrict inbound access to DMZ

Kyverno: deny non-compliant ingress

Ingress resource audit

Customer configures DMZ tier

1.4.1

Denies all traffic by default

Default-deny NetworkPolicy

Policy shown in kubectl get networkpolicies

Customer confirms policy active

1.4.2

Stateful firewall rules

NetworkPolicy + connection tracking (kernel-level)

Network flows in audit logs

Customer validates throughput/latency acceptable

1.4.3

Explicitly prohibits dangerous protocols

Kyverno rule blocks non-standard protocols

Policy enforcement

Customer lists approved protocols

1.4.4

Render firewall config in human/machine-readable form

NetworkPolicy YAML format

All policies exportable via kubectl

Customer version-controls policies

1.4.5

Only one primary route between networks

N/A - Customer network design

Network diagram

Customer designs topology

1.4.6

Configure routers/firewalls to prohibit inbound traffic from untrusted networks

Istio ingress + Kyverno

Ingress controller audit logs

Customer whitelists trusted sources

1.4.7

Document management procedures for all network components

Playbook + RBAC

Access logs to cluster; audit trail of changes

Customer documents procedures

2.1.1

Establish secure baseline configuration

CleanStart image = immutable baseline

Dockerfile + build process

Customer documents base image SLA

2.1.2

Document all system components

Admission control template: require component labels

Kubernetes labels (team, app, version)

Customer applies labels to all workloads

2.1.3

Document security parameters

Kyverno policies enforce security settings (non-root, read-only FS, dropped capabilities)

Policy rules + audit logs

Customer verifies parameters in deployment spec

2.1.4

Document hardening procedures

Container Security Policy (governance doc)

Policy + runbooks

Customer trains teams on hardening

2.2.1

Remove vendor-supplied defaults

Image built without shell, package managers, default creds

Dockerfile + SBOM inspection

Customer confirms no defaults in app config

2.2.2

Restrict access to configuration parameters

Kyverno + RBAC: only SRE/DevOps can modify deployments

Audit logs show who changed what

Customer manages secret credentials (not in image)

2.2.3

Restrict physical/logical access to components

Cloud IAM + Kubernetes RBAC

Service account permissions scoped

Customer manages infrastructure access (GCP)

2.2.4

Document all access to system components

Kubernetes audit log

All API calls logged to /var/log/audit/audit.log

Customer monitors audit logs

2.2.5

Identify unnecessary services/protocols/ports

Image = minimal set of binaries

Trivy scan confirms no unnecessary tools

Customer lists required ports in NetworkPolicy

2.3.1

Configure all system components to restrict authentication access

Kyverno: require securityContext with runAsNonRoot

Deployment spec audit

Customer sets securityContext (required by policy)

2.3.2

Restrict admin access to system components

Kubernetes RBAC: roles defined (viewer, editor, admin)

Role definitions in kube-rbac-authorization-config

Customer assigns roles per team

2.3.3

Document management interface security parameters

Cluster API server uses TLS; RBAC enforces authz

Audit logs; TLS certificates

Customer monitors admin API access

2.3.4

Configure cryptographic keys for authentication

Cosign keys rotated annually

Certificate expiration monitoring

Customer uses cloud key management (Cloud KMS)

3.1

Keep data retention and disposal procedures

N/A - Customer decision

Retention policy document

Customer defines retention (e.g., 12 months)

3.1.1

Establish procedures to purge stored account data

N/A

Purge scripts / automation

Customer implements data deletion

3.1.2

Do not store sensitive authentication data post-authorization

N/A - App requirement

Code review

Customer ensures no hardcoded secrets

3.1.3

Mask PAN display (show last 4 digits only)

N/A

App code review

Customer masks PAN in logs/UI

3.2.1

Encrypt stored account data at rest

Read-only root filesystem prevents plaintext files

Falco alerts on write-to-root attempts

Customer encrypts data at rest (Cloud SQL encryption, etcd encryption)

3.2.1.1

Use strong cryptography (TLS 1.2+, AES-256)

Kubernetes etcd encrypted (Cloud Config)

GCP config

Customer ensures DB uses strong crypto

3.2.1.2

Key management procedures

Cloud KMS rotates keys automatically

KMS audit logs

Customer audits key usage

3.2.1.3

Key injection into memory for cryptographic operations

N/A

N/A

Customer manages secrets injection (not in image)

3.2.2

Document encryption architecture

N/A

Architecture document

Customer documents data flow (encrypted)

3.3

Restrict access to encryption keys

Cloud IAM restricts KMS key access

IAM binding rules

Customer audits KMS permissions

3.3.1

Generate strong cryptographic keys

Cloud KMS uses FIPS 140-2 approved algorithms

KMS config

Customer verifies algorithm strength

3.3.2

Restrict key access to essential personnel

Cloud IAM: only SRE/DevSecOps can access keys

Audit logs

Customer reviews access

3.3.3

Store keys securely

Cloud KMS (HSM-backed)

KMS documentation

Customer does not export keys

3.3.4

Render keys unreadable during storage and transmission

Keys stored in Cloud KMS; not in code/config

Config audit

Customer never logs key material

3.3.5

Prevent unauthorized key substitution

Cloud IAM prevents key deletion/replacement

Audit logs

Customer tracks key versions

3.3.6

Key rotation at least every 3 years

Cloud KMS auto-rotation enabled

KMS config

Customer enables auto-rotation

3.3.7

Split key responsibilities

N/A

N/A

Customer enforces 4-eyes principle (if applicable)

4.1.1

Establish encryption for all non-console access

Kubernetes API: TLS 1.2+ required

KubeAPI server config (--tls-min-version=VersionTLS12)

Customer uses HTTPS for app APIs

4.1.2

No 'early' versions of TLS/SSL

Kyverno policy can enforce TLS version minimum

Ingress controller config

Customer configures app to require TLS 1.2+

4.1.3

Encrypt all cardholder data in transit (end-to-end)

Istio mTLS between pods; TLS to external systems

Istio config; NetworkPolicy; tcpdump verification

Customer ensures app uses TLS for card transmission

4.2

Encryption keys and certificates managed securely

Cloud KMS; certificate management (GCP cert manager)

Certificate expiration monitoring

Customer maintains certificate chain

5.1

Maintain anti-malware software/solution

Image vulnerability scanning (Trivy) + Falco eBPF monitoring

Scan results; Falco rules

Customer runs app-level malware detection (if applicable)

5.1.1

Implement anti-malware on all personal computers

N/A (containers, not PCs)

N/A

N/A (out of scope for container env)

5.1.2

Implement anti-malware on all systems not considered personal computers

Trivy scan identifies known malware signatures

Scan artifacts

Customer scans for fileless malware (OS-level)

5.1.3

Update anti-malware definitions

Trivy database auto-updates daily

Scan timestamps

Customer runs scans regularly

5.1.4

Configure anti-malware to perform regular scans

Automated image scanning in CI/CD

ScanResult CRD in cluster

Customer monitors scan results

5.2

Ensure anti-malware is not disabled

Falco rule alerts if malware detection disabled

No admission control override possible

Customer does not disable scanning

6.1

Maintain SDLC: design → develop → test → release

Build pipeline: source → scan → sign → push

Git workflow; CI/CD logs

Customer reviews code before merge

6.1.1

Identify all security requirements in SDLC

N/A

Security requirements doc

Customer lists requirements (e.g., "encrypt PII")

6.1.2

Review security requirements before development

Code review process

PR comments in GitHub/GitLab

Customer enforces review before merge

6.1.3

Define development environments separate from production

Separate image tags; staging vs prod labels

Kyverno rule: block mixing tags

Customer uses staging before deploying to prod

6.1.4

Remove test accounts before production release

Image scanning + manual review

SBOM audit; no test creds in Dockerfile

Customer audits code for test accounts

6.1.5

Review custom code before release for injection vulnerabilities

SAST (static analysis) in CI/CD pipeline

ScanResult artifact

Customer runs SAST (Snyk, Sonarqube, etc.)

6.1.6

Prevent insecure code from moving to production

Admission control: blocks unsigned images

Deployment blocked if not signed

Customer ensures CI/CD enforces signing

6.1.7

Review code changes before production deployment

Change control process; Gatekeeper policy review

Git history; Slack approvals

Customer documents code changes

6.2.1

Maintain inventory of all systems with vendor support

Kubernetes version support matrix

Version tracking

Customer documents all system versions

6.2.2

Establish procedures for vendor security patches

Container Security Policy (SLAs for Critical/High CVEs)

Policy document

Customer follows SLA for patching

6.2.3.1

Security patches: Critical within 30 days

Remediation SLA: Critical CVE → 24 hours

Tracking dashboard; incident tickets

Customer prioritizes critical vulnerabilities

6.2.3.2

Security patches: High within 90 days

Remediation SLA: High CVE → 7 days

Tracking dashboard

Customer prioritizes high vulnerabilities

6.2.3.3

Security patches: Medium within 180 days

Remediation SLA: Medium CVE → 30 days

Tracking dashboard

Customer tracks medium vulnerabilities

6.2.4

Implement updates securely: test before release

Staging environment testing; canary deployment

Test results in CD logs

Customer runs integration tests

6.3.1

SAST (Static Application Security Testing)

Trivy + SCA (software composition analysis) for dependencies

ScanResult artifact in registry

Customer runs SAST on custom code

6.3.2

DAST (Dynamic Application Security Testing)

Trivy scan of built image

ScanResult artifact

Customer runs DAST on running app

6.3.3

Penetration testing

Not CleanStart responsibility

N/A

Customer conducts annual pen testing

6.3.4

Remediate vulnerabilities before release

Image cannot be pushed if Critical/High CVE

Scan gate in CI/CD

Customer cannot deploy vulnerable image

6.4

Change control process

Git-based workflow + approval process + Gatekeeper

Audit logs

Customer enforces 2-person approval

6.4.1

Separate dev/test/production environments

Image tags + Kyverno label enforcement

Policy prevents cross-env tag misuse

Customer uses environment labels

6.4.2

Document change control procedures

Container Security Policy + runbooks

Policy document

Customer documents procedures

6.4.3

Document configuration standards

Dockerfile + security baselines

Dockerfile + policy doc

Customer documents config changes

6.4.4

Assign change control access

Kubernetes RBAC: editor vs viewer roles

Role definitions

Customer restricts deployment access

6.4.5

Review and approve all changes

Kyverno policies enforce approval

Audit logs; OPA decision logs

Customer documents approval process

6.4.6

Implement changes securely

Image-based rollout (not in-place patching)

Deployment history

Customer tests before deploying

6.4.7

Restrict audit log access

Audit logs stored in separate system

GCP Cloud Audit Logs

Customer reviews audit access

6.5.1

Injection attacks: parameterized queries, prepared statements

N/A

Code review

Customer uses parameterized queries (not "string + user input")

6.5.2

Cross-Site Scripting (XSS): output encoding

N/A

Code review

Customer encodes user input before rendering

6.5.3

Cross-Site Request Forgery (CSRF): unique tokens

N/A

Code review

Customer implements CSRF tokens

6.5.4

Insecure cryptography: use approved algorithms

Image contains OpenSSL/BoringSSL (approved)

Dockerfile + SBOM

Customer uses approved crypto libraries

6.5.5

Broken access control: implement authorization checks

N/A

Code review

Customer checks user permissions before allowing action

6.5.6

Sensitive data exposure: remove unnecessary data

Image built minimal (no unnecessary tools)

SBOM audit

Customer minimizes data collection

6.5.7

Identification and authentication failures: strong controls

N/A

Code review

Customer uses strong auth (MFA, password policies)

6.5.8

Data integrity: cryptographic signing

Cosign image signature

Signature verification logs

Customer verifies signatures before deployment

6.5.9

Logging and monitoring failures: comprehensive logging

Falco + Kubernetes audit logs

Logs accessible to customer

Customer reviews logs regularly

6.5.10

Using components with known vulnerabilities: dependency scanning

Trivy dependency check (SCA)

SBOM artifact

Customer runs SAST on custom dependencies

7.1

Limit access to data based on business need

RBAC: ClusterRole/ClusterRoleBinding

Role definitions in cluster

Customer defines who needs access to what

7.1.1

Implement role-based access control (RBAC)

Kubernetes RBAC system

kubectl get roles -A

Customer assigns roles (viewer, editor, admin)

7.1.2

Document access needs for each role

N/A

RBAC policy document

Customer documents why each role exists

7.1.3

Restrict access to necessary resources

Kyverno policy: namespace isolation

NetworkPolicy blocks cross-namespace access

Customer configures namespace boundaries

7.2

Establish access control system that restricts access based on need-to-know

Kubernetes RBAC

Role bindings restricted per namespace

Customer reviews role assignments quarterly

7.2.1

Assign access based on job classification

N/A

RBAC policy

Customer assigns roles per team/person

7.2.2

Default deny; explicitly grant access

Default RBAC: no permissions unless explicitly granted

Default ClusterRole is "" (no access)

Customer explicitly grants needed permissions

7.2.3

Document access control system

RBAC configuration documented

Policy document

Customer documents access model

7.2.4

Implement access control on all system components

RBAC applies to: API server, etcd, kubelet, services

Audit logs

Customer verifies RBAC on all components

7.3

Provide access to data on a need-to-know basis

RBAC restricted per user; time-limited access

Access logs

Customer reviews who accessed cardholder data

7.3.1

Limit access to cardholder data to those who need it

Service account per workload; no shared credentials

Audit logs

Customer prevents credential sharing

7.3.2

Assign access based on individual need

Separate service accounts per team

kubectl get serviceaccounts -A

Customer creates least-privilege service accounts

8.1

Assign unique user ID

Cloud IAM service accounts named per team

IAM console

Customer creates unique service accounts

8.1.1

Generate unique user ID before allowing access

Cloud IAM: service account = unique identity

Service account email (format: sa@project.iam.gserviceaccount.com)

Customer provisions accounts before granting access

8.1.2

Remove user ID access within 24 hours of termination

Cloud IAM: disable service account

Audit logs

Customer disables accounts on termination

8.1.3

Remove/disable inactive accounts

Cloud IAM: disable if unused >90 days

Audit logs

Customer reviews inactive accounts

8.1.4

Remove shared group/generic accounts

Kyverno policy blocks service account sharing

Audit logs

Customer creates per-person service accounts (no generic)

8.2.1

Use strong authentication: strong passwords or other methods

Cloud IAM: Service account keys + MFA

MFA enforced at GCP org level

Customer enables MFA for all users

8.2.1.1

Strong password: min 8 characters + complexity

Cloud IAM password policy enforced

Org-level password rules

Customer enforces password policy

8.2.1.2

Passwords not found in readily available cipher text

Cloud IAM: passwords hashed, never transmitted plaintext

Google Cloud KMS encryption

Customer does not share passwords

8.2.1.3

Limit password reuse (no repeat of 4 previous)

Cloud IAM: password history rule

Org-level policy

Customer enforces password history

8.2.1.4

Password validity period ≤ 90 days

Cloud IAM: password expiration enforced

Org-level policy

Customer enforces expiration

8.2.1.5

Limit login attempts to 6 failures

Cloud IAM: account lockout after N failed attempts

Org-level policy

Customer monitors lockouts

8.2.1.6

Lock account for 30 min after 6 failed attempts

Cloud IAM: lockout enforced

Org-level policy

Customer resets locked accounts

8.2.2

Use multi-factor authentication (MFA) for all administrative access

Cloud IAM: MFA (Authenticator app, Security key, SMS)

MFA enrollment dashboard

Customer requires MFA for all admins

8.2.3

Authentication credentials sent only over secure channels

Cloud IAM: TLS 1.2+

Google Cloud infrastructure (managed)

Customer uses HTTPS for all authentication

8.2.4

Use two-factor authentication (2FA) for all non-administrative access

Cloud IAM: optional 2FA for users

MFA policy

Customer enforces 2FA if handling cardholder data

8.3

Secure access management: multi-factor identification

MFA required for admin access

Enrollment logs

Customer uses security keys when possible

8.3.1

Implement MFA before granting admin access

Cloud IAM: require MFA before activation

MFA enrollment

Customer enforces MFA enrollment before admin access

8.3.2

Incorporate MFA into automated access control systems

Cloud IAM: integration with Kubernetes RBAC

Service account keys + MFA at Google Cloud level

Customer maps GCP identities to K8s RBAC

8.4

Render access credentials unreadable during transmission

Service account keys: never hardcoded; stored in Cloud KMS

Key management dashboard

Customer never logs service account keys

8.5

Secure remote access to cardholder data systems

Cloud IAM + Cloud VPN (if needed)

VPN config

Customer requires VPN for remote admin access

8.5.1

Implement MFA for remote access

Cloud IAM: MFA required at GCP

MFA enrollment

Customer uses MFA for remote access

8.5.2

Remove/restrict direct public access to cardholder systems

Kubernetes ClusterIP services (not LoadBalancer)

Service type audit

Customer does not expose PCI-in-scope services publicly

8.5.3

Remote access technologies (SSH, VPN, etc.) use strong encryption

Cloud SSH keys + VPN (managed by customer)

SSH key audit

Customer uses strong SSH keys (4096-bit RSA or Ed25519)

8.5.4

Document remote access procedures

N/A

Remote access policy

Customer documents who can access and how

8.5.5

Monitor and restrict remote access

Cloud Audit Logs

gcloud logging read

Customer reviews remote access logs

8.6

Implement access controls for all systems on the cardholder data network

Kubernetes RBAC + NetworkPolicy

Audit logs; policy enforcement

Customer monitors who accesses what

8.6.1

Require unique user ID; render passwords unreadable

Cloud IAM identity + encryption

Service account audit

Customer does not share passwords

8.6.2

Restrict access by device before allowing access

Cloud IAM: device compliance policies (optional)

Device compliance dashboard

Customer enforces device enrollment (if applicable)

8.6.3

Restrict access by geography/location (if applicable)

Cloud IAM: geo restrictions (advanced)

Login audit logs

Customer implements geo restrictions if needed

8.6.4

Use inactive session timeouts

Kubernetes API server: token expiration (default: 24 hours)

API server config

Customer configures session timeout (e.g., 15 min inactivity)

8.6.5

Prevent reuse of session IDs

Kubernetes API: session ID randomization

API server config

Customer does not hardcode session IDs

8.6.6

Limit session timeout

Kubernetes API: configurable timeout

API server config (--max-requests=...)

Customer limits token lifetime to 1 hour for sensitive ops

9.1

Implement physical access controls (facility security)

OUT OF SCOPE - GCP managed

GCP datacenter security certifications (SOC2, ISO 27001)

Customer reviews GCP security docs

9.1.1

Perimeter security (fencing, badges, video surveillance)

GCP datacenters (customer not responsible)

GCP certifications

N/A

9.2

Maintain access log for physical access

GCP audit logs; Kubernetes API logs

GCP Cloud Audit Logs

Customer reviews cluster access logs

9.2.1

Control inbound access; badge readers/locks

GCP managed (customer not responsible)

GCP security docs

N/A

9.2.2

Visitor access controlled and signed in

GCP managed

GCP security docs

N/A

9.2.3

Access badges expire

GCP managed

GCP security docs

N/A

9.2.4

Remove access to facilities when employment ends

GCP managed

GCP security docs

N/A

9.3

Physical monitoring of computer facilities

GCP managed

GCP security docs

N/A

9.3.1

Video surveillance

GCP datacenters have CCTV

GCP certifications

N/A

9.3.2

Monitor physical access points

GCP managed

GCP security docs

N/A

9.3.3

Collect and retain surveillance logs

GCP managed

GCP security docs

N/A

9.4

Restrict physical access to network infrastructure

GCP managed

GCP security docs

N/A

9.5

Monitor server rooms; control access to servers/terminals

GCP managed

GCP security docs

N/A

10.1

Implement log capturing and review

Kubernetes API audit logs + Falco + Cloud Audit Logs

Logs accessible via kubectl / gcloud

Customer configures log shipping (e.g., to Splunk)

10.1.1

Log access to all systems on cardholder data network

Kubernetes audit log: all API calls logged

--audit-log-path=/var/log/audit/audit.log

Customer exports logs to central SIEM

10.1.2

Log user access to cardholder data

Application logging (customer responsibility)

App logs

Customer logs all data access in app

10.1.3

Log access to audit trails themselves

Cloud Audit Logs: access to Cloud Logging API

Audit logs of audit logs

Customer prevents unauthorized audit log access

10.1.4

Log all access to cardholder data management systems

Kubernetes audit log

kubectl get events

Customer logs PCI-related activities

10.1.5

Log attempts to access invalid accounts

Kubernetes API: failed authentication logged

Audit log analysis

Customer alerts on failed login attempts

10.1.6

Log administrative actions

Kubernetes audit log: all kubectl/API calls

Audit events

Customer logs all admin actions

10.1.7

Log access to interactive user sessions

Kubernetes API: session tokens logged

Audit log (truncated token)

Customer tracks interactive sessions

10.2.1

Log user identification in audit trails

Kubernetes audit log: user + email

Audit JSON: "user": {"username": "...@domain.com"}

Customer verifies user identification

10.2.2

Log authentication attempts

Kubernetes audit log

Failed API calls logged (401 Unauthorized)

Customer monitors auth failures

10.2.3

Log access to audit logs themselves

Cloud Audit Logs

Admin Activity log tracks access to Logging API

Customer alerts on audit log access

10.2.4

Log invalid access attempts

Kubernetes audit log

Failed API calls (403 Forbidden, 404 Not Found)

Customer investigates invalid access attempts

10.2.5

Log administrative actions

Kubernetes audit log

kubectl apply, kubectl delete logged

Customer logs API changes

10.2.6

Log all access to cardholder data

Application logging (customer responsibility)

App must log query, read, write, delete of PAN

Customer implements PII-aware logging

10.2.7

Log system access for systems with PCI scope

Kubernetes audit log

API server: all pod/secret/config access logged

Customer monitors system access

10.3

Protect audit trails against tampering/alteration

Cloud Audit Logs: immutable (cannot delete/modify)

GCP Cloud Logging: write-once semantics

Customer enables Cloud Audit Logs (not local logs)

10.3.1

Limit audit log viewing to those with legitimate need

Cloud Logging: IAM role logging.viewer

IAM bindings

Customer restricts access to logs

10.3.2

Protect logs against unauthorized deletion

Cloud Audit Logs: immutable (enforced by GCP)

GCP security docs

Customer does not have ability to delete Cloud Audit Logs

10.3.3

Back up audit trails regularly

Cloud Audit Logs auto-replicated (GCP managed)

Bucket redundancy (multi-region)

Customer enables log export to Cloud Storage for archival

10.3.4

Export logs to centralized log management system

Cloud Logging Sinks

Log sink configuration

Customer exports logs to Splunk/DataDog/etc.

10.4

Implement automated log review procedures

Falco + custom alerting

Falco rules; alert rules

Customer configures alerts for PCI events

10.4.1

Review logs daily for: suspicious activity, unauthorized access, invalid transactions, etc.

Falco alerts + Cloud Logging dashboard

Daily report generation

Customer assigns log review to security team

10.4.2

Document audit log review findings

N/A

Investigation records

Customer documents findings

10.4.3

Analyze trends and anomalies

Cloud Logging dashboards; Falco timeline

Monthly security review

Customer performs quarterly trend analysis

10.4.4

Investigate root cause of significant events

Incident response playbook

Incident ticket

Customer conducts investigation

10.4.5

Retain log analysis for at least 3 months

Cloud Audit Logs: retained for 400 days (GCP default)

Log retention policy

Customer exports logs for 7-year retention (if required)

10.5.1

Retain online log history for at least 3 months

Cloud Audit Logs: 400-day retention

GCP policy

Customer exports to archive for 7-year retention

10.5.2

Retain log history for at least 1 year; retain 3 months online

Cloud Audit Logs

Bucket retention rules

Customer archives old logs to Cloud Storage (Nearline class)

10.5.3

Limit access to logs based on need-to-know

Cloud Logging IAM

roles/logging.viewer assigned to security team

Customer restricts log access

10.5.4

Use cryptographic authentication to prevent log deletion

Cloud Audit Logs: API-only, no direct deletion

GCP enforces read-only access

Customer cannot delete Cloud Audit Logs

10.5.5

Promptly make changes to logs following investigations

N/A (logs are immutable)

N/A

Customer documents investigation findings separately

10.6

Implement automated mechanisms to detect + alert on network anomalies

Falco + Cloud Network Intelligence

Falco rules; GCP DLP alerts

Customer monitors network for suspicious activity

10.6.1

Monitor all cardholder data flows; alert on suspicious flows

NetworkPolicy logging; VPC Flow Logs

GCP VPC Flow Logs enabled

Customer analyzes flows for exfiltration

10.6.2

Monitor all network segments; detect suspicious activity

Falco network rules

Falco syscall logging

Customer alerts on unexpected connections

10.6.3

Monitor inbound + outbound wireless access points

N/A (not applicable to container env)

N/A

N/A

10.6.4

Detect unauthorized wireless access points

N/A (not applicable)

N/A

N/A

10.6.5

Alert on detection of unauthorized change to network state

NetworkPolicy + Cloud Monitoring

Alert policy configured

Customer alerts on policy changes

10.7

Monitor all access to cardholder data

Application logging

App audit log

Customer logs all PAN/cardholder access

10.7.1

Log access by all individuals to cardholder data

Application logging

App must log: user, timestamp, action, data, result

Customer implements comprehensive audit logging

10.7.2

Alert on suspicious access patterns

Cloud Data Loss Prevention (DLP)

DLP rule detects PAN patterns

Customer configures DLP alerts

10.7.3

Protect access logs from alteration

Application logging: immutable log store

Logs sent to Cloud Logging (immutable)

Customer exports logs to immutable storage

10.7.4

Investigate alerts on cardholder data access

Incident response playbook

Incident ticket

Customer investigates all DLP alerts

11.1

Implement vulnerability scanning

Trivy image scanning + SBOM

ScanResult artifact

Customer runs SAST on application code

11.1.1

Test for vulnerabilities in external-facing systems

Trivy scan of image

Scan run as part of CI/CD

Customer conducts vulnerability scan before deployment

11.1.2

Scan at least quarterly (or after any changes)

Automated scan on every build

Build log timestamps

Customer runs scans on schedule

11.1.3

Address scan findings

Container Security Policy (SLA)

Tracking dashboard

Customer remediates high-risk findings

11.1.4

False positive investigation

N/A

Manual review

Customer investigates scan false positives

11.2

Perform vulnerability rescans after remediation

Trivy scan of patched image

ScanResult artifact

Customer verifies patch effectiveness

11.3

Penetration testing

N/A

Customer responsibility

Customer conducts annual pen testing

11.3.1

External penetration testing (annual)

N/A

Pen test report

Customer engages external firm

11.3.2

Internal penetration testing (annual)

N/A

Pen test report

Customer tests internal systems

11.4

Test intrusion detection/prevention systems

Falco monitoring

Test alert firing

Customer validates Falco rules effectiveness

11.2

Maintain security testing protocols

Container Security Policy + incident response playbook

Policy document

Customer documents testing procedures

11.2.1

Test network segmentation

NetworkPolicy testing in CI/CD

Test results

Customer validates network policies

11.2.2

Test for unauthorized changes to system components

Falco baseline monitoring

Falco alerts

Customer monitors for unauthorized changes

11.2.3

Test authentication mechanisms

Integration tests in CI/CD

Test results

Customer tests auth before deploying

11.2.4

Test access controls

RBAC testing

Audit logs

Customer validates RBAC permissions

11.3

Maintain change detection system to monitor configuration changes

Kyverno policies + audit logs

Policy enforcement; audit events

Customer enables change notifications

11.3.1

Maintain current network diagram

N/A

Network topology (customer)

Customer updates diagram annually

11.3.2

Maintain list of all network and security components

Kubernetes inventory

kubectl get nodes, pods, svc, ingress

Customer maintains hardware/software inventory

11.3.3

Update inventory within 30 days of any changes

Git history + automation

Change logs

Customer documents changes in version control

11.4

Maintain security configuration standards

Kyverno policies + Container Security Policy

Policy rules

Customer enforces baselines

11.4.1

Establish security configuration baseline

Dockerfile + Kyverno rules

Policy documentation

Customer documents required settings

11.4.2

Assess configuration compliance regularly

Kyverno policy audit

Admission control logs

Customer audits compliance (monthly)

11.4.3

Identify and correct deviations from baseline

Gatekeeper + manual review

Exception tracking

Customer investigates policy violations

11.4.4

Update baseline annually

Annual policy review

Version history

Customer reviews and updates baseline

11.5

Implement change control testing procedures

Git workflow + CI/CD testing

Build logs

Customer tests before deploying

11.5.1

Test all changes before implementing in production

Staging environment

Test results in CD logs

Customer runs integration tests

11.5.2

Use test environment that mirrors production

Staging cluster (same K8s version, config)

Cluster configuration comparison

Customer maintains equivalent staging

11.5.3

Document testing procedures

CI/CD pipeline documentation

README; test suite documentation

Customer documents test procedures

11.6

Detect unauthorized wireless access points

N/A (not applicable to container env)

N/A

N/A

12.1

Establish information security policy

Container Security Policy

Policy document

Customer maintains formal security policy

12.1.1

Document security objectives

Container Security Policy (Section 2)

Policy statement

Customer documents security goals

12.1.2

Management approval and assignment

Container Security Policy (Approval section)

Approval signatures

Customer obtains board/exec approval

12.1.3

Acknowledge responsibility for security

Incident response playbook

Policy document

Customer assigns clear ownership

12.1.4

Define roles and responsibilities

RACI matrix in Container Security Policy

RACI table

Customer documents who is responsible for what

12.1.5

Address information security requirements

Container Security Policy (Sections 4-7)

Policy document

Customer covers all control areas

12.1.6

Review and update policy annually

Annual policy review process

Version history; approval dates

Customer updates policy yearly

12.2

Conduct annual risk assessment

Risk management framework

Risk register

Customer maintains risk assessment

12.2.1

Identify threats and vulnerabilities

Threat modeling; vulnerability scanning

Threat inventory

Customer identifies threats relevant to cardholder data

12.2.2

Identify sensitive assets

Asset inventory

Asset list with classification

Customer lists all systems processing cardholder data

12.2.3

Assess potential business impact

Risk assessment matrix

Impact/likelihood matrix

Customer evaluates financial/reputational impact

12.2.4

Determine risk level (probability × impact)

Risk register

Risk score formula

Customer calculates overall risk

12.2.5

Document risk assessment

Risk assessment report

Annual report

Customer documents findings

12.2.6

Review and document risk remediation

Risk mitigation plan

Plan with deadlines

Customer tracks remediation progress

12.2.7

Evaluate residual risk

Risk register (post-mitigation)

Updated risk scores

Customer confirms residual risk is acceptable

12.3

Maintain incident response plan

Supply Chain Incident Response Playbook

Playbook document

Customer adapts playbook for their environment

12.3.1

Define incident response team

Playbook (Section 3.1)

Team roster; contact info

Customer identifies incident response team

12.3.2

Define incident response procedures

Playbook (Sections 3-7)

Incident response plan

Customer documents procedures

12.3.3

Document incident response process

Playbook

Process flowchart

Customer documents phases (detect → respond → recover)

12.3.4

Practice incident response (testing)

Tabletop exercises + simulated incidents

Drill records

Customer conducts quarterly drills

12.3.5

Document post-incident activities

Playbook (Section 7)

Post-mortem procedure

Customer conducts post-mortems

12.3.6

Keep incident response plan current

Annual updates

Version history

Customer updates plan on material security change

12.3.7

Obtain management approval

Incident response playbook

Approval signatures

Customer obtains executive sign-off

12.3.8

Distribute incident response plan

N/A

Shared with team

Customer ensures all relevant teams have copy

12.4

Implement security awareness program

Training plan

Training materials

Customer trains all personnel

12.4.1

Make security awareness part of job duties

Policy requirement

Policy statement

Customer emphasizes security accountability

12.4.2

Provide security training to all personnel

Training schedule

Course completion records

Customer trains all employees/contractors

12.4.3

Training content: secure use of systems, password security, secure deletion, phishing, malware, social engineering

Course material

Training curriculum

Customer covers PCI-relevant topics

12.4.4

Provide regular training (annually)

Annual training schedule

Attendance records

Customer refreshes training yearly

12.4.5

Train contractors on security requirements

Contractor onboarding

Training records

Customer ensures contractors trained

12.4.6

Provide incident response training to relevant personnel

Incident response drills

Drill attendance

Customer trains incident responders quarterly

12.5

Designate system owner for each PCI system

Asset inventory with owner assignment

Owner list

Customer assigns owner to each system

12.5.1

Document system components under each owner

Asset inventory; network diagram

Asset documentation

Customer lists all systems under each owner

12.5.2

Define system owner responsibilities

System owner charter

Job description

Customer defines owner duties

12.5.3

Update system ownership assignments annually

Annual inventory review

Version history

Customer reviews ownership assignments

12.6

Implement disciplinary process for personnel security violations

HR policy

Disciplinary policy

Customer documents disciplinary process

12.6.1

Communicate disciplinary process to personnel

Policy distribution

Training records

Customer communicates expectations

12.6.2

Apply disciplinary process consistently

HR records

Incident documentation

Customer enforces consistently

12.7

Maintain list of third parties/service providers

Vendor inventory

Vendor list

Customer maintains vendor list

12.7.1

Maintain written agreements with vendors

Contracts

Service agreements

Customer ensures vendor agreements include security terms

12.7.2

Maintain written policy addressing PCI compliance obligations

Vendor management policy

Policy document

Customer requires vendors to maintain PCI compliance

12.7.3

Verify vendor PCI compliance status

Vendor audit reports; attestations

Compliance evidence

Customer verifies vendor compliance (SOC2, ISO 27001, etc.)

12.7.4

Monitor vendor compliance

Vendor assessment

Audit checklist

Customer conducts periodic vendor assessments

12.8

Require suppliers to acknowledge PCI-DSS requirements

Supplier agreement

Signed acknowledgment

Customer includes PCI-DSS clause in supplier contracts

12.8.1

Require suppliers to comply with PCI-DSS

Supplier agreement

Compliance clause

Customer makes compliance a contract requirement

12.8.2

Provide suppliers with requirements list

Vendor onboarding

PCI requirements document

Customer educates suppliers on requirements

12.8.3

Monitor supplier compliance

Vendor audit

Assessment results

Customer verifies ongoing compliance

1.2.1

Restrict inbound traffic to approved systems

READY

None

N/A

N/A

N/A

2.1.1

Secure baseline configuration

IN PROGRESS

No Dockerfile versioning

Document Dockerfile version in deployment spec

SRE

2026-04-15

3.2.1

Encrypt stored account data at rest

READY

None

N/A

N/A

N/A

6.2.3

Patch vulnerability within SLA

IN PROGRESS

No CVE tracking tool

Implement tracking dashboard + weekly review

SecOps

2026-04-30

8.2.2

MFA for all admin access

NOT READY

MFA not enforced

Configure Cloud IAM MFA enforcement

Identity

2026-05-15

10.1

Implement audit logging

READY

None

N/A

N/A

N/A

CISO

________________

________________

____________

Compliance Officer

________________

________________

____________

General Counsel

________________

________________

____________