Common cloud audit findings
The same dozen cloud findings come up in audit after audit. None is exotic. Most take a day to fix and months to evidence, which is why they belong before the window opens.
The cloud findings auditors raise most often are about access and evidence, not exotic attacks: people signing in without MFA or with long-lived keys, departed staff still holding access, audit logs not kept for the whole period, production and development sharing an account, security alerts nobody triaged, and backups that were never restored. Fix them before the observation window opens, because the fix only counts from the day it was made.
| Finding | Why it matters | Fix |
|---|---|---|
| Cloud users without MFA, or root or global admin without MFA | Single stolen password compromises the account | Federate to an IdP enforcing MFA; hardware MFA on root |
| Long-lived access keys or service account keys for people | Keys leak and do not expire | Remove; use federation and workload identity |
| Leavers still have cloud access | Failed deprovisioning, the classic CC6 exception | Access only through the IdP; tie offboarding to IdP removal |
| No access review, or a review with no evidence | Control did not operate | Quarterly review with export, sign-off and removals |
| Audit logs retained less than the audit period | Auditor cannot sample early in the window | Retention set to period plus margin, before the window opens |
| Logs stored where admins can delete them | Evidence can be destroyed | Separate log account, object lock or bucket lock |
| Production and development in one account | Developers effectively have production access | Separate accounts, subscriptions or projects |
| Console changes to production outside the pipeline | Change management bypassed | Pipeline-only write access; emergency change process |
| Security findings open for months | Monitoring existed but was not acted on | Ticket routing, remediation targets, documented exceptions |
| Backups never restored | Recovery capability unproven | Recorded restore test at least annually |
| Public storage or databases | Data exposure | Preventive policy at organization level |
| SSH or RDP open to the internet | Direct attack surface | Session Manager, Bastion or Identity-Aware Proxy |
| Network diagram out of date | System description does not match reality | Diagram maintained with infrastructure code |
Why timing matters more than the fix
A SOC 2 Type 2 tests whether a control operated across the whole period. A finding fixed in month four of a twelve-month window leaves three months of exception. The auditor reports it, and the customer reading your report sees it. The same fix made before the window opens produces a clean result. That is the whole argument for a readiness review before the audit rather than during it.
Provider-specific favourites
- AWS
- CloudTrail in one region only, root access keys still present, unencrypted RDS instances created years ago, IAM users for people. See SOC 2 on AWS.
- Azure
- Activity Log retention left at 90 days, standing Owner assignments, old guest accounts, no diagnostic settings on key resources. See SOC 2 on Azure.
- Google Cloud
- Basic Owner or Editor roles on people, projects outside the organization, service account keys, Data Access logs off. See SOC 2 on Google Cloud.
The readiness score checks you against most of this list, and the cloud compliance checklist turns it into a list you can work through.
What is the most common SOC 2 exception in cloud environments?
Access-related exceptions: a departed employee who kept access, an access review that was not performed or not evidenced, or a user without MFA. These are process failures more than technical ones.
Does one exception fail a SOC 2 audit?
No. SOC 2 reports list exceptions, and the auditor may still issue an unqualified opinion if the control objectives were met overall. Buyers do read exceptions, though, and several in one area can lead to a qualified opinion.
Can we fix findings during the observation window?
Yes, and you should. The fix only counts from the day it is made, so the period before it may still show as an exception. Fixing before the window opens avoids that.
Want a readiness review before the window opens?
Firms in the network check your cloud against this list and fix what they find.
Get matched