SOC 2 Compliance Checklist for SaaS Companies

SOC 2 is a trust framework, not a security certification. The distinction matters because many SaaS companies approach an audit as a paperwork exercise and emerge with a report that tells customers very little about the actual security of the system. Done correctly, SOC 2 is an engineering discipline — one that forces rigor in access control, logging, change management, and incident response.

This checklist is written for engineering and technical leadership at SaaS companies preparing for a SOC 2 Type II audit. It covers what auditors actually look at, the controls that most commonly have gaps, and the sequencing decisions that affect how painful the process is.

Type I vs. Type II: What the Difference Actually Means

A SOC 2 Type I report describes the design of your controls at a single point in time. An auditor reviews your documented policies, inspects your configurations, and opines on whether the controls, as designed, appear capable of meeting the applicable Trust Service Criteria.

A Type II report covers operating effectiveness over an observation period — typically six to twelve months. The auditor is not just reading your policies; they are testing whether the controls actually functioned throughout the period. That means log evidence, access review records, change management tickets, incident documentation, and vendor review artifacts — all timestamped and covering the full observation window.

Type I is sometimes used as a stepping stone, but enterprise buyers and enterprise procurement teams increasingly require Type II. If your goal is enterprise sales, plan for Type II from the beginning.

The practical implication for engineering: your observation period starts before you engage an auditor. Controls need to be live and producing evidence before the clock starts. If you implement audit logging in November and your observation period starts October 1, you have a gap.

The Five Trust Service Criteria

SOC 2 is built on the AICPA Trust Service Criteria (TSC). Security is the only required criterion — the others are optional and elected based on what your customers care about and what your product does.

Security (CC) — The Common Criteria. Required. Covers logical and physical access controls, risk management, change management, monitoring, and incident response. This is the baseline that all SOC 2 reports include.

Availability (A) — The system is available for operation and use as committed. Relevant if your customers have uptime SLAs or your product is operationally critical. Requires documented uptime monitoring, incident response, and disaster recovery.

Confidentiality (C) — Information designated as confidential is protected. Relevant if you handle proprietary business data, trade secrets, or non-PHI sensitive information. Requires data classification, encryption, and access controls scoped to confidential data.

Processing Integrity (PI) — System processing is complete, valid, accurate, timely, and authorized. Relevant if you process financial transactions, payroll, or other integrity-sensitive workflows. Requires input validation, error handling, and output completeness controls.

Privacy (P) — Personal information is collected, used, retained, disclosed, and disposed of in conformity with your privacy notice and applicable criteria. Relevant if you handle personal data for individuals. Overlaps significantly with GDPR and CCPA obligations.

Most SaaS companies elect Security plus one or two others. If you process payments or handle financial data for customers, add Processing Integrity. If you are in a B2B context storing customer business data, Confidentiality is common. Healthcare products almost always add Availability given clinical dependencies.

The Engineering Checklist

What follows is organized by control domain. Each item reflects what auditors will look for evidence of — not just policy documentation, but operational evidence that the control functioned during the observation period.

Access Controls

Unique user accounts for every individual — no shared credentials, no team accounts
Multi-factor authentication enforced for all internal systems, cloud consoles, and production access
Privileged access management: production access is separated from development access, with documented justification for each user who has production credentials
Role-based access control with documented role definitions — what each role can access and why
Access provisioning is tied to an onboarding process with documented approvals
Quarterly (or more frequent) access reviews: evidence that you are reviewing who has access and removing stale accounts
Offboarding procedures result in access revocation within a defined timeframe (24-48 hours is a common commitment)
Automated deprovisioning where possible — SSO with SCIM provisioning makes access review evidence far cleaner
Emergency access procedures documented and tested

Audit Logging and Monitoring

Authentication events logged: successful logins, failed logins, MFA challenges
Privileged actions logged: production access events, administrative configuration changes, data exports
Application-level events logged for security-relevant operations
Logs are centralized — not scattered across individual servers or services
Log integrity: logs cannot be modified or deleted by the application or by standard user roles
Log retention meets your defined retention policy (common commitment: 12 months)
Automated alerting on anomalous events: failed login spikes, unusual access patterns, configuration changes outside business hours
Alerts are reviewed and responded to — documented evidence of the review process

Encryption

Data at rest encrypted — document the algorithm and key management approach
Data in transit encrypted with TLS 1.2 or higher for all endpoints — TLS 1.3 preferred
Encryption key management documented: who holds keys, rotation schedule, what happens when personnel with key access depart
Secrets are managed via a secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) — not environment variables in application code or configuration files
No plaintext secrets in version control — confirmed via secret scanning in your CI pipeline
Backup data encrypted with the same or equivalent controls as primary data

Change Management

All production changes go through a defined process — documented, not just practiced
Code review required before merge to main: evidence that changes were reviewed by at least one person other than the author
Separation of duties for deployments: the person who writes code cannot be the only person who deploys it (some auditors will accept a compensating control if team size makes this impractical — document it)
Automated testing in CI pipeline before production deployment
Change approvals documented — a ticketing system or PR approval record suffices
Emergency change process documented for out-of-band deployments, with post-incident documentation requirements
Infrastructure changes managed as code where possible — reduces drift and creates an audit trail

Vendor Management

Vendor inventory maintained: all third-party services that have access to your systems or customer data
Security reviews conducted for critical vendors before onboarding
Annual (or more frequent) reviews of critical vendor SOC 2 reports or equivalent
Contracts with subprocessors that handle customer data include appropriate security and data handling obligations
If you are in scope for HIPAA: BAAs in place with every vendor that processes PHI
A process exists for monitoring vendor security incidents and assessing impact on your environment

