Compliance · SOC 2 · Type 2

How to pass SOC 2 Type 2: a practical roadmap

Sahil Dubey

CISA · AWS Solutions Architect Professional · 27 Jul 2026

Type 2 isn't a test you cram for - it proves your controls operated over months. Here's the sequence that gets you to a clean report without a fire drill.

Type 1 vs Type 2 in one line

Type 1 says your controls are designed correctly at a point in time. Type 2 proves they actually operated over a period — commonly three to twelve months. Type 2 is what most enterprise buyers want, and you can't cram for it: the evidence is generated by controls running day after day.

The roadmap

1. Scope and select criteria

Decide which Trust Services Criteria apply. Security (the Common Criteria) is mandatory; add Availability, Confidentiality, Processing Integrity or Privacy only if they're relevant to your service.

2. Gap assessment

Compare current state to the criteria and produce a prioritised gap register. This is where you learn how far off you really are.

3. Remediate and implement in AWS

Turn gaps into real controls: least-privilege IAM and MFA, KMS encryption, CloudTrail and Config, change management through a reviewed CI/CD pipeline, backups with tested restore.

4. Automate evidence

Wire controls so they emit evidence automatically — access reviews, pipeline logs, config snapshots — instead of screenshotting things the night before fieldwork.

5. Pick the observation window

Choose the window (often three to six months for a first Type 2). Controls must operate for the whole period.

6. Operate and monitor

Run the controls, catch drift, remediate on an SLA. Consistency over the window is what the auditor tests.

7. Auditor fieldwork

The auditor samples evidence across the window and writes the report. Clean evidence collected all along makes this fast.

The controls auditors actually check

Domain	AWS control	Evidence
Access	IAM least-privilege, MFA, SSO	Access-review exports, no long-lived keys
Change mgmt	Reviewed CI/CD, IaC	Pipeline logs, PR approvals
Monitoring	CloudTrail, Config, GuardDuty	Log retention, alerts fired
Encryption	KMS at rest & in transit	Key policies, TLS config
Resilience	Backups + tested restore	Backup schedule, restore test

Why teams fail (or stall)

• Treating it as a document exercise while the account tells a different story.
• Collecting evidence manually and burning out before the window ends.
• Controls that work in one region but are switched off in another.
• No one owning remediation, so drift accumulates.

My take

The teams that pass Type 2 the first time don't work harder during fieldwork — they front-loaded the controls and automated the evidence, so the observation window ran itself. Build it right once, then let it operate.

Want the gap register for your stack?

I'll assess your AWS environment against the Trust Services Criteria and hand you a prioritised remediation plan.

SOC 2 consulting →Book a free call

The window is the defining feature of a Type 2 and the part teams handle worst, largely because nothing appears to happen during it.

Length is negotiable within limits. Three months is the shortest most auditors will accept for a first report and some buyers regard it as thin. Six is the common choice. Twelve carries the most weight and delays your first report by most of a year. For an initial report six months is usually the right trade, moving to twelve on the annual cycle afterwards so each report follows the last without a gap.

What matters far more than length is that controls are genuinely operating on day one of the window. A window opened optimistically — with a control configured but not yet producing artefacts, or a process agreed but not yet followed — accumulates exceptions that you cannot retroactively fix. You can remediate a control mid-window, but the failure period stays in the report.

During the window the work is unglamorous and non-negotiable: the access reviews actually happen on schedule, the restore test actually gets run, the training completion actually gets recorded. Reviewing evidence monthly rather than discovering its absence at fieldwork is the difference between a clean report and a set of explanations.

An exception is the auditor recording that a control did not operate as described for some part of the period. Teams treat this as failure; buyers mostly do not, and the distinction is worth understanding before you panic.

Exceptions vary enormously in weight. A training completion recorded four days late is noise. Privileged access granted outside the documented process and not caught by review is material, because it undermines the control that most other controls depend on. What a sophisticated buyer assesses is severity, whether it was self-detected, and what you did about it.

That last point is where you have agency. An exception you found through your own monitoring and remediated with a dated record reads very differently from one the auditor discovered. The former demonstrates the control environment working; the latter suggests nobody was watching. If something goes wrong mid-window — and over six months something usually does — document the detection, the response and the fix contemporaneously rather than reconstructing it later.

Management responses accompany exceptions in the report. Write them plainly: what happened, why, what changed. Defensive or vague responses do more damage than the exception itself.

Fieldwork is where the report gets built, and knowing its shape removes most of the anxiety.

It opens with a request list — often a hundred-plus items — covering policies, system descriptions, population lists and evidence samples. The population lists matter more than people expect: the auditor asks for every change, every access grant, every incident in the period, then samples from them. An incomplete population is a problem in itself, so make sure you can produce complete lists before you are asked.

Then sampling and walkthroughs. The auditor picks specific items and asks you to demonstrate the control operated for each. Expect to walk through a change from ticket to deployment, an onboarding from request to access granted, and an access review from trigger to outcome. They will also interview engineers — briefly, and about how things actually work rather than what the policy says. Prepare people by telling them to answer honestly and say "I don't know, let me find out" rather than guessing, since a confident wrong answer creates a discrepancy that takes far longer to resolve.

Then follow-ups, draft report, management responses, and issuance. Budget several weeks from fieldwork start to a report in hand, and expect the follow-up round to need real attention rather than trailing off.

The first report is a project; every one after should be an operating rhythm. If year two costs nearly what year one did, something is wrong with how evidence is produced.

The compounding assets are the ones built into systems: evidence emitted by pipelines and cloud services rather than assembled by people, a scope that has stayed stable, policies that describe real behaviour so they need editing rather than rewriting, and an auditor relationship where expectations are already calibrated. The recurring cost that does not compound is anything a human has to remember to do.

Windows should also abut rather than restart. If your first report covers January to June and the second covers the following January to December, you have a gap, and buyers reading both will notice it. Plan the second window to begin where the first ended.

The one thing that genuinely resets year two is a material architecture change — a new product line, a migration, an acquisition. Those need scope reassessment early rather than a discovery during fieldwork.