Governance and Compliance

A certificate that didn't cover what they thought

A healthcare startup signs up with a major cloud provider, sees the SOC 2 and ISO 27001 badges on the provider's compliance page, and tells its board the platform is HIPAA-compliant. Months later, an actual HIPAA audit asks for the startup's own access logs, its encryption configuration, and records of staff security training, none of which the provider's certifications ever claimed to cover.

This is the same gap the first lesson in this topic named as a misconception, now playing out in full: a provider's certification proves its own infrastructure meets a standard. Whether the application built on top of it meets that same standard is a separate question, and it's exactly what governance and compliance, as a discipline, exist to answer.

Governance asks inward, compliance points outward

Governance is an organization's own rulebook for how its cloud resources get configured and used: who reviews access requests, how resources get tagged, what configuration baseline every new service has to meet before it goes live. It's internally driven, and a company can have strong governance with no external framework in play at all.

Compliance is different: it's proving, to an auditor, a regulator, or a customer's own procurement team, that an organization's practices meet a specific external bar. That bar might be a certifiable standard a company chooses to pursue, or a law it has no choice but to satisfy. Good governance makes compliance easier to demonstrate, but the two answer different questions: governance asks "are we doing this consistently," compliance asks "can we prove it to someone outside the organization."

The compliance landscape: what each framework actually covers

ISO 27001 and SOC 2 overlap substantially in the controls they check, enough that a well-run compliance program can often satisfy both without duplicating the work, but they serve different audiences: SOC 2 is what a US enterprise customer usually asks for, ISO 27001 is what an international one usually expects.

Where to find the provider's half of the evidence

A cloud provider doesn't email its compliance reports on request; it publishes them through a self-service portal. AWS's version is called AWS Artifact, giving any account on-demand access to AWS's own SOC 1/2/3, ISO, and PCI reports, each generated with a unique watermark for the requester. That portal is the customer's starting point when an auditor asks "show me the provider's controls," and it's free to use. What it can never hand over is the other half of the evidence, the customer's own configuration, access logs, and internal processes, because AWS Artifact only documents AWS's side of the shared responsibility line.

Data residency versus data sovereignty

These two terms get used interchangeably, and the exam boundary between them is worth naming explicitly. Data residency is about physical location: where, geographically, is the data stored. Data sovereignty is about legal jurisdiction: whose laws govern that data, regardless of where it happens to sit.

GDPR is a useful case study because it clarifies which one it actually cares about. GDPR does not require EU personal data to physically stay inside the EU. What it requires, under its rules on international transfers, is that any transfer of personal data outside the EU or EEA receive protection that's essentially equivalent to what GDPR itself provides, through mechanisms like an adequacy decision covering the destination country, or standard contractual clauses between sender and receiver. A company can choose an EU cloud region for good operational reasons, lower latency to EU users, a simpler story for customers, but doing so addresses residency, a location question. It does not, by itself, satisfy the legal transfer question GDPR is actually asking if that same data later gets copied, backed up, or processed somewhere outside the EU.

A worked example: choosing a region for EU personal data

Say a team is building a service that stores personal data belonging to EU residents. Picking an EU-based region keeps that data physically close to its users and gives a simple answer to "where does our data live." But the team still has to check every place that data travels afterward: a support tool hosted outside the EU, an analytics pipeline in a US region, a backup replicated to another continent. Each of those is a transfer under GDPR's Chapter 5 rules, and each one needs its own legal basis, an adequacy decision for that destination, or contractual clauses, regardless of how carefully the primary region was chosen.

Misconception, revisited: inheriting a badge

The first lesson in this topic named this misconception in the context of security generally; here it is the specific, recurring compliance mistake: assuming a provider's certification transfers automatically to whatever a customer builds on top of it. It never does. AWS Artifact, or its equivalent on any provider, hands over evidence of the provider's own controls. The customer still has to assemble evidence of its own: access reviews, encryption configuration from the previous lesson, employee training, incident response processes, everything that HIPAA, PCI DSS, or a customer's own security questionnaire actually asks to see.

Exam cues: matching a scenario to a framework

Where this leaves you

Compliance is never something a customer inherits wholesale from a provider's badge page; it's something assembled from the provider's certified infrastructure plus the customer's own controls layered on top, the exact same boundary the shared responsibility model drew at the start of this topic, now applied specifically to proving it to an outsider. That closes out Cloud Security: you can now name who owns which security task, how identity and encryption enforce that ownership, and how governance and compliance prove it holds up under audit. The next topic in this domain leaves security behind and asks a different question entirely: once a system is secure, how does it stay running.