SOC 2 Readiness Checklist for SaaS Companies

SOC 2 is built on five Trust Service Criteria (TSC): Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. Before writing a single policy, decide which criteria apply to your product and define the precise systems, infrastructure, and people that fall within your audit boundary.

• Identify which TSCs are relevant — Security is always required; add Availability if you have uptime SLAs, Confidentiality if you process sensitive business data, and Privacy if you handle personal data.
• Draw a clear system boundary: list every production service, data store, cloud account, and CI/CD pipeline in scope.
• Document what is explicitly out of scope and get auditor agreement early to avoid scope creep.
• Choose your audit type: Type I (point-in-time design effectiveness) vs. Type II (operational effectiveness over 6–12 months).
• Select a licensed CPA firm that specialises in SOC 2 and schedule a pre-audit readiness call.

Auditors test controls against written policies. Without approved, version-controlled documents, even good technical practices will not satisfy the criteria. Aim for policies that are specific enough to be enforceable but not so granular that they become outdated with every sprint.

• Draft and approve an Information Security Policy signed by executive leadership.
• Write an Acceptable Use Policy covering employee devices, cloud credentials, and data handling.
• Create a Data Classification Policy that defines sensitivity tiers (e.g., Public, Internal, Confidential, Restricted).
• Document a Change Management Policy requiring peer review, testing, and approval before production deployments.
• Publish an Incident Response Plan with defined roles, escalation paths, and SLA targets for containment and notification.
• Write a Business Continuity and Disaster Recovery Plan; include tested RTO and RPO targets.
• Establish a Vulnerability Management Policy specifying severity-based remediation timelines (e.g., Critical within 24 hours, High within 7 days).
• Store all policies in a version-controlled document management system and schedule annual reviews.

SOC 2 requires that your organisation identifies and responds to risks on a recurring basis. A one-off risk assessment document produced the week before the audit will not satisfy an experienced auditor. Build a living risk register instead.

• Identify assets (data stores, services, third-party integrations) and assign an owner to each.
• Enumerate threats and vulnerabilities for each asset using a structured methodology (e.g., STRIDE or a qualitative risk matrix).
• Score each risk by likelihood and impact to produce an inherent risk rating.
• Define and document a treatment decision for every risk: Accept, Mitigate, Transfer, or Avoid.
• Record residual risk after controls are applied and get sign-off from leadership.
• Schedule risk assessment reviews at least annually and after significant architecture changes.

Technical controls are the backbone of SOC 2 compliance. Auditors will inspect your configuration evidence, so screenshots, exported configuration files, and automated evidence collection all count.

• Enable encryption at rest (AES-256 or equivalent) for all databases, object storage buckets, and backup files.
• Enforce TLS 1.2 or higher on all external and internal service endpoints — Sensagraph continuously scans your domains for weak TLS configurations and expired certificates.
• Disable all unnecessary ports and services; document your approved network topology.
• Apply a Web Application Firewall (WAF) in front of customer-facing services and tune it to block OWASP Top 10 attack patterns.
• Implement a patch management process: inventory all OS and dependency versions, subscribe to CVE feeds, and automate patching where possible.
• Run regular vulnerability scans against production and staging environments; track findings in your risk register.
• Harden cloud provider configurations using a benchmark (e.g., CIS AWS Foundations, CIS Azure) and remediate critical findings.
• Enforce HTTPS-only with HSTS headers on all web properties; check for missing security headers (CSP, X-Frame-Options, etc.).
• Scan your public-facing attack surface regularly — Sensagraph monitors exposed services and misconfigurations automatically.

More SOC 2 findings trace back to access control gaps than almost any other category. Apply the principle of least privilege everywhere and build processes that keep access rights accurate as roles change.

