Compliance in the Cloud

Moving to the cloud changes everything about how you think about compliance.

On-prem, you controlled the entire stack. You knew which rack your server lived on, who had the key to the data center, and exactly which firewall rules sat between your application and the internet. Compliance was hard, but the boundaries were clear.

In the cloud, those boundaries dissolve. Your infrastructure lives in someone else's data center. Your data might be replicated across regions you've never visited. Your "network perimeter" is a set of IAM policies and security group rules — not a physical wall.

That shift doesn't make compliance harder. It makes it different. The controls change shape. The evidence looks different. The auditor's questions shift from "show me your firewall configuration" to "show me your cloud security posture management dashboard."

If you're pursuing SOC 2, ISO 27001, or another framework while running workloads in AWS, Azure, or GCP — this guide breaks down how to approach cloud compliance without drowning in complexity.

☁️ The Shared Responsibility Model

Every cloud provider publishes a shared responsibility model. Understanding it is the single most important step in cloud compliance. The concept: the provider secures the cloud, you secure what's in the cloud.

What your cloud provider handles:

Physical security of data centers
Hardware maintenance and replacement
Network infrastructure and backbone
Hypervisor and host OS security

What you own:

Identity and access management configuration
Data encryption decisions (at rest and in transit)
Network configuration (security groups, NACLs, VPCs)
OS patches on your VMs (IaaS)
Application-level security
Data classification and handling
Logging, monitoring, and alerting

The tricky part is the gray area. With managed services like RDS or Lambda, the provider handles more infrastructure, but you still own the configuration. A misconfigured S3 bucket with public read access isn't AWS's problem. It's yours.

Auditors know this. They won't accept "AWS handles that" as an answer unless you can articulate which controls fall on each side of the line — and prove you're fulfilling your half.

🔐 Cloud-Specific Controls That Auditors Look For

When an auditor reviews your cloud environment, they focus on a consistent set of control areas. The concepts aren't new, but the implementation and evidence are cloud-native.

IAM and Access Management

Cloud IAM is both more powerful and more dangerous than traditional access control. A single overprivileged role can expose your entire infrastructure. Auditors want to see:

Least-privilege access: Roles and policies scoped to the minimum permissions needed
MFA enforcement: Especially for console access and privileged accounts
Regular access reviews: Quarterly reviews showing who has access — and proof stale accounts get removed
Service account hygiene: No long-lived credentials, rotation policies in place, cross-account access documented
Break-glass procedures: Documented emergency access that doesn't permanently weaken your posture

Encryption at Rest and in Transit

Most managed services offer encryption at rest by default. But "default" isn't always sufficient for compliance. Key areas to document:

Encryption at rest: Which KMS keys you use, who has access, rotation policies
Encryption in transit: TLS versions enforced, certificate management, service-to-service encryption
Key management: Who can create, rotate, and delete keys — and is that audited?

Logging and Monitoring

If something goes wrong and you don't have logs, it didn't happen — at least not in a way you can prove to an auditor. Essential controls:

CloudTrail / Activity Log / Audit Log: Every API call should be logged and retained
Centralized log aggregation: Logs from all accounts and regions in a single, tamper-resistant location
Alerting on high-risk events: Root account usage, security group changes, IAM policy modifications
Retention policies: Most frameworks require 90 days to one year of log retention

Network Segmentation

The cloud equivalent of network segmentation is VPC architecture and security group design. Auditors want to see that production is isolated from development, databases aren't publicly accessible, and traffic flows are documented. Key evidence:

VPC diagrams showing segmentation between environments
Security group rules with clear justification for each allowed flow
Private subnet usage for databases and internal services
Network flow logs enabled and reviewed

Data Residency

Where your data physically lives matters — especially for GDPR or customers in regulated industries. You need to know which regions your resources are deployed in, whether replication crosses borders, and whether your backup strategy respects residency requirements.

This is particularly important for SaaS companies serving enterprise customers. A Fortune 500 prospect will ask where their data lives. If the answer is "I'm not sure," that deal is over.

🌐 Multi-Cloud Challenges

Running workloads across AWS, Azure, and GCP is increasingly common. Maybe you acquired a company on a different provider, or your engineering team chose the best tool for each job. Either way, multi-cloud makes compliance harder.

Inconsistent terminology: AWS calls it a "Security Group." Azure says "Network Security Group." GCP says "Firewall Rule." Same concept, different names, different configuration surfaces.
Fragmented visibility: Logging, IAM, and encryption controls are configured separately in each provider's console. No single pane of glass by default.
Policy drift: A security policy enforced in AWS might not have an equivalent rule in Azure. Without continuous checks, the drift compounds.
Evidence collection complexity: Auditors want one coherent story. They don't care that you have three clouds — they want to see the same controls exist everywhere.

The fix is standardization at the policy layer. Define your control requirements once — "all data at rest must be encrypted with customer-managed keys" — then map that to the specific implementation in each provider. Review for drift regularly.

