Free SOC 2 Compliance Checker — 24-Question Global Assessment

About the SOC 2 Compliance Checker

The SOC 2 Compliance Checker assesses readiness against the five Trust Services Criteria (TSC) — Security, Availability, Processing Integrity, Confidentiality, and Privacy — that the AICPA defines for service organization audits. Security (the Common Criteria) is mandatory for every SOC 2 report; the other four are optional categories you scope based on customer commitments. The 24 questions reflect what an AICPA-credentialed auditor evaluates during a Type II examination, weighted by which control deficiencies most often produce qualified opinions or extended remediation periods. SOC 2 is not a regulatory framework — it is an auditor attestation that your controls, as designed and operated, meet the TSC over a defined period (typically 6–12 months for Type II). The checker scores design, not operation; only an actual audit verifies operating effectiveness.

What this SOC 2 assessment covers

The 24-question assessment scores 100 points across 5 weighted categories. Each category reflects a distinct SOC 2 control domain.

Security — CC Series · 32 pts · 8 questions

Assessment of security controls across the Common Criteria series.

Availability · 18 pts · 4 questions

Evaluation of system uptime, disaster recovery, and capacity management.

Processing Integrity · 16 pts · 4 questions

Assessment of data processing accuracy, completeness, and auditability.

Confidentiality · 18 pts · 4 questions

Evaluation of data classification, encryption, retention, and contractual protections.

Privacy · 16 pts · 4 questions

Assessment of privacy notice, data minimization, and individual rights practices.

Common SOC 2 compliance gaps

The patterns we see most frequently in SOC 2 self-assessments and remediation work. Each is the kind of finding an auditor flags first.

Type I controls passed but Type II controls failed. Most teams ship a SOC 2 Type I (point-in-time control design) and then fail Type II (operating effectiveness over 6–12 months) because controls weren't consistently executed. The most common failure is access reviews — designed to happen quarterly, executed sporadically, with no evidence trail.

Vendor management is incomplete. Auditors expect a documented vendor inventory, vendor risk tier assignments, and evidence of vendor security reviews (typically the vendor's own SOC 2 report or equivalent). Teams often have the inventory but no evidence of actual review — just a list of vendors and their SOC 2 status checkbox.

Change management lacks evidence. Code review approvals exist in pull requests, but auditors want a defensible trail showing every production change was reviewed, approved, and tested per policy. Direct pushes to production, hotfixes that bypass review, and merge-without-review on emergency tags are the typical findings.

Logging exists but monitoring doesn't. You collect logs but don't alert on anomalies. Trust Services Criterion CC7.2 expects detection and response to anomalous events — passive logs in a SIEM that no one reviews is a deficiency, not a control.

Backup tests are documented but not performed. Backup policy says quarterly restore tests. Engineering hasn't actually restored a backup in 18 months. This is the #1 finding in availability-scoped SOC 2 audits because it's both critical and easy for the auditor to verify (or fail).

Workforce offboarding takes days. SOC 2 expects same-day access revocation for terminated employees. Real-world processes that route through HR queues, IT tickets, and Slack DMs often result in access remaining live for 3–7 days. Build-in SCIM-based deprovisioning catches this.

What to do with your SOC 2 results

Your score is a starting point — these are the steps that convert the assessment into actionable remediation.

Pick your TSC scope before writing controls. Security is mandatory; everything else is optional based on what you commit to customers. Scoping more categories than your customers actually require inflates audit cost and remediation work without commensurate sales value.

Choose Type I or Type II based on customer pressure. Type I is faster and cheaper (4–8 weeks, point-in-time). Type II is the standard customers expect (6–12 month observation window). Most teams ship Type I first to unblock pilots and Type II second to close enterprise deals.

Select an auditor before you write controls. Auditors have opinions on control design that can save you months of rework if surfaced before remediation. Big Four firms cost more but carry more weight with enterprise procurement; specialty firms (Prescient, Insight Assurance, Johanson Group) are faster and cheaper.

Stand up evidence collection automation. Drata, Vanta, Secureframe, and Sprinto automate evidence collection — the actual day-to-day burden of a SOC 2 program. Manual evidence collection for a 12-month Type II is roughly 200–400 hours of engineering time per cycle.

Run an internal pre-audit 90 days before the formal one. Walk the auditor's playbook yourself. Most deficiencies surface in this pass and can be remediated before the formal audit window begins.

SOC 2 compliance FAQ

How long does a SOC 2 Type II audit take?

Plan 6–12 months for the observation window plus 4–8 weeks for fieldwork and report issuance. Type I is much faster — 4–8 weeks total — because it's a point-in-time control design review. Most teams pursue Type I first for early customer pilots and Type II for enterprise procurement.

What does SOC 2 cost?

Audit fees range from $15K (small firm, Security-only scope, Type I) to $80K+ (Big Four, all five TSC, Type II). Compliance automation platforms (Drata, Vanta) add $10K–$50K/year. Internal engineering time for evidence collection and remediation typically runs 200–600 hours over the audit cycle.

Is SOC 2 required for healthcare apps?

Not by regulation, but increasingly by procurement. Hospitals, health plans, and large healthcare buyers routinely require SOC 2 reports during vendor due diligence — sometimes alongside HIPAA. HITRUST CSF is the healthcare-native equivalent that some large buyers prefer over SOC 2.

What's the difference between SOC 1, SOC 2, and SOC 3?

SOC 1 reports on controls relevant to financial reporting (used by service organizations handling customer financial data). SOC 2 reports on Trust Services Criteria (used by SaaS, hosting, and managed service providers). SOC 3 is a public-facing summary of a SOC 2 report — same controls, less detail, distributable to anyone.

Can we use someone else's SOC 2 report to cover our infrastructure?

Partially. You can rely on your infrastructure provider's SOC 2 (AWS, GCP, Azure all publish them) for the controls they manage — physical security, network segmentation, hypervisor isolation. You are still responsible for the controls in your portion of the shared responsibility model (application security, access management, change control, data classification).

What is the SOC 2 + HIPAA + HITRUST stack for a healthcare SaaS?

SOC 2 demonstrates baseline trust controls for any enterprise buyer; HIPAA is the regulatory minimum for handling PHI; HITRUST CSF is the healthcare-native attestation many hospital systems require. Mature healthcare SaaS companies typically hold all three. They overlap significantly — running a unified controls program across all three saves substantial effort versus parallel programs.

Build it instead of buying it

Generate a SOC 2-compliant healthcare app with the controls built in

VertiComply generates production-ready healthcare applications with SOC 2 controls scaffolded from the first commit — no add-on tier, no platform lock-in, code exported to your GitHub.

Start free

SOC 2 Readiness Checker

Progress: 0/24

Security — CC Series

Availability

Processing Integrity

Confidentiality

Privacy