SOC 2 Readiness Checklist

Multi-factor authentication is enforced on the AWS root account.

All IAM users with console access have MFA enabled.

The AWS root account has no active programmatic access keys.

Strong password policy configured with minimum length, complexity, and rotation requirements.

IAM users with credentials unused for 90+ days are disabled or removed.

IAM users and roles are granted only the permissions required for their role.

User access rights are reviewed quarterly and unnecessary access revoked.

When employees leave, all system access is revoked within 24 hours.

Okta enforces MFA for all users across all connected applications.

Okta users inactive for 30+ days are flagged or automatically disabled.

MFA is enforced for all Google Workspace accounts at the domain level.

Super admin privileges are limited to the minimum number of accounts necessary.

Users inactive in Google Workspace are detected and disabled.

Physical access to offices and server rooms is controlled and logged.

AWS CloudTrail is enabled and logging API activity across all regions.

CloudTrail log file integrity validation is enabled to detect tampering.

CloudTrail logs are encrypted at rest using a KMS customer-managed key.

AWS GuardDuty is active and detecting threats across the account.

GuardDuty findings are reviewed and triaged on a regular schedule.

VPC flow logs are capturing network traffic for monitoring and analysis.

CloudWatch alarms are configured for root account usage, unauthorized API calls, and IAM policy changes. Checked automatically by TrailProof.

Audit and access logs are retained for a minimum of 12 months.

A documented process exists for regularly reviewing audit logs.

All S3 buckets have public access blocked unless explicitly required.

Server-side encryption is enabled on all S3 buckets.

Versioning is enabled on S3 buckets containing production or customer data.

Access logging is enabled on S3 buckets to maintain an audit trail.

All RDS instances have encryption at rest enabled.

RDS databases are not directly accessible from the public internet.

Automated backups are enabled with a retention period of at least 7 days.

Security groups do not allow unrestricted inbound access on sensitive ports.

Port 22 is not open to 0.0.0.0/0 in any security group.

AWS KMS keys have automatic annual rotation enabled.

EC2 instances use Instance Metadata Service v2 (IMDSv2) to prevent SSRF attacks.

TLS is enforced for all data in transit — no unencrypted HTTP in production.

Regular vulnerability scans are performed and findings remediated in a timely manner.

GitHub branch protection rules are configured and enforced on the main branch.

All changes to main require at least one peer code review before merging.

Two-factor authentication is enforced for all members of the GitHub organisation.

GitHub secret scanning is active and alerting on any exposed credentials.

A written process defines how code and infrastructure changes are approved and deployed.

Changes are tested in a staging environment before deployment to production.

Documented procedures exist for rolling back failed changes quickly.

Data is classified by sensitivity level (e.g. public, internal, confidential, restricted).

A policy defines how long different types of data are retained and how it is disposed of.

All customer data is stored encrypted at rest across all storage systems.

Backups are tested regularly to verify successful restoration.

Production RDS instances use Multi-AZ deployment for high availability.

A risk assessment has been conducted and documented, identifying key risks to the system.

A risk register is maintained and reviewed at least annually.

A third-party penetration test has been completed within the past 12 months. Available as an add-on via TrailProof — delivered by an OSCP & CREST-certified consultant.

Key vendors and subprocessors have been assessed for security risk.

A business continuity and disaster recovery plan is documented and tested.

A written information security policy has been adopted and communicated to all staff. Generated by TrailProof AI.

All employees have a signed acceptable use policy covering company systems and data. Generated by TrailProof AI.

A written incident response plan exists with clear roles and escalation paths. Generated by TrailProof AI.

A vendor management policy defines how third-party relationships are assessed and monitored. Generated by TrailProof AI.

Complete policy documentation covering all SOC 2 Trust Service Criteria exists and is current. TrailProof generates all 8 documents with AI, tailored to your company.

Security policies are formally reviewed and updated at least once per year.

A named individual or team owns information security at the management level.

Background checks are performed before hiring employees with access to sensitive systems.

All employees complete security awareness training at least once per year.

All employees and contractors sign confidentiality agreements before starting.

New employees complete a security onboarding checklist before receiving system access.

When employees leave, a checklist ensures all access is revoked and equipment returned.