Cloud Compliance: The Five Issues That Derail IT Audits

Audits are not supposed to be surprises. The best compliance teams I've worked with run their own internal audits every quarter, catch the findings themselves, and hand the external auditors a clean environment. The worst treat the audit as a yearly fire drill, scramble to fix things in the two weeks before the visit, and discover the same findings again the next year.

After helping customers through SOC 2, HIPAA, PCI, CJIS, ISO 27001, and various state-level audits, I've noticed the same five issues come up in nearly every cloud environment. If you can find and fix them yourself, you will walk into your next audit calmer, cheaper, and better-prepared than most of your peers.

Issue One: Identity Sprawl With Forgotten Access

This is the finding that shows up in every audit. A user who left the company six months ago still has an active account. A contractor whose engagement ended a year ago still has SSH access to a production VM. A developer who moved to a different team still has admin on systems they should no longer touch. A service account used for a project that was canceled still has credentials stored somewhere and still has permissions in IAM.

The reason this finding persists is that most organizations do not have a clean join/move/leave process for identity. HR systems, IT provisioning, and the 30 SaaS applications that a modern employee uses are loosely coupled at best. Offboarding often misses two or three systems, and those are the ones the auditor finds.

How to fix it on your own:

• Run a quarterly access review that compares every account in every system against the HR roster.
• Put every SaaS application behind SSO so deactivating one identity closes most doors automatically.
• Set expiration dates on contractor access at creation, not at offboarding.
• Audit service accounts every quarter — who owns it, what does it do, is it still needed, when was its credential last rotated.

Doing this for one quarter is painful. Doing it every quarter takes a few hours and keeps the audit clean.

Issue Two: Logging That Exists But Isn't Actually Useful

The auditor asks, "Do you log administrative actions in your cloud environment?" The answer is usually yes. The auditor asks, "Can you show me who modified the firewall rule for this production subnet on March 12?" The answer is sometimes no, because the logs exist but they're in five different places, none of them retained long enough, and nobody has queried them in months.

Compliance logging has three requirements that each need to be true independently:

• Completeness: every administrative action in every service is captured. Cloud native audit logs (CloudTrail, Azure Activity Log, GCP Audit Logs) need to be enabled across all accounts, subscriptions, and regions. Missing regions are where auditors love to find gaps.
• Retention: long enough for your specific compliance framework. Most require at least one year; some require seven. Native cloud audit retention defaults are usually not enough — you need to export to object storage with lifecycle policies.
• Accessibility: you can actually search them. A log you can't query within 15 minutes is not usable during an incident, and the auditor will ask you to demonstrate the search.

The fix is to build a small but complete log architecture — enabled everywhere, exported to immutable storage with the right retention, and fed into a search tool (SIEM, Sentinel, Chronicle, or even a well-structured S3 + Athena setup). This is boring work. It's also the work that turns a bad audit into a boring one.

Issue Three: Encryption Gaps and Key Management

"Is your data encrypted at rest?" is almost always answered "yes." "Show me." is where it gets interesting. Most cloud providers enable encryption by default on storage services now, but there are still pockets where encryption isn't on, where it's on but uses provider-managed keys when the standard requires customer-managed keys, or where the keys are stored in ways the framework doesn't allow.

The second, harder question is key management. Who can access the keys. Who can export them. Who can delete them. How are they rotated. What's the backup if the key management service goes down. Auditors who specialize in cloud environments ask these questions, and they should.

How to audit your own environment:

• Run a compliance scanner (AWS Config conformance packs, Azure Policy, GCP Security Health Analytics) against an encryption-specific baseline.
• List every customer-managed key and verify that the access policy grants only what's needed.
• Document key rotation schedules and verify that they're happening.
• Specifically check data categories that shouldn't exist but sometimes do: database snapshots, backup vaults, dev/test environments, and analytics sandboxes.

Issue Four: Network Exposure That Nobody Documented

Every cloud environment accumulates network exposures over time. A security group that was opened for a troubleshooting session and never closed. A load balancer pointing to an old test environment. A storage bucket with public read enabled because a vendor needed temporary access. A VPN peering that was set up for a project that's been dead for a year.

These are not always vulnerabilities, but they are always findings. The auditor wants to see that every externally reachable surface is justified, documented, and reviewed.

Run a quarterly external attack surface review. Every public IP, every 0.0.0.0/0 rule, every internet-facing storage endpoint should be on a list with a name next to it explaining why it exists. Anything without a justification gets closed. This is genuinely simple to run with tooling (Censys, Shodan, or the cloud-native inventory features), and it tends to find three to five things worth fixing every quarter.

Issue Five: Change Control That Doesn't Match Reality

Every compliance framework wants to see change control: proposed changes are reviewed, approved, tested, and logged. Most organizations have a change-control process that lives on a wiki and a completely different process that happens in practice, where engineers ship changes through infrastructure-as-code pipelines and the paperwork gets reconstructed at audit time.

The gap between documented and actual process is the finding. Auditors can tell.

The fix is not to add more paperwork. The fix is to make your actual workflow generate the evidence the auditor needs, automatically. If you're using Terraform with pull requests and an approval requirement, that's your change control — write the policy to describe that, not an idealized process that nobody follows. Infrastructure-as-code pipelines are genuinely excellent change control when you lean into them. They are also terrible change control when you pretend they aren't happening.

Bonus: The Evidence Package Problem

This isn't a compliance issue so much as an audit fire-drill cause. The actual evidence the auditor asks for — screenshots, exports, attestations, logs — gets gathered from scratch every year, by people who weren't around last year, with no templates and no automation.

Build an evidence library. For every control in your framework, document what evidence proves it, where that evidence lives, and how to generate a fresh copy. Keep the library updated as the framework evolves. The first time you do this it's a real project. Every time afterward it saves weeks.

How We'd Run the Quarterly Self-Audit

If I were a compliance officer in a mid-size cloud environment, here's the cycle I'd run every quarter:

• Month 1, Week 1: Identity review. Every user, every group, every service account, cross-referenced against HR and active projects.
• Month 1, Week 2: Logging and retention check. Are logs enabled everywhere, is retention correct, is the search tool indexing what it should.
• Month 2, Week 1: Encryption and key management review. Scanner run, key policies verified, rotation checks.
• Month 2, Week 2: External exposure review. Attack surface scan, 0.0.0.0/0 rules, public buckets, DNS records.
• Month 3, Week 1: Change control and infrastructure-as-code audit. Does the actual process match the documented one.
• Month 3, Week 2: Update the evidence library with anything new.

That's 12 weeks of about two days' work each. In exchange you walk into your annual audit with almost no surprises.

Three Takeaways

1. The same five findings come up in every cloud audit. They are findable on your own schedule if you know where to look.
2. Identity hygiene is the biggest compliance lever you have. Clean joiners, movers, and leavers processes solve more findings than any other control.
3. Audit yourself quarterly and the annual audit gets boring. Boring is the goal.