Compliance Frameworks and Auditing in GCP

Compliance frameworks are rulebooks written by governments, industries, or standards bodies. They define how organisations must handle specific types of data. For example, GDPR (General Data Protection Regulation) is a European law that controls how companies collect, store, and delete the personal data of EU citizens. HIPAA (Health Insurance Portability and Accountability Act) is a US law that sets rules for protecting medical records. PCI DSS (Payment Card Industry Data Security Standard) is a set of rules created by credit card companies that governs how you store, process, and transmit credit card numbers. Each framework has dozens or hundreds of specific controls. A control is a single requirement, like "encrypt all data at rest" or "log all access attempts to patient records". You cannot pass a compliance audit unless you implement every control that applies to your organisation.

Before cloud computing, companies had to prove compliance by showing auditors physical server rooms, printed logs, and paper policies. It was slow, expensive, and easy to make mistakes. Google Cloud changes this by offering built-in tools that automate compliance. The most important tool for auditing is Security Command Center (SCC). Security Command Center is a security and risk management platform that runs inside Google Cloud. It continuously scans your cloud resources, like virtual machines, storage buckets, and databases, against a set of security benchmarks and compliance frameworks. SCC detects misconfigurations, such as a storage bucket that allows anyone on the internet to read its contents, or a virtual machine that does not have the latest security patches. Each detection is called a finding. SCC groups findings by severity: critical, high, medium, or low. It also assigns a category, like "public bucket access" or "unpatched vulnerability". You can view all findings in a dashboard or export them to Cloud Logging for long-term storage.

To use SCC for compliance, you first enable it in your Google Cloud project. Then you turn on specific services inside SCC, such as Event Threat Detection, which watches for suspicious login attempts, or Container Threat Detection, which scans your containers for malware. You can also connect SCC to your compliance framework by activating the relevant compliance module. For example, Google Cloud offers a HIPAA compliance checklist inside SCC that lists every control you need to meet. SCC then checks your environment against that list and reports which controls pass or fail. This is called a compliance score. A score of 85% means you meet 85% of the required controls. The remaining 15% need manual action, like writing a policy document or training employees.

The second critical piece is audit logging. Cloud Audit Logs are a built-in feature of Google Cloud that records every action taken inside your project. Every time someone creates a virtual machine, deletes a storage bucket, or changes a firewall rule, Cloud Audit Logs records who did it, what they did, when they did it, and from where. There are three types of audit logs: Admin Activity logs track changes to configurations and metadata, like creating a new project. Data Access logs track reads and writes to customer data, like viewing a record in a database. System Event logs track automated actions by Google systems that affect your resources, like a VM being migrated to another host for maintenance. You must enable Data Access logs manually because they generate a lot of data. Without them, you cannot prove to an auditor that you know who accessed sensitive data.

Finally, you need to understand how Google Cloud itself is audited. Google Cloud undergoes independent third-party audits every year. It publishes the results as compliance reports, like SOC 1, SOC 2, SOC 3, ISO 27001, and FedRAMP. These reports prove that Google Cloud's internal controls meet global security standards. When you run workloads on Google Cloud, you inherit some of that compliance. For example, if HIPAA requires that the data centre has physical security, Google Cloud already passes that control, so you do not have to build a guarded fence. This is called the shared responsibility model. Google is responsible for the security of the cloud (the physical hardware, the network, the hypervisor). You are responsible for security in the cloud (your applications, your data, your user permissions). Compliance frameworks test both layers. You must show that you correctly configured your part inside Google Cloud. Security Command Center and Cloud Audit Logs are how you automate that proof.

Consider a mid-sized health tech company called MedTrack that stores patient medical records in Google Cloud. MedTrack must comply with HIPAA because it handles Protected Health Information (PHI). PHI includes names, addresses, medical diagnoses, and insurance numbers. A HIPAA auditor visits once per year. If MedTrack fails the audit, it can face fines up to $50,000 per violation.

MedTrack's IT team of three people sets up Google Cloud the day before the auditor arrives. They spin up a Cloud SQL database and a Compute Engine virtual machine to run their patient portal. They think they are ready. However, they forgot two critical things. First, they accidentally left the Cloud Storage bucket containing backup patient records publicly readable. Second, they never enabled Cloud Audit Logs for Data Access, so they have no record of who read each patient's file. The HIPAA auditor arrives. The auditor asks to see the logs showing who accessed a specific patient record in the last month. MedTrack cannot produce them. The auditor also runs a simple tool and finds the public storage bucket. MedTrack fails the audit immediately.

Now imagine the same company using Security Command Center correctly. Before the auditor visits, MedTrack enables SCC and turns on the HIPAA compliance module. SCC scans their entire Google Cloud environment within minutes. It generates a compliance score of 72%. SCC shows specific failing controls:

- Storage bucket 'patient-backups' is publicly accessible. - Cloud SQL database does not have encryption at rest enabled. - Compute Engine VM is running an outdated operating system version. MedTrack's team fixes each issue. They set the bucket to private, enable encryption on the database, and patch the VM. SCC rescans and shows a compliance score of 96%. The day of the audit arrives. The auditor asks for the same evidence. MedTrack opens SCC and shows the auditor the compliance dashboard with a 96% score. The auditor asks for audit logs. MedTrack opens Cloud Audit Logs and filters by the specific patient record. They show the auditor every single access event: timestamp, user identity, IP address, and action taken. The auditor passes MedTrack with no violations.

The key daily tasks for an IT professional using these tools include: