SOC 2 Compliance Checklist: The Practical Guide for SaaS and Technology Companies

SOC 2 compliance has become the de facto security standard for technology companies selling into enterprise accounts. If you have ever lost a deal because you could not produce a SOC 2 report — or spent weeks answering security questionnaires that a SOC 2 report would have preempted — you already understand why this matters. According to IBM's Cost of a Data Breach 2022, organizations with both an incident-response team and a regularly tested IR plan saved an average of $2.66 million per breach versus those with neither. SOC 2 is not merely a checkbox — it is a competitive differentiator that signals operational maturity to prospects, partners, and investors.

This guide provides a practitioner's checklist for achieving SOC 2 Type II compliance, covering the Trust Services Criteria, the technical controls you actually need to implement, what auditors look for during evidence collection, and the most common reasons companies fail their first audit. It is written for engineering leaders and security teams at SaaS and technology companies who need actionable guidance rather than abstract frameworks.

SOC 2 Type I vs. Type II: Understanding the Difference

SOC 2 comes in two report types, and the distinction is critical:

• SOC 2 Type I evaluates whether your security controls are suitably designed at a specific point in time. It answers the question: "Do you have the right controls in place today?" A Type I report is a snapshot — an auditor examines your policies, configurations, and architecture on the audit date and attests to their design.
• SOC 2 Type II evaluates whether those controls are operating effectively over a sustained observation period, typically 3 to 12 months. It answers the harder question: "Are your controls actually working consistently?" A Type II report requires continuous evidence — logs, access reviews, change records, incident reports — proving that your controls function as designed across the entire audit window.

Which one do enterprise customers require? Type II. Almost universally. A Type I report demonstrates intent. A Type II report demonstrates execution. When a Fortune 500 procurement team asks for your SOC 2, they mean Type II. Starting with a Type I is a legitimate stepping stone — it forces you to build the control framework — but plan for Type II as the actual deliverable your customers will accept.

The Five Trust Services Criteria

SOC 2 is organized around five Trust Services Criteria (TSC), defined by the AICPA. Understanding which criteria apply to your organization determines the scope of your audit:

• Security (CC — Common Criteria): The only required criterion. Covers protection against unauthorized access, both physical and logical. This encompasses access controls, network security, monitoring, incident response, and risk management. Every SOC 2 report includes Security.
• Availability (A): Addresses whether your systems are operational and accessible as committed in SLAs. Covers redundancy, disaster recovery, backup procedures, and capacity planning. Recommended for SaaS companies — your customers care about uptime.
• Processing Integrity (PI): Ensures that system processing is complete, valid, accurate, and timely. Most relevant for companies that process financial transactions, data pipelines, or calculations where errors have material impact.
• Confidentiality (C): Covers protection of information designated as confidential — trade secrets, intellectual property, business plans, client data governed by NDAs. Relevant when you handle sensitive business information beyond personal data.
• Privacy (P): Addresses the collection, use, retention, disclosure, and disposal of personal information. Aligns with privacy frameworks like GDPR and CCPA. Include this if your platform processes significant volumes of PII.

Practical recommendation: Most technology companies begin with Security + Availability. These two criteria cover the controls enterprise customers care about most — "is our data protected?" and "will your service stay up?" — without overextending your initial compliance scope. Add Processing Integrity, Confidentiality, or Privacy in subsequent audit cycles based on customer requirements and your data handling profile.

Technical Controls Checklist

The following checklist maps to the controls auditors evaluate during a SOC 2 Type II engagement. This is not theoretical — these are the specific items that generate audit findings when missing or improperly implemented.

Access Control

• Multi-factor authentication (MFA) enforced on all production systems, cloud consoles, and SaaS tools — no exceptions for service accounts without compensating controls
• Role-based access control (RBAC) with documented role definitions and least-privilege assignment
• Quarterly access reviews with evidence of remediation (revoked access for role changes, departures)
• Automated offboarding that revokes access within 24 hours of termination — SSO deprovisioning, cloud IAM removal, VPN revocation, and shared credential rotation
• Unique accounts for all users — no shared credentials for production systems
• Privileged access management (PAM) with just-in-time elevation for administrative operations

Network Security

