Public cloud compliance is the practice of proving that the workloads you run on AWS, Azure, GCP, or another provider meet a defined set of security and regulatory requirements, and the single most important thing to understand about it is that responsibility is shared. The provider secures the infrastructure; you secure what you put on it. Most compliance failures in the cloud are not the provider's fault and not exotic — they are a customer misconfiguring something the provider explicitly told them they own. Getting the boundary right is where public cloud compliance begins.
The shared responsibility model in plain terms
Every major cloud provider publishes a shared responsibility model, and they broadly agree. The provider is responsible for the security of the cloud: physical data centers, the hypervisor, the network backbone, and the managed services' underlying infrastructure. You are responsible for security in the cloud: your data, your access controls, your operating system patches (on anything that is not fully managed), your network configuration, and your application code.
The line shifts depending on the service model. Run a virtual machine (IaaS) and you own the OS, the runtime, and everything above it. Use a managed database (PaaS) and the provider patches the engine, but you still own the schema, the access grants, and whether it is exposed to the internet. Use a SaaS product and your surface shrinks to identity, data, and configuration. The mistake teams make is assuming "managed" means "the provider handles compliance," when in reality it just moves the line, not the obligation.
Which frameworks actually apply to you
There is no single "cloud compliance" standard. You inherit obligations based on what you do and who your customers are:
- SOC 2 is the default for B2B SaaS. It is an attestation against the Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy), and most enterprise buyers ask for a SOC 2 Type II report before they sign.
- ISO 27001 is the international information-security management standard, common when you sell outside the US.
- PCI DSS applies if you store, process, or transmit cardholder data.
- HIPAA applies to protected health information in the US.
- FedRAMP applies if you sell to US federal agencies, and it is substantially stricter than commercial baselines around cryptography, data residency, and continuous monitoring.
- GDPR and other privacy regimes apply based on where your users live, not where you are.
You do not pick one. A mid-size SaaS company selling to enterprises and handling payments might carry SOC 2, PCI DSS, and GDPR obligations simultaneously. The good news is that the underlying controls overlap heavily — strong access management, encryption, logging, and change control satisfy pieces of all of them at once.
The controls that show up in every framework
Whatever the specific standard, auditors keep asking about the same handful of things. Get these right and most of a cloud audit is downhill.
Identity and access management. Least privilege, enforced MFA, no long-lived root or admin keys, and regular access reviews. Over-permissioned IAM roles are the most common cloud audit finding and the most common real-world breach vector.
Encryption. Data encrypted at rest (provider-managed keys are usually acceptable; customer-managed keys score better) and in transit with modern TLS. FedRAMP and some others require FIPS-validated cryptography specifically, so read the fine print.
Logging and monitoring. Centralized, tamper-resistant audit logs (CloudTrail, Azure Monitor, Cloud Audit Logs) retained for the period the framework demands, with alerting on anomalous activity. An auditor will ask you to produce logs from a date they choose; if you cannot, the control fails.
Configuration management. Baselines for how resources should be configured, drift detection, and infrastructure-as-code so that changes are reviewable and reproducible. A public S3 bucket or an open security group is a configuration failure, and it is the single most-cited cause of cloud data exposure.
Vulnerability management. Knowing what software runs in your workloads and remediating known CVEs on a defined timeline. This is where your software supply chain intersects with cloud compliance — a container image full of unpatched dependencies is a compliance gap even if the cloud config is perfect.
From point-in-time audit to continuous compliance
The old model was to scramble for two weeks before an annual audit, collect screenshots, and hope. That does not survive a SOC 2 Type II, which examines whether controls operated effectively over a period (usually 6 to 12 months), not on the day the auditor looked.
Continuous compliance means the evidence is generated as a byproduct of doing the work correctly. Infrastructure-as-code gives you a reviewable change history for free. Automated configuration scanning (AWS Config, Azure Policy, GCP Security Command Center, or a third-party CSPM) proves controls are enforced, not just documented. Dependency scanning in CI produces a running record that you remediate vulnerabilities on schedule. When the audit arrives, you export a report instead of hunting for screenshots.
Software supply chain evidence is an underrated part of this. Frameworks increasingly expect you to know what is in your software — a software bill of materials, a vulnerability remediation record, and a policy gate that blocks non-compliant builds. An SCA platform such as Safeguard can produce that evidence continuously, which turns "prove you manage vulnerabilities" from a fire drill into an export. If you are early in a SOC 2 journey, our academy has structured material on building these controls from scratch.
Common ways public cloud compliance goes wrong
The failures cluster in predictable places. Teams assume the provider handles something they own. They enforce a control in production but not in the staging account that also holds real data. They document a policy nobody follows, which is worse than no policy because it demonstrates the gap to an auditor. And they treat compliance as a one-time project rather than an operating discipline, so controls decay between audits.
The fix for all of these is the same: make the compliant path the default path. When the secure configuration is the one your infrastructure-as-code produces automatically, and the vulnerability gate is wired into the pipeline everyone already uses, compliance stops being a separate effort and becomes what "shipping normally" looks like.
FAQ
What is the shared responsibility model?
It is the division of security duties between a cloud provider and its customer. The provider secures the underlying infrastructure (physical, network, hypervisor, managed-service internals) and the customer secures what they run on it (data, access, configuration, and code). The exact line shifts between IaaS, PaaS, and SaaS.
Which compliance framework should a cloud SaaS start with?
SOC 2 is the usual starting point for B2B SaaS because enterprise buyers routinely require a SOC 2 Type II report. You may also inherit PCI DSS, HIPAA, ISO 27001, FedRAMP, or GDPR obligations depending on your data and customers.
Does using managed cloud services make me compliant automatically?
No. Managed services move the responsibility boundary but do not remove your obligations. You still own identity, data, configuration, and often the application-level vulnerability posture, all of which auditors examine.
How does software supply chain security relate to cloud compliance?
Most frameworks require you to know what software runs in your workloads and to remediate known vulnerabilities on a defined timeline. A software bill of materials, dependency scanning, and a policy gate produce the evidence auditors ask for, so supply chain controls are a direct input to cloud compliance.