SOC 2 Type II Readiness Checklist for AWS-Native Startups

Remove all direct IAM policies from users — attach policies to groups, not individuals. Use groups for job functions (devops, developer, read-only) and assign all permissions through group membership. aws iam list-users --query 'Users[*].[UserName,PermissionsBoundary]' --output table

Enforce MFA on all IAM users — including the root account. Enable MFA for every user with console access; programmatic MFA is optional but recommended. AWS console shows MFA status per user. aws iam list-mfa-devices --user-name <username>

Eliminate wildcard IAM policies — Action: "*" or Resource: "*" is an automatic audit flag. Replace with service-specific actions and ARNs. Use AWS Access Analyzer to find violations. aws access-analyzer list-findings --filter '{"resourceType":[{"eq":["AWS::IAM::Policy"]}]}'

Create an admin role with conditions — break-glass admin role for emergencies, with IP-based conditions and CloudTrail logging on every assume-role event. Separate from day-to-day operations.

Enable IAM Access Analyzer — set to run continuously. It detects when roles grant external access, which is one of the most common SOC 2 findings. Review findings weekly.

Create an onboarding checklist for new employees — defines which groups/roles they get, who approves access, and which systems they need. Every new hire should go through the same process.

Define the offboarding process — AWS IAM user deactivation, GitHub/org access revocation, and Slack/email deprovisioning within 24 hours of departure. Document this in your security policy.

Implement role-based access reviews quarterly — SOC 2 requires you to show you periodically review who has access and whether it's still appropriate. Automate user list export with a timestamp for the auditor. aws iam list-users --query 'Users[*].[UserName,CreateDate,PasswordLastUsed]' --output table

Set up AWS SSO or centralized identity — if you're not using AWS SSO, you likely have IAM users with long-lived access keys. AWS SSO integrates with your identity provider (Google, Okta, Azure AD) and centralizes access governance.

Enable CloudTrail in all regions — multi-region trail with global event logging (e.g., AssumeRole, ConsoleLogin) captures cross-region activity. Enable in every region, not just your primary. aws cloudtrail create-trail --name soc2-trail --is-multi-region-trail --include-global-service-events

Write CloudTrail logs to a dedicated S3 bucket — never the same bucket as application data. Use a separate account (Security Tooling account) for log storage if possible — prevents a compromised application account from altering its own logs.

Enable CloudTrail log file validation — SHA-256 integrity validation detects tampering with log files. Required for SOC 2 evidence integrity. aws cloudtrail update-trail --name soc2-trail --enable-log-file-validation

Set S3 lifecycle on log bucket — SOC 2 typically requires 90-day minimum log retention. Configure S3 Intelligent-Tiering or Standard storage with a Glacier transition after 90 days to control costs.

Configure CloudWatch Logs integration — stream CloudTrail events to CloudWatch for real-time alerting on suspicious activity (failed Console logins, unusual API calls, privilege escalation).

Enable AWS GuardDuty — continuous security monitoring across CloudTrail, VPC Flow Logs, and DNS logs. Detects cryptocurrency mining, credential compromise, and lateral movement automatically. Cost is ~$0.002/MB/day.

Configure AWS Config Rules — continuous compliance checking for your AWS resources. GuardDuty monitors "did something bad happen?" while Config monitors "is something badly configured?" Both required for SOC 2 coverage. aws configservice describe-config-rules --query 'ConfigRules[*].[ConfigRuleName,Compliance.Type]' --output table

Enable Security Hub — aggregates findings from GuardDuty, Config, and IAM Access Analyzer into a single dashboard. Simplifies evidence collection for the auditor.

Create alert for failed Console logins — CloudTrail logs ConsoleLogin events. Alert on failed logins above a threshold (e.g., 5 in 10 minutes) per IP or user account. Failed login patterns are an early indicator of credential stuffing.

Alert on IAM policy changes — any change to an IAM policy or role is audit-significant. Create CloudWatch event rules that trigger SNS alerts on PutRolePolicy, AttachUserPolicy, or CreatePolicy events.

