Cloud Compliance

Cloud compliance is the discipline of showing that data, workloads, and their controls in cloud services meet the requirements that apply to the organization. These include laws such as the GDPR, HIPAA or LGPD, contractual commitments such as PCI DSS, and assessment frameworks such as ISO 27001 and SOC 2. Moving systems to a cloud provider changes where the controls run, not the obligations.

What must be controlled depends on the service model. In infrastructure as a service, the customer configures operating systems, applications, and data settings, so most requirements apply directly. In software as a service, the provider runs the platform, while the customer governs identities, sharing settings, and what users may export. In every model, regulated data remains the customer's responsibility.

Every major provider publishes a shared responsibility model. The provider is accountable for the cloud itself: hardware, physical security, and availability. The customer is responsible for security and compliance in the cloud: data classification, access decisions, configuration, and user activity. A provider's certifications cover its side of that line, never the customer's.

The split matters because regulators hold the data owner accountable. A supervisory authority does not accept “the provider was certified” as an answer when the cause was a misconfigured storage bucket, a share open to anyone with the link, or an employee exporting records to a personal account. Compliance work starts by mapping each service's responsibility matrix onto the organization's obligations and closing the gaps on the customer side: identity, configuration, logging, and data handling.

Data protection law follows the data, not the infrastructure. Under the GDPR, using a cloud provider creates a processor relationship. That requires a data processing agreement, documented sub-processors, and transfer safeguards when data leaves the region. HIPAA requires a business associate agreement before protected health information may touch the provider's services.

This leads to two duties. The first is knowing what regulated data exists and where it lives: which services hold it, in which regions and under which agreements. That is impossible without classification and a service inventory that includes shadow IT, meaning the tools employees adopted on their own. The second is controlling movement. Regulated data that leaves the approved boundary through an unsanctioned account or a misdirected share is a compliance event, and it may also count as a data breach, even without malicious intent.

Frameworks give the vocabulary in which compliance is shown to customers, auditors, and regulators. The most requested ones are listed below.

A cloud provider does not shrink the PCI DSS scope: the cardholder data environment must be assessed wherever it runs.

Audit in the cloud has two layers. The provider layer relies on the provider's attestations, such as the SOC 2 report and the ISO 27001 certificate. The customer layer relies on evidence the organization produces itself: configuration baselines, access reviews, activity logs, and incident records.

Continuous compliance monitoring replaces the annual snapshot. Because cloud environments change daily, auditors expect evidence generated automatically: alerts on configuration drift, complete audit trails of who did what in which service, and reports on demand. The customer layer usually follows four steps:

1. 1

   Baseline

   Record the approved configuration of each cloud service and compare every change against it.

2. 2

   Review access

   Check who can reach each service, and remove accounts that no longer have an owner.

3. 3

   Keep the trail

   Store who did what in each service, with the time and the object, for as long as policy requires.

4. 4

   Report on demand

   Produce the evidence for an auditor from the stored records, not from memory.

In Anexet, the cloud storage control settings of an agent profile set an access level, an audit mode, and a shadow copy for each cloud service.

In practice, a program brings together a few components: an inventory of the cloud services in use, including unsanctioned ones; classification of the data that reaches them; a mapping of controls to each applicable framework, so one control meets several requirements; enforcement on the channels through which data enters and leaves those services; and evidence collection that makes all of this demonstrable on demand.

None of these components is specific to one regulation. Obligations multiply with a new privacy law, a new contract or a new framework version, while the underlying controls rarely change. Organizations that keep the inventory, classification, enforcement, and audit trail absorb each new requirement by mapping it onto existing controls. The protection side of this work is covered in cloud data security.

Further reading: Use Anexet Ultimate DLP system for GDPR compliance.