Cloud Compliance Basics: SOC 2, ISO 27001, HIPAA and GDPR

Their Attestation Is Not Your Attestation

A provider's compliance page is an impressive wall of logos, and it is routinely misread. Those documents cover the provider's own operations: their data centres, their staff vetting, their change management, their physical security.

They say nothing about how you configured your account. A storage bucket left open to the public sits inside a certified facility and is still a breach. The certification transfers a set of controls to the provider; everything in the layer you operate remains yours.

That division is the shared responsibility model, explained in the shared responsibility model in plain English. Compliance work is mostly the discipline of proving that your half is under control, repeatedly, with evidence.

Four Names That Work Very Differently

SOC 2

An attestation report produced by an independent accounting firm against the Trust Services Criteria, most commonly security plus whichever of availability, confidentiality, processing integrity and privacy apply. It is not a certification and there is no certificate to display. A Type I report describes control design at a point in time; a Type II report tests whether those controls operated over a period, and that is the one enterprise buyers ask for.

ISO/IEC 27001

A certifiable international standard for an information security management system. You define a scope, assess risks, select controls, document a statement of applicability and then submit to an accredited certification body. The emphasis is on the management system itself, meaning a repeatable cycle of risk assessment and improvement, more than on any specific technical control. The standard is published by ISO.

HIPAA

United States legislation covering protected health information. It is not something you are certified against; you are either subject to it or you are not. If you handle such data on behalf of a covered entity, you are a business associate, and a business associate agreement with both your customer and your cloud provider is a prerequisite. Providers publish which of their services may be used under such an agreement, and using one outside that list breaks the arrangement.

GDPR

European Union regulation governing personal data, applying by the location of the people whose data it is rather than by where your company sits. It assigns roles: a controller decides why and how data is processed, a processor acts on instructions. Cloud providers are normally processors, and a data processing agreement between you is required. Obligations include a lawful basis for processing, honouring individual rights and notifying supervisory authorities of qualifying breaches without undue delay.

Inherited, Shared and Entirely Yours

Providers publish their own evidence through a portal: AWS Artifact, the Microsoft Service Trust Portal and Google Cloud's compliance reports manager all let an account holder download reports under a confidentiality agreement, as the AWS Artifact documentation describes. Auditors will accept those for the inherited rows and will ask you directly about the rest.

Evidence Is Most of the Work

The uncomfortable truth of a first audit is that teams usually do the right things and cannot demonstrate it. Access is reviewed, but informally. Changes are approved, but in a conversation. Backups are tested, but nobody wrote down when.

Three habits generate most of the evidence an auditor asks for, and they are worth adopting whether or not you pursue a report.

First, make changes flow through a reviewed, recorded path. A merge request with an approver is change control evidence that costs nothing extra, which is one of the quiet benefits of defining infrastructure in version controlled files.

Second, keep the audit trail switched on everywhere and store it somewhere the people being audited cannot alter. Retention periods are a common finding, and the mechanics are covered in audit logging in the cloud.

Third, schedule the periodic reviews as calendar events with an output. Access reviews, backup restore tests and vendor reassessments all become evidence when they produce a dated artefact and nothing at all when they live in someone's memory.

Where the Data Sits, and Who Can Reach It

Several frameworks care about geography. GDPR restricts transfers of personal data outside the European Economic Area unless a recognised mechanism such as an adequacy decision or standard contractual clauses is in place. Sector rules in other jurisdictions add their own constraints.

The practical control is region selection, plus a check on what your configuration does around the edges. Backups replicated to a second region, a content delivery network caching at global points of presence, a log aggregator in another country and a support process with staff elsewhere are all places data moves without an obvious decision.

Read the provider's subprocessor list as well, since your obligations extend to the parties they use. The broader considerations are set out in data residency and sovereignty.

European providers often simplify this conversation by operating within a narrower footprint. The Scaleway account listings describe an account on a European platform, and the OVHcloud versus Scaleway comparison looks at how two such providers differ.

A Sensible Order of Operations

Teams often begin by buying a compliance automation platform. That is usually step four or five. The earlier steps are cheaper and make the tooling useful when it arrives.

Begin with an inventory. What data do you hold, which categories are sensitive, where does each live and who can reach it? Almost every finding traces back to a gap in this list.

Next, fix identity. Unique accounts, strong multi-factor authentication on every identity, least privilege roles and a documented leaver process cover a substantial share of the controls in every framework.

Then turn on the technical basics you will be asked about: encryption in both states as covered in encryption at rest and in transit, centralised logging, backups with a tested restore, and a written incident response process with named roles.

Only then write the policies. Policies drafted after the practice describe what you do; policies drafted first describe what you intended, and the gap between the two is what auditors find.

Questions Teams Ask First