Incident Response

Incident response plan documented — not a template, but a plan tailored to your environment and team
Incident classification defined (severity levels with documented response requirements per level)
On-call or escalation path defined and tested
Post-mortems documented for significant incidents during the observation period
Customer notification procedures documented for security incidents that affect customer data
Tabletop exercise conducted during the observation period — evidence of the exercise and its outcomes
Communication channels tested: can you reach your team and your customers if primary systems are unavailable?

Common Gaps That Cause Audit Findings

Access reviews with no evidence. Many teams conduct quarterly access reviews verbally or in a Slack thread. Auditors need a record — a spreadsheet, a ticketing system export, or a documented process output — showing that the review occurred and what actions were taken as a result.

Logging coverage gaps. Application logging and infrastructure logging often exist in separate systems. Auditors look for comprehensive coverage. If your CloudTrail is configured but your application-level events are not centralized anywhere, you have a gap.

Change management exceptions. Emergency deployments that bypass the normal change process are common. What auditors look for is whether you have a documented exception process and whether those exceptions are tracked and reviewed. Undocumented hotfixes to production are findings.

Vendor reviews that stopped at the contract stage. Signing a DPA or a security addendum with a vendor is necessary but not sufficient. Auditors expect ongoing review — annual SOC 2 attestation verification, monitoring vendor breach disclosures, re-assessing critical vendors when they make significant changes.

Policies that do not match practice. The most common finding is a policy that says one thing and operational evidence that shows something different. Your password complexity policy says 16 characters minimum; your identity provider is configured to accept 8. The fix is either to update the policy or to update the configuration — but the gap itself is a finding.

Separation of duties with single-person teams. Small teams legitimately cannot separate every duty. Auditors understand this. What they require is that you document the compensating controls: enhanced monitoring, periodic manager review, or other mechanisms that reduce the risk. The finding comes when there is neither separation nor a documented compensating control.

Observation Period Timing and Auditor Engagement

The observation period is the window during which auditors collect evidence of control operation. Six months is the minimum for a credible Type II report; twelve months is more common and more credible to enterprise buyers.

The practical sequencing:

Implement controls. Every control on your checklist needs to be live and producing evidence before the observation period starts. Do not start the clock until your logging is centralized, your access reviews are scheduled, and your change management process is documented and followed.
Run the controls for a period. Many teams run for 30-60 days post-implementation before formally engaging an auditor. This surfaces operational gaps before the audit clock starts.
Engage an auditor for readiness assessment. Most audit firms offer a pre-audit readiness review. This is worth doing. It surfaces gaps that would otherwise appear as findings in the final report.
Observation period begins. This is typically agreed upon between you and your auditor. The auditor collects evidence at the end of the period, not throughout it — but the evidence they collect (logs, access review records, change tickets) must span the full period.
Evidence collection and fieldwork. The auditor requests evidence packages. Having a well-organized evidence repository — organized by control domain, with clear naming and date metadata — significantly reduces the friction here.
Report issuance. A Type II report contains a description of your system and controls, the auditor's opinion on control design, and testing results for each control over the observation period. Findings (exceptions) are documented with your management's response.

The typical engagement timeline from control implementation to report issuance is 12-18 months for a first-time SOC 2 Type II. Teams that try to compress this timeline often end up with short observation periods that raise questions with sophisticated buyers, or they end up rushing control implementation into the observation window and accumulating findings.

Frequently Asked Questions

How much does a SOC 2 Type II audit cost?

Audit fees from established CPA firms range from $20,000 to $60,000 for a first-time Type II engagement, depending on the scope of criteria elected and the complexity of your environment. Compliance automation platforms (Vanta, Drata, Secureframe) typically cost $10,000-$25,000 per year and can reduce the audit fee by streamlining evidence collection. Budget for both the audit firm and the tooling.

Do we need SOC 2 compliance if we are a small startup?

Not immediately. SOC 2 becomes a practical requirement when you are selling to enterprise buyers, to regulated industries (healthcare, financial services, government), or to any customer whose procurement process includes a security questionnaire. Many early-stage SaaS companies implement the controls without pursuing a formal audit, then engage an auditor once enterprise sales require it.

What is the difference between SOC 2 and ISO 27001?

Both are information security frameworks with third-party attestation. SOC 2 is US-centric and more common in US enterprise sales. ISO 27001 is internationally recognized and required by some European and global enterprise buyers. The controls overlap significantly; organizations that pursue both typically use a unified control framework rather than running two separate programs.

Can we use a compliance automation platform instead of an auditor?

Compliance automation platforms (Vanta, Drata, Secureframe) automate evidence collection, monitor your environment for control drift, and connect to your infrastructure via API. They do not replace the auditor — you still need a licensed CPA firm to conduct the audit and issue the report. What they replace is much of the manual evidence collection work and the spreadsheet-driven control tracking that otherwise consumes significant engineering time.

Build Controls That Actually Work

A SOC 2 report is evidence of the controls you operate, not the controls you intend to operate. The teams that come through audits cleanly are the ones that implemented controls before the observation period, ran them consistently, and maintained operational evidence as a byproduct of normal engineering practice — not as a compliance exercise bolted on at the end.

If your team is preparing for a first SOC 2 engagement and wants a structured review of your current control posture before the observation period begins, that is a useful conversation to have early. Reach out to discuss your architecture and where the gaps are most likely to surface.