PCI DSS and ISO 27001 Evidence Automation for a Small Team
Meridian Pay is a payments processor pursuing PCI DSS v4.0 and ISO/IEC 27001. It runs three GKE clusters and 14 Cloud SQL instances; cardholder data is tokenized, but session data includes PAN fragments. The security team has six people and no GRC tool. The auditor requests evidence of quarterly access reviews for production, proof that CMEK keys are rotated at least annually, and separation of duties between those who approve firewall changes and those who apply them. Current state: firewall changes are applied by the same on-call engineer who approves the ticket; key rotation is manual and last done 19 months ago; access reviews are exported to spreadsheets. The GCP organization has nine folders and 60 projects. The team wants to automate evidence collection without buying a new platform.
1. Design a control mapping and evidence collection approach using native Google Cloud services. Explain how you would keep the evidence trustworthy for an auditor.
Read the worked answer
Map each auditor request to a GCP control owner and a native evidence source. Quarterly access reviews map to IAM policy exports from Cloud Asset Inventory and group membership reports from the Admin SDK. CMEK rotation maps to Cloud KMS key version and rotation metadata, plus audit logs for key version creation. Separation of duties maps to Cloud Audit Logs for firewall rule changes and the ticketing system's approval records. Store evidence in a dedicated evidence project with a Cloud Storage bucket that has retention lock and versioning, and restrict write access to an automation service account so that humans cannot quietly alter collected files.
Automate collection on a schedule: a Cloud Run job or Cloud Scheduler-triggered function exports IAM policies, key metadata, and firewall change logs to timestamped files, computes a hash, and writes a manifest. Include the query, the project scope, and the collection time so the auditor can reproduce it. For access reviews, generate a CSV per quarter listing every principal with production roles and the ticket or owner that justifies it; have reviewers sign off in the ticketing system, not in email. Link the signed ticket to the evidence object.
Trustworthiness comes from provenance and immutability. Enable Cloud Audit Logs for the evidence bucket, use retention lock, and separate the evidence project from production administration. Do not let the same team both collect and approve evidence without a second reviewer. Where native logs are the evidence, export them to a locked bucket rather than relying on screenshots.
2. Key rotation is 19 months overdue. What remediation and proof would you produce for the auditor, and what misconception should you correct?
Read the worked answer
Remediate first: enable automatic rotation on the Cloud KMS key with a period of 12 months or less, then create a new key version and confirm that Cloud SQL and GKE workloads can still decrypt. Key rotation in Cloud KMS creates a new primary version; it does not re-encrypt all existing ciphertext. Existing data remains decryptable with older enabled versions. If the auditor expects proof that all data was re-encrypted, correct that misconception: the control is about limiting the lifetime of a key version and about having a rotation process, not about rewriting every object.
Produce evidence: Cloud KMS key metadata showing the rotation schedule, the list of key versions with creation times, audit logs showing the rotation event and who or what triggered it, and a test record showing that a workload could read data after rotation. If policy requires retiring old versions, show the planned timeline and the risk assessment, because disabling old versions immediately can break decryption of existing data.
Also address why it was overdue. If rotation was manual, the root cause is process, not the key. Automate the rotation and add an alert if a key's primary version age exceeds the policy threshold. For Cloud SQL, confirm that the instance uses the CMEK key and that the service account binding is intact. Document the exception period and the compensating control, such as restricted key admin access, so the auditor sees a managed risk rather than an unexplained gap.
3. Firewall changes are approved and applied by the same on-call engineer. How would you redesign separation of duties with minimal operational friction, and what evidence would prove it?
Read the worked answer
Separate the approval role from the apply role using IAM and the ticketing workflow. Create two groups: firewall-approvers and firewall-operators. Approvers can approve tickets but cannot mutate firewall rules. Operators can apply rules but cannot approve their own tickets. Grant roles/compute.securityAdmin only to the operator group, ideally through short-lived elevation with a ticket reference. The on-call engineer can be in both groups only if the system enforces that they cannot approve a ticket they will apply; if that cannot be enforced in the ticketing tool, require a second approver for production changes.
Use Terraform or infrastructure-as-code so that firewall changes are reviewed as merge requests. The merge request approval is the separation-of-duties evidence, and the apply pipeline uses a service account that only the CI system can impersonate. This removes standing human write access and creates a clear record: who approved the merge, which pipeline applied it, and what changed. For emergency changes, allow a break-glass path but require retroactive approval within 24 hours and alert on its use.
Evidence: Cloud Audit Logs for compute.firewalls.insert, patch, and delete, showing the principal and timestamp; ticketing records showing a different approver; merge request approvals; and IAM policies showing that the operator group cannot approve tickets. Test the control by attempting a self-approved change and confirming it is blocked. The auditor wants to see that the control operates, not just that a policy document exists.