A SOC 2 audit tests whether the controls you say you have actually operated over a period of time. It is, before it is anything else, an evidence problem. The auditor is not grading your architecture. They are asking a narrow question — show me that this control was working on these dates — several hundred times, and writing down whether you could.
That framing changes what infrastructure is for in an audit. The useful question is not “is our cloud secure enough to pass”. It is “what does our cloud produce, by itself, that answers an auditor’s question without anyone taking a screenshot?”
Readiness is not certification
This distinction is worth being pedantic about, because the market blurs it constantly.
- Readiness means the controls exist, operate continuously, and generate records you can produce on demand. It is engineering work. It can be delivered, inherited or bought.
- Certification — strictly, an attestation report — is a licensed auditor forming an opinion after testing those controls. It covers your organization, not your infrastructure: policies, onboarding, vendor management, background checks, incident response and the humans who run all of it.
No product makes you certified. A product can make the evidence trivial to produce, which removes most of the cost and nearly all of the panic. That is the honest claim, and it is the only one we make.
The two-week screenshot scramble, and why it happens
The familiar failure looks like this. Four weeks before fieldwork, someone opens a spreadsheet of control requests. Engineers start logging into consoles, screenshotting settings, exporting user lists, and pasting them into a shared drive. A week is lost. The screenshots prove the setting was true on the day it was taken, which is the one thing a Type II audit is not asking.
The cause is structural, not a discipline problem. If evidence is something you collect, collecting it will always be a project. If evidence is something the system emits, the audit becomes a query. The difference is whether the recording was switched on before the period started.
The evidence sources worth building first
Six sources answer most of what an auditor asks. Each is a capability, not a product, and every major cloud has an equivalent.
| Evidence source | The questions it answers | Why an auditor accepts it |
|---|---|---|
| Immutable API audit log | Who did what, where, when, from which identity | Complete, timestamped, and outside the control of the person being tested |
| Configuration recorder and history | Was this resource configured correctly throughout the period | Shows state over time, not on the day of the screenshot |
| Continuous control checks | Which controls are passing right now, and which drifted | Turns a control into a measurement with a history |
| Identity and access records | Who had access, when it was granted, when it was revoked | Directly answers the largest control family in the framework |
| Threat detection findings | Were anomalies detected, triaged and resolved | Evidence of monitoring and of response, which is usually the weaker half |
| Version control and review history | What changed in the environment, who approved it, when it shipped | Change management evidence, produced as a by-product of doing the work |
The last row is the one teams underestimate. If every infrastructure change is a reviewed pull request applied by a pipeline, your change management evidence already exists, in order, with approvals attached, for the entire period. No separate change log to maintain and no reconciliation between what the log says and what actually happened.
Make the log archive untouchable
One control deserves special attention because auditors probe it and incidents depend on it: the integrity of the audit log itself.
Logs that can be deleted by the same identity that operates the system are weak evidence, and worse, they are weak forensics. Three properties make the difference:
- The archive lives in a separate account from the systems it records, with access limited to a small number of principals.
- Stopping or deleting the logging configuration is denied at the organization level, above every account, so it is not a matter of nobody choosing to do it.
- Integrity validation is enabled, so tampering is detectable rather than merely discouraged.
In the AWS Enterprise Baseline, that is how the audit account is set up: an organization-wide multi-region CloudTrail with log file validation and customer-managed encryption keys, delivered into a dedicated log archive account, with a service control policy that denies stopping or deleting CloudTrail and Config anywhere in the organization. Those specifics describe the AWS edition; the property is part of the BuiltForProd Standard in every edition.
Give auditors access — to the configuration, not the data
Auditors need to verify that controls are in place. That is a configuration question. It is not a reason for them to be able to read your customers’ records.
The pattern that works is a dedicated read-only role with an explicit denial on data-plane reads: they can see that a storage bucket is encrypted, that a database requires TLS, that access reviews happened. They cannot open the objects or query the rows. This is easier to grant, easier to defend to your own customers, and it makes the access review of your auditors uneventful.
What “ready” looks like in practice
Some numbers from the AWS edition, offered as a worked example rather than a target. The AWS Enterprise Baseline ships a SOC 2 baseline conformance pack enabled by default — thirteen automated configuration rules mapped to specific Trust Services criteria — with a further twenty-eight conformance pack templates behind a single flag each, covering frameworks including HIPAA, PCI DSS 4.0, NIST CSF, CMMC 2.0 and CIS Controls. Eleven frameworks have documented control mappings. The deployment itself finishes with seventeen verification checks mapped to SOC 2 controls, run twice, and the handover includes a quarterly evidence-snapshot procedure and a monthly compliance checklist.
Two honest caveats. Most of those packs ship off, because they cost money to run and the right set depends on which frameworks you are actually in scope for; each switch states its price next to it so the decision is informed rather than surprising. And a mapped control is not a passing control — the mapping tells you where to look, and the finding tells you whether you are there.
A sequence that works
If you are starting from a single cloud account and a deadline, this order produces evidence fastest:
- Turn on the recorders. Audit logging, configuration history, threat detection. Do this first, today if possible: the clock on your observation window starts when they do, and nothing else you do this quarter matters as much.
- Fix identity. Single sign-on, no long-lived credentials, defined roles, and a revocation path that actually revokes. This is the largest control family and the one where evidence is hardest to fake. We wrote about the credential half of it in zero long-lived cloud credentials.
- Route every change through review. Infrastructure as code with pull requests and an approval gate on production. Your change management evidence then generates itself.
- Separate the log archive and deny anyone the ability to stop it.
- Map controls to the framework and let the continuous checks tell you what is failing, rather than discovering it during fieldwork.
- Rehearse. Pull a quarter’s evidence as though the auditor asked. Whatever takes more than an hour is a gap.
Steps one through three cover a surprising share of what gets tested, and all three are things you want anyway.
The part infrastructure cannot do
Your report will also cover policies, employee onboarding and offboarding, security awareness training, vendor risk, business continuity and incident response. None of that lives in a cloud account. A compliance automation platform helps track it, and a good auditor will tell you where the gaps are early if you ask them early.
What infrastructure can do is make its own half boring — so that the week before fieldwork is spent on the human controls, which is the half that usually needs the attention.
If you want the infrastructure half handled as part of building the foundation rather than as a project afterward, that is what the BuiltForProd Baseline does, and SOC 2 readiness is the situation it is most often bought for.