• Network segmentation isolating production, staging, development, and corporate environments
• Firewall rules documented with business justification — default-deny policies for inbound traffic
• IDS/IPS deployed at network boundaries with active alerting to your security team or managed infrastructure provider
• TLS 1.2+ enforced for all data in transit — no fallback to deprecated protocols
• VPN or zero-trust network access (ZTNA) for remote administrative access
• Regular penetration testing — at minimum annually, and after significant infrastructure changes

Endpoint Security

• Endpoint Detection and Response (EDR) deployed on all endpoints — workstations, laptops, and servers
• Automated patch management with defined SLAs: critical vulnerabilities patched within 14 days, high within 30 days
• Full-disk encryption (BitLocker, FileVault, LUKS) on all endpoints that access production data
• Mobile device management (MDM) for company-owned devices with remote wipe capability
• Host-based firewalls enabled on all endpoints

Logging & Monitoring

• Centralized log aggregation (SIEM or equivalent) collecting logs from all production systems, cloud services, identity providers, and network devices
• Log retention of at least 90 days online, 12 months archived — aligned with your audit observation period
• Real-time alerting on security-relevant events: failed authentication spikes, privilege escalation, configuration changes, data exfiltration indicators
• Log integrity controls — write-once storage or tamper-evident logging to prevent evidence destruction
• Defined escalation procedures: who gets alerted, response time SLAs, on-call rotation

Incident Response

• Documented incident response (IR) plan covering identification, containment, eradication, recovery, and post-incident review
• Defined severity levels with corresponding response time SLAs
• Tabletop exercises conducted at least annually — with documented findings and remediation actions
• Communication plan covering internal escalation, customer notification, regulatory reporting, and legal counsel engagement
• Post-incident review process that produces written root-cause analysis and preventive action items

Change Management

• All code changes tracked in version control (Git) with descriptive commit messages
• Peer code review required before merge to production — no self-approvals
• CI/CD pipeline with automated security checks: SAST, dependency scanning, container image scanning
• Rollback procedures documented and tested — you must be able to revert a bad deployment within your defined SLA
• Separation of duties between development and production deployment approval
• Change advisory board (CAB) or documented approval process for infrastructure changes

Vendor Management

• Third-party risk assessment process for all vendors that access, process, or store your data
• Business Associate Agreements (BAAs) or Data Processing Agreements (DPAs) in place for all data-handling vendors
• Annual vendor security reviews — request SOC 2 reports, penetration test summaries, or complete security questionnaires
• SLA monitoring for critical service providers — uptime, incident response, data handling compliance
• Documented vendor inventory with data classification for each vendor relationship

Data Protection

• Encryption at rest for all production databases and storage systems — AES-256 or equivalent
• Key management procedures with key rotation schedules and access controls on key material
• Backup procedures with defined RPO (Recovery Point Objective) and RTO (Recovery Time Objective)
• Backup restoration testing conducted at least quarterly — with documented results
• Data classification policy defining sensitivity levels and corresponding handling requirements
• Architecture hardening reviews to identify and remediate data exposure risks

Evidence Collection: What Auditors Actually Want

The gap between "having controls" and "proving controls work" is where most companies struggle during their first SOC 2 audit. Auditors operate on evidence, not assurances. Here is what they expect to see:

• Screenshots with timestamps: Configuration screenshots from your cloud console (AWS, Azure, GCP) showing MFA enforcement, encryption settings, network security groups, and IAM policies. These must be dated within the observation period.
• Access logs: Authentication logs showing MFA challenges, failed login attempts and follow-up actions, privileged access usage, and access review completion records.
• Change records: Pull request histories showing code review approvals, deployment logs with approver identification, change tickets with business justification and risk assessment.
• Policy documents: Written policies for information security, acceptable use, incident response, data classification, vendor management, and business continuity. These must be version-controlled with evidence of annual review and employee acknowledgment.
• Incident records: Incident tickets showing detection-to-resolution timelines, root-cause analyses, and remediation actions. Even if you had zero security incidents during the observation period, auditors want to see your incident response tabletop exercise records.
• Monitoring evidence: Alert configurations, escalation records, and on-call schedules. Dashboards alone are insufficient — auditors want to see that alerts triggered responses.

The critical distinction: Having a written password policy is necessary but not sufficient. Auditors want evidence that the policy is enforced — SSO configurations that mandate complexity requirements, access review records showing accounts disabled after failed compliance, and training records showing employees acknowledged the policy. The pattern applies across every control: policy + enforcement evidence + operational proof.