• Enforce Multi-Factor Authentication (MFA) for all employees on every system in scope — cloud consoles, code repositories, SaaS tools, VPN.
• Implement Single Sign-On (SSO) with a central identity provider so that offboarding instantly revokes access.
• Apply role-based access control (RBAC) and grant only the minimum permissions required for each role.
• Prohibit shared or generic accounts; every action must be attributable to an individual user.
• Conduct formal access reviews at least quarterly — review who has access, whether it is still needed, and remove stale permissions.
• Document the joiner/mover/leaver (JML) process and verify it is consistently followed with HR.
• Restrict and log all privileged (root/admin) access; consider just-in-time (JIT) access tools to eliminate standing privilege.
• Store secrets (API keys, database passwords) in a secrets manager — never in code repositories or plain-text config files.

The Availability and Security criteria both require that you detect and respond to anomalies. Centralised logging with meaningful alerts is essential evidence during a Type II audit, which covers how your controls operated over time.

• Enable audit logging on all in-scope systems: cloud provider logs (CloudTrail, GCP Audit Logs, Azure Monitor), application logs, and database query logs.
• Forward all logs to a centralised SIEM or log management platform with tamper-evident storage.
• Define retention periods that meet your TSC requirements (commonly at least 12 months for SOC 2).
• Create alerts for critical security events: failed login attempts, privilege escalation, configuration changes, data exfiltration indicators.
• Set up uptime and latency monitoring with on-call alerting for Availability TSC commitments.
• Document and test your incident response runbooks; conduct at least one tabletop exercise per year.
• Review alert thresholds regularly to reduce false positive fatigue while maintaining detection fidelity.

Your audit scope includes risks introduced by sub-processors and critical vendors. If a vendor has a breach that exposes your customer data, you are still responsible. Build a vendor risk programme that is proportionate to the sensitivity of data shared.

• Maintain a complete inventory of all third-party vendors and sub-processors that access, store, or process in-scope data.
• Classify vendors by risk tier based on data sensitivity and integration depth.
• Collect SOC 2 Type II reports (or ISO 27001 certificates) from high-risk vendors annually and review them for relevant exceptions.
• Sign Data Processing Agreements (DPAs) with all vendors that handle personal or confidential data.
• Include security requirements and breach notification timelines in vendor contracts.
• Review vendor access rights as part of your quarterly access review cycle.
• Have a plan for vendor offboarding: data deletion confirmation, credential revocation, and contract termination process.

Before engaging your auditor, perform an internal readiness assessment. Treat it like a mock audit: test your controls, collect evidence, and document gaps. Remediating findings now is far less painful than receiving an auditor exception in your final report.

• Map every SOC 2 control requirement to a specific policy, process, or technical control you have in place.
• Identify gaps where a control is missing, partially implemented, or lacks documented evidence.
• Prioritise remediation by risk level and audit impact — address Security TSC gaps before Availability or Privacy gaps.
• Collect and organise evidence artifacts: screenshots, configuration exports, access review records, training completion logs.
• Perform an external attack surface review to find any exposed services or misconfigurations that could appear in auditor testing — Sensagraph can provide a continuous view of your web-facing exposure.
• Conduct employee security awareness training and document completion rates; auditors check this.
• Engage your auditor for a readiness walkthrough and address their preliminary observations before the formal audit period begins.

SOC 2 Type II is not a one-time project — it covers a rolling period and renews annually. Companies that treat it as a checkbox exercise find themselves scrambling every year. Build compliance into your engineering and operations rhythm instead.

• Automate evidence collection wherever possible (access logs, vulnerability scan reports, backup confirmations) to reduce manual effort at audit time.
• Integrate security checks into your CI/CD pipeline: SAST, dependency scanning, and secrets detection on every pull request.
• Schedule recurring tasks in your project management tool: monthly log reviews, quarterly access reviews, annual policy reviews, annual risk assessment.
• Assign a named compliance owner (internal or fractional) responsible for tracking control health and coordinating the annual audit cycle.
• Communicate your SOC 2 status to customers through your trust portal and include the report in sales and procurement processes.
• Review and update your control set whenever you launch a major new feature, migrate infrastructure, or onboard a significant new vendor.