Sunspot
Back to Blog
compliance

SOC 2 Compliance Checklist for 2025: Everything You Need to Pass Your Audit

A complete, actionable SOC 2 Type II checklist covering all five trust service criteria, ready for your next audit cycle. Updated for 2025.

5 min readBy Sarah Chen
SOC2complianceauditType IItrust service criteria

Let's talk about SOC 2

SOC 2 (System and Organization Controls 2) is the AICPA's auditing standard for how you handle customer data. It boils down to five Trust Service Criteria:

  1. Security (the only one that's mandatory on every audit)
  2. Availability
  3. Processing Integrity
  4. Confidentiality
  5. Privacy

Most companies kick things off with Security alone and bolt on Availability and Confidentiality later, usually because an enterprise prospect asked for it during a sales cycle. That's fine. Don't try to boil the ocean on day one.

Type I vs. Type II: which one do you actually need? - SOC 2 Type I is a snapshot. It says "yes, your controls are designed properly" at a single point in time. - SOC 2 Type II covers a window, typically 6 to 12 months, and proves those controls actually worked the whole time.

Here's the reality: enterprise buyers want Type II. Almost without exception. If you're early-stage and not ready for that observation period, getting a Type I first can be a smart stepping stone. It signals intent while you build up the track record. Just know that Type I won't be enough long-term.

The 2025 Checklist

Security (CC Series), Required

Access Control - [ ] Multi-factor authentication on all production systems, no exceptions - [ ] Least privilege enforced everywhere. If someone doesn't need access, they shouldn't have it - [ ] Quarterly access reviews. Revoke departing employees within 24 hours (not "sometime next week") - [ ] A formal request-and-approval workflow for new access - [ ] Privileged access management for admin accounts

Change Management - [ ] Every production change goes through a documented process - [ ] Peer review on all code before it merges - [ ] Audit log of everything deployed to production - [ ] Changes tested in non-production environments first - [ ] Emergency change procedures exist, are documented, and are used sparingly

Risk Assessment - [ ] Formal risk assessment at least once a year - [ ] Risk register maintained with owners, residual risk scores, and remediation plans - [ ] Risk assessments updated after major changes to your environment

Incident Response - [ ] Documented incident response plan - [ ] Escalation procedures and comms templates ready to go - [ ] At least one tabletop exercise annually (and honestly, you should do more) - [ ] Every security incident logged and formally closed with lessons learned

Vendor Management - [ ] Full inventory of third-party vendors touching customer data - [ ] Security questionnaires or SOC 2 reports collected from critical vendors yearly - [ ] Contracts include real security language, including DPAs and BAAs where applicable

Logical and Physical Security - [ ] Data encrypted at rest (AES-256 or equivalent) and in transit (TLS 1.2+) - [ ] Physical access to data centers and offices restricted and logged - [ ] Vulnerability management program in place. Scan regularly, patch critical vulns within 30 days

Availability (A Series), Optional but increasingly expected - [ ] Uptime SLAs defined and communicated to customers - [ ] Monitoring and alerting on all critical services - [ ] Business Continuity Plan and Disaster Recovery Plan documented - [ ] DR procedures tested at least annually (not just written and filed away) - [ ] Backup and restore procedures documented and tested

Confidentiality (C Series), Enterprise customers will ask - [ ] Data classified with clear handling requirements per classification level - [ ] Access to confidential data limited to people with a legitimate business need - [ ] Encryption on confidential data, both at rest and in transit - [ ] Retention and disposal policies in place and actually enforced

Where audits fall apart

I've seen teams nail the technical controls and still stumble hard on audit day. It's almost always one of these:

Evidence gaps. Your controls might be solid, but if you can't prove they operated consistently over the observation period, the auditor will flag it. Automate evidence collection wherever you can. Manually screenshotting dashboards every month is a recipe for missed evidence.

Access review failures. Quarterly access reviews sound simple enough, but they're one of the most commonly missed items. Put them on the calendar with a clear owner. Don't let them slide.

Vendor management holes. Missing security questionnaires for critical vendors comes up again and again. Keep a vendor inventory and set up automated reminders for renewals. Your future self will thank you.

Undocumented changes. Even a tiny config tweak can become a finding if it skipped the change management process. Make sure your engineers know what counts as a "change," because to an auditor, pretty much everything does.

Getting audit-ready

  1. Pick your observation window. Six months is standard for a first Type II. Some teams go shorter, but six gives you enough runway to demonstrate consistency.

  2. Do a readiness assessment. Find the gaps before your auditor does. Cheaper that way, and a lot less stressful.

  3. Automate evidence collection. Seriously. Manual collection is where good intentions go to die. Use a GRC platform and save yourself the headache.

  4. Choose the right auditor. You want a CPA firm with actual SOC 2 experience in your industry. Not all auditors are created equal, so ask for references.

  5. Prep your team. Engineers and IT staff will get interviewed. Brief them on what the auditor's looking for so they're not caught off guard.

How Sunspot fits in

Sunspot handles evidence collection, maps your controls to SOC 2 criteria, and generates audit-ready packages without the manual grind. Our customers typically cut their SOC 2 prep time by about 60%.

Start your SOC 2 journey today