How to Pass SOC 2 Type 2: A Practical Roadmap (AWS)

Sahil Dubey — Thu, 30 Jul 2026 13:21:28 +0000

Originally published at sahildubey.us

Type 2 isn't a test you cram for — it proves your controls operated over months. After 16 years building AWS platforms and taking them through SOC 2, PCI DSS and ISO 27001 audits (CISA, CISM, AWS Solutions Architect Professional), 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

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.

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.

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.

Automate evidence

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

Pick the observation window

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

Operate and monitor

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

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.

I'm Sahil Dubey — DevOps, cloud & compliance architect (CISA, CISM, AWS SA Pro). Full version with FAQ: How to pass SOC 2 Type 2, more at sahildubey.us.

AWS Compliance Controls Mapping: Services to SOC 2, PCI DSS & ISO 27001

Sahil Dubey — Thu, 30 Jul 2026 13:18:07 +0000

Originally published at sahildubey.us

Engineers think in AWS services; auditors think in controls. The gap between those two languages is where audits stall. After 16 years building AWS platforms and defending them in SOC 2, PCI DSS and ISO 27001 audits (I'm a CISA-certified auditor and AWS Solutions Architect Professional), here's how the core AWS building blocks map to the frameworks — and, just as important, the evidence each one has to produce.

The mapping

AWS component	Satisfies (SOC 2 / PCI / ISO)	Evidence an auditor asks for
IAM + Identity Center + IRSA	CC6.1–6.3 / PCI 7,8 / A.9	Access-review export, MFA policy, no long-lived keys
VPC + private subnets + SG/NACL	CC6.6 / PCI 1 / A.13	Network diagram, SG rules, no 0.0.0.0/0 to sensitive ports
KMS + Secrets Manager	CC6.7 / PCI 3,4 / A.10	Key policies, rotation config, encryption-at-rest proof
CloudTrail + Config + GuardDuty	CC7.2–7.3 / PCI 10 / A.12	Log retention, tamper-evidence, alert routing
CodePipeline + Checkov/OPA gate	CC8.1 / PCI 6 / A.14	Pipeline definition, failed-build evidence, change tickets
RDS + automated backups	A1.2 / PCI 10 / A.12	Backup schedule, tested restore, RTO/RPO doc

The failure modes

These are the patterns that actually fail audits:

Long-lived access keys in CI instead of IRSA or OIDC.
A public RDS endpoint or open SSH to 0.0.0.0/0.
Hardcoded secrets and unmanaged encryption keys.
Logging switched off in one region, so the trail has holes.
Manual production changes with no pipeline gate or ticket.

From mapping to evidence

The point of the mapping isn't the table — it's that each row produces evidence automatically when the control is real. IAM Identity Center emits access reviews; the pipeline emits change records; Config emits drift. Wire those outputs into an evidence store and the audit stops being a scramble.

Does AWS give you compliance out of the box?

No. AWS provides compliant infrastructure under the shared-responsibility model, but you still have to configure and prove the controls in your own account. AWS being compliant does not make your workload compliant.

My take

One well-built AWS control set serves SOC 2, PCI DSS and ISO 27001 at once, because the frameworks overlap far more than they differ. Build the controls to satisfy the strictest requirement, map them to each framework, and you defend three audits with one platform.

I'm Sahil Dubey — DevOps, cloud & compliance architect (CISA, CISM, AWS SA Pro). More at sahildubey.us, including the full version of this piece with FAQ: AWS compliance controls mapping.