Cloud account structure for audits
The account structure decides how much of your cloud an auditor has to look at. Put production in its own accounts and the audit scope follows the boundary.
A small company needs five accounts, subscriptions or projects to have an audit-friendly structure: a management root that nobody uses day to day, a security account for monitoring tools, a log archive, production, and non-production. Larger estates split production by product or tenant and add shared services. The rule is that production data and production access live only inside production accounts.
The minimum structure
| Account or equivalent | Purpose | Who has access |
|---|---|---|
| Management or root | Billing, organization policies, identity federation | Two or three administrators, MFA, rarely used |
| Security | Delegated admin for GuardDuty, Security Hub, Defender or SCC | Security staff |
| Log archive | Immutable audit logs from every account | Security staff, read-only |
| Production | Customer-facing workloads and customer data | Pipeline identity, small operator group, just-in-time admin |
| Non-production | Development and staging | Engineers |
On AWS these are accounts in an organization with organizational units. On Azure they are subscriptions under management groups. On Google Cloud they are projects under folders, with logging and security projects of their own.
Why structure matters to the audit
- Scope. The system description can name the production accounts. Development accounts may be out of scope, which reduces what an auditor samples.
- Access evidence. "Who can reach production" becomes a list of assignments on a few accounts instead of a list of policies across one mixed account.
- Guardrails. Organization-level policies apply to every account, so controls like region restriction and logging cannot be disabled locally.
- Blast radius. A compromised development credential cannot touch production data.
Production data outside production
Copying production databases into staging for testing puts customer data in an environment with wider access, which puts staging in scope or produces a finding. Use synthetic or masked data outside production, and write that rule into the data classification or secure development policy.
Moving from one account to many
- Create the organization and the new structure alongside the existing account.
- Set up identity federation and logging for the new accounts first.
- Decide which account keeps production. Often the original account becomes production and non-production moves out, because moving production is the riskier migration.
- Move non-production workloads, then tighten access on what remains.
- Finish before any Type 2 observation window opens. Structural change during a window creates exceptions to explain.
The AWS landing zone and Azure landing zone guides cover the tooling that automates this.
How many AWS accounts does a startup need for SOC 2?
Four or five: management, security, log archive, production and non-production. That is enough to separate duties, protect logs and keep development access away from customer data. More accounts follow growth, not the audit.
Can we pass SOC 2 with everything in one AWS account?
It is possible with careful IAM, but harder. Every engineer's access has to be scoped away from production resources inside the same account, and the auditor will test that closely. Splitting accounts is usually less work than proving the single account is safe.
Are development accounts in SOC 2 scope?
Usually not, if they hold no customer data and cannot reach production. Your system description defines the boundary. The pipeline that deploys to production is in scope wherever it runs.
Need your accounts restructured?
Firms in the network plan and run the split before the audit window.
Get matched