This is where having a solid evidence library that scales across providers pays off. Organize evidence by control, not by cloud. The auditor cares about what you're doing, not which console you did it in.

🔍 Continuous Monitoring vs Point-in-Time Audits

Traditional compliance was a point-in-time exercise. The auditor showed up, you scrambled to gather evidence, they checked boxes, and everyone breathed a sigh of relief until next year.

Cloud compliance doesn't work that way. Here's the uncomfortable truth: a point-in-time audit in a cloud environment is almost meaningless.

Cloud infrastructure changes constantly. A developer can spin up a new instance, open a port, or create a public S3 bucket in seconds. Your environment at 9 AM might not match it at 3 PM. A passing audit in January means nothing if someone misconfigured a security group in February.

SOC 2 Type II and ISO 27001 surveillance audits increasingly expect to see evidence of continuous monitoring — not just a snapshot from audit day.

What continuous monitoring looks like in practice:

Cloud Security Posture Management (CSPM): Tools that continuously scan your configuration against a baseline and alert on deviations
Automated compliance checks: Policies defined as code that evaluate infrastructure on a schedule
Drift detection: Alerts when a resource configuration changes from its compliant state
Dashboard visibility: A real-time view of compliance posture across all environments

The shift from "audit-ready" to "always-ready" is significant but liberating. When continuous monitoring is in place, audit season stops being a fire drill. The evidence is already there. You're not scrambling — you're presenting. episki's compliance dashboard gives you this real-time view across every cloud and framework you manage.

🛠️ Cloud-Native vs Third-Party Compliance Tools

AWS has Security Hub and Config. Azure has Defender for Cloud. GCP has Security Command Center. These tools are powerful, well-integrated, and often free. So why would you ever need anything else?

Cloud-Native Tools: The Good

Deep integration: They see everything in their environment without API keys or agents
Low latency: Findings show up fast because they're built into the platform
Cost-effective: Often included in your existing cloud spend
Framework benchmarks: Pre-built rules for CIS benchmarks, SOC 2 controls, and more

Cloud-Native Tools: The Gaps

Single-cloud view: AWS Security Hub doesn't know about your Azure environment
No cross-framework mapping: They check individual rules, not your program's control structure
Limited evidence management: They surface findings but don't help you present evidence to an auditor
No workflow layer: They tell you what's wrong but don't track who's fixing it or when

Third-Party Tools: When They Make Sense

Third-party platforms fill the gaps — aggregating findings across providers, mapping them to control frameworks, and adding the workflow layer for ownership, deadlines, and auditor collaboration.

The sweet spot: cloud-native tools for detection, third-party tools for program management. Let AWS Config and Azure Policy surface misconfigurations. Use your compliance platform to map findings to controls, assign remediation, and build the evidence package your auditor expects.

This is the approach episki takes. Rather than replacing your cloud-native security tools, episki sits on top of your compliance program — giving you control mapping across frameworks, evidence tracking, and a unified view across every cloud and framework you manage.

🏗️ Building Your Cloud Compliance Stack

Here's a practical stack that works for growing teams:

Layer 1: Cloud-Native Security Baseline

Enable CloudTrail / Activity Logs / Audit Logs in every account and region
Turn on default encryption for all storage services
Enforce MFA for all human users
Deploy a CSPM tool for continuous misconfiguration scanning
Enable network flow logs for production VPCs

Layer 2: Policy and Control Framework

Define your control set based on your target framework(s)
Map each control to specific cloud configurations and evidence artifacts
Assign one owner per control
Document your shared responsibility model decisions

Layer 3: Evidence and Workflow

Build an evidence library organized by control, not by cloud provider
Set collection cadences and expiration dates for every artifact
Automate collection where possible (API exports, scheduled reports)
Create a remediation workflow: finding, assignment, fix, verification, evidence

Layer 4: Continuous Improvement

Review compliance posture monthly, not just at audit time
Track metrics: mean time to remediate, evidence freshness, control coverage
Run tabletop exercises for cloud incident response
Update control mappings when frameworks release new versions

The companies that do this well aren't the ones with the biggest security teams. They're the ones with repeatable systems. A two-person team with a structured program will outperform a ten-person team that's winging it.

Key Takeaways

Understand the shared responsibility model — know which controls are yours vs your provider's
Cloud controls need cloud evidence — IAM policies, encryption configs, and audit logs replace physical security screenshots
Multi-cloud means extra work — standardize at the policy layer, organize evidence by control
Continuous monitoring beats point-in-time audits — cloud environments change too fast for annual snapshots
Cloud-native tools are necessary but not sufficient — pair them with a platform that handles cross-framework mapping and workflow
Build in layers — security basics first, then control structure, then evidence automation

Cloud compliance isn't a one-time project. It's a system you build and refine as your infrastructure evolves. The good news? Once the system is in place, every new cloud account, framework, and audit gets easier — not harder.

Ready to bring structure to your cloud compliance program? episki gives you cross-framework control mapping, evidence tracking with freshness alerts, and a unified view across every cloud you run. Start your free trial