Create or verify KMS customer-managed keys (CMKs) — use CMKs, not AWS-managed keys. CMKs give you audit access to key usage logs and control rotation. Account-level CMK is fine for startups; per-service CMKs for enterprise. aws kms list-keys --query 'Keys[*].[KeyId,KeyState,KeyRotationEnabled]' --output table

Enable automatic key rotation on all CMKs — annual rotation is required by PCI-DSS and strongly recommended for SOC 2. Rotation is free, takes effect immediately, and doesn't require application changes. aws kms enable-key-rotation --key-id <key-id>

Verify RDS encryption at rest — all RDS instances should have StorageEncrypted: true. Enable by default for new instances; migrate existing unencrypted instances via snapshots. Cannot be enabled after creation. aws rds describe-db-instances --query 'DBInstances[*].[DBInstanceIdentifier,StorageEncrypted,KmsKeyId]' --output table

Encrypt S3 buckets with SSE-KMS — use server-side encryption with AWS KMS (SSE-KMS) for sensitive data buckets. Enable bucket versioning so you can recover from accidental overwrites. aws s3api get-bucket-encryption --bucket <bucket-name>

Enable S3 Block Public Access at the account level — prevents any bucket from going public, even by accident. Critical for SOC 2 CC6.6. aws s3control get-public-access-block --account-id <account-id>

Enforce HTTPS on all ALB listeners — redirect all HTTP traffic to HTTPS. Enable HSTS (HTTP Strict Transport Security) headers for long-term enforcement.

Verify TLS 1.2 minimum for all services — disable TLS 1.0 and TLS 1.1 at the ALB/security group level. AWS ACM certificates enforce TLS 1.2+ by default.

Encrypt RDS connections — set rds.force_ssl=1 parameter group setting for PostgreSQL. MySQL uses require_ssl=1. Force SSL on all database connections — never allow plaintext connections to production databases.

Use Secrets Manager or SSM Parameter Store for credentials — no credentials in Lambda env vars, application config files, or EC2 user data. Rotate secrets on a schedule (90 days minimum for production).

Write an Information Security Policy — one-page doc covering: data classification, access management, incident response, and change management. Auditors want to see that leadership signed off on security being a priority.

Document the access review process — quarterly user access reviews are a SOC 2 requirement. Document the process: who runs it, what they check, how changes are recorded, and who signs off. Automate the user list export for efficiency.

Create change management runbooks — SOC 2 CC8.1 requires change authorization and testing. Document how code changes get reviewed, tested, and deployed. Even a lightweight process is better than none.

Define a vendor management process — if you use third-party services (Okta, Datadog, etc.), list them with their own compliance certifications (SOC 2, ISO 27001, etc.). SOC 2 auditors ask for this in the vendor section.

Write an Incident Response Plan — define what constitutes a security incident, who the response team is, and the steps for containment, eradication, and recovery. Include escalation paths and communication templates. SOC 2 CC7.3.

Test your backup restore process — SOC 2 requires evidence that you can recover from data loss. Document your RTO (Recovery Time Objective) and RPO (Recovery Point Objective), and test restores at least quarterly.

Create a vendor escalation contact list — AWS support tier, your security tool vendors, and legal counsel. Auditors want to see you have a plan for when something goes wrong, not just when it's working.

Document a business continuity plan — high-level description of how the company continues operating if its primary AWS region fails. Can be simple — SOC 2 wants to see you thought about it, not that you have a 200-page document.

Export CloudTrail logs for the audit period — if your audit covers Jan–Dec 2026, export all CloudTrail events for that window. AWS CloudTrail Lake can query this directly. Don't wait until the auditor asks.

Run a quarterly access review and save the output — export the IAM user list with last-access timestamps. Auditor will ask for evidence that access reviews happened during the audit period. aws iam generate-credential-report then aws iam get-credential-report

Export GuardDuty findings for the audit period — Security Hub or GuardDuty console. Document any open findings with remediation dates. Unresolved findings without a documented plan are a red flag.

Document all system components in scope — create a system architecture diagram showing what's in scope vs. out of scope. Auditors use this to define the "description of system" section of the report.

Confirm all controls were in place for the full audit period — Type II audit requires 3–12 months of continuous evidence. Controls added on day 89 won't count for a 90-day audit window. Scope your timeline carefully.