Common Audit Failures: The Top 5 Reasons Companies Fail

After supporting multiple organizations through SOC 2 readiness, these are the most frequent reasons companies receive qualified opinions or fail their initial audit:

1. No Evidence of Monitoring

Having a SIEM deployed is not the same as having a monitoring program. Auditors look for evidence that alerts were generated, reviewed, and acted upon. If your SIEM collected logs but no one investigated alerts during the observation period, that is a finding. The fix: establish documented triage procedures, maintain an alert investigation log, and ensure on-call personnel document their response actions.

2. Incomplete Offboarding

This is the single most common finding in SOC 2 audits. Auditors cross-reference your HR termination records against active accounts in your identity provider, cloud consoles, and SaaS tools. If a terminated employee still has an active account 48 hours after their departure date, that is a control failure. The fix: automate offboarding through your identity provider, run monthly orphaned account audits, and maintain an offboarding checklist with sign-off.

3. Missing Change Management Evidence

Code pushed directly to production without peer review. Infrastructure changes made without tickets. Deployments without approval records. Auditors trace a sample of production changes back through your change management process — if any step is missing, that is a finding. The fix: enforce branch protection rules, require pull request approvals, and log all production deployments with approver identification.

4. Untested Incident Response Plan

Many companies write an incident response plan and never exercise it. Auditors ask for evidence of tabletop exercises, post-incident reviews, or plan activation. A plan that has never been tested is a plan that does not work. The fix: conduct at least one tabletop exercise per year, document the scenario, participants, findings, and resulting plan updates.

5. Gaps Between Policy and Practice

Your information security policy requires quarterly access reviews, but the last review was 8 months ago. Your change management policy requires risk assessment for all changes, but 40% of tickets lack a risk field. Auditors compare policy requirements against operational evidence and flag discrepancies. The fix: audit your own compliance quarterly — review a sample of evidence against each policy requirement and remediate gaps before the auditor finds them.

Timeline and Investment

Realistic timelines for SOC 2, based on a technology company starting with limited formal controls:

• SOC 2 Type I readiness: 3–6 months. This period covers policy development, control implementation, tool deployment (SIEM, EDR, identity provider configuration), and gap remediation. Companies with existing security programs may compress this to 6–8 weeks.
• SOC 2 Type II observation period: 3–12 months after Type I. Most auditors recommend a 6-month observation window for the initial Type II. This is the period during which your controls must operate consistently and generate evidence. Subsequent annual audits cover a 12-month window.
• Total time to Type II report: 9–18 months from initiation. Plan for 12 months as a realistic baseline.

Costs vary widely by approach and company size. According to Vanta's own published guidance, achieving SOC 2 typically totals $10K to $80K or more, with the independent audit itself running roughly $10K–$50K (Vanta, "How much does a SOC 2 audit cost?"). The largest variables are how much control implementation and evidence collection you handle internally versus outsource, the number of frameworks in scope, and whether you engage a regional CPA firm or a Big 4 auditor.

Compliance-automation platforms such as Vanta, Drata, and Secureframe quote custom pricing rather than published list prices, and the platform subscription is separate from — and additional to — the auditor's fee. A DIY effort trades cash for internal engineering time (commonly 500–1,000 hours of control implementation and evidence collection); a full-service, MSSP-assisted engagement adds security program buildout, policy development, and audit coordination for companies without dedicated security staff.

The cost of not achieving SOC 2 is harder to quantify but often larger: lost enterprise deals, extended sales cycles due to security questionnaires, higher cyber insurance premiums, and increased breach risk from immature controls. For most SaaS companies selling to enterprise accounts, SOC 2 Type II pays for itself within the first two enterprise contracts it unlocks.

Start Your SOC 2 Readiness Program

SOC 2 compliance is a sustained program, not a one-time project. The checklist above provides the technical foundation, but successful implementation requires consistent execution, evidence discipline, and periodic self-assessment against your own control framework.

If your organization needs support building the security controls that underpin SOC 2 readiness — from web application security assessments and penetration testing to architecture hardening and managed infrastructure — Fortress MSSP provides practitioner-led security services that map directly to SOC 2 Trust Services Criteria. Contact us to discuss your compliance objectives and get a realistic assessment of your current readiness posture.