SOC 2 for SaaS companies, done right.
Skadi audits SaaS companies exclusively on SOC 2 Type II. Our local model automates evidence collection and testing; a licensed CPA scopes, tests, and signs the report enterprise buyers demand. This page is written from an auditor's chair — what we actually look at, sample, and conclude on for a modern SaaS.
Audit challenges we solve for you.
Mid-market and enterprise procurement won't move without a current Type II report. Every quarter without one is pipeline slippage that shows up on the board deck.
Most first-time auditees arrive with one part-time compliance owner and a busy platform team. The audit cannot consume engineering for six months — control ownership needs to be assigned by name, not by team.
Daily deploys, new services monthly, an architecture that looks different in Q4 than Q1. The system description has to describe a moving target honestly, and the auditor has to test what actually shipped — not the diagram.
Ticket links expire, screenshots go stale, and engineers rotate. Populations and evidence must be captured continuously across the window; retroactive assembly at fieldwork is where exceptions come from.
Controls that matter most for your business.
Okta/Google Workspace enforcement, MFA coverage above 98%, quarterly access reviews signed by owners, and clean offboarding within a documented SLA. The single most-tested area in a SaaS audit.
Branch protection enforced across production repos, mandatory reviewer, required CI checks green before merge, and no direct pushes to protected branches — evidenced by GitHub audit logs across the full window.
AWS/GCP/Azure baselines, encryption at rest and in transit, KMS-managed keys with rotation, network segmentation, and continuous configuration monitoring with alerting on drift.
On-call rotations with escalation, incident postmortems for every SEV-1/SEV-2, SLO tracking, and evidence availability commitments were met — including for scoped Availability criteria.
Living sub-processor inventory, security review completed before onboarding (not after), and monitoring evidence for every critical processor. Enterprise questionnaires probe this heavily.
Threat modeling on new services, SAST/dependency/secret scanning in CI, and secure coding standards enforced through review templates and CI gates — not just a wiki page.
Backups configured, retention aligned to customer commitments, and — the control that gets missed most — an actual restoration test performed and documented during the window.
Annual risk assessment tied to actual threats, board or leadership acknowledgment, and evidence risks are tracked to remediation. Auditors read this before anything else.
What actually fails in this vertical.
Real deviations we see in SOC 2 Type II fieldwork — and what your platform and security teams should fix before the observation window starts.
Reviews happened in Slack but were never signed, dated, or attached to a ticket. Population of 4 quarterly reviews is tested in full — one missing signature is one exception.
- Signed access-review report per system (Okta, AWS, GitHub, prod DB) with reviewer name + date
- Jira/Linear ticket linking review to remediation actions
- IdP export (CSV/JSON) used as the review population, timestamped
- Slack/email approval thread from resource owner attached to the ticket
Offboarding tickets closed with 'done' but IdP deactivation timestamp shows 6+ days later. Sample the last 25 leavers and this fails on 3–5 in almost every first-year audit.
- HRIS termination export with effective date for each leaver
- Okta/Google Workspace deactivation timestamp per user
- Offboarding checklist ticket with SLA clock and completion timestamp
- Written offboarding policy stating the SLA (e.g. 24h) in effect during the window
GitHub audit log shows admin overrides on production repos without corresponding change tickets or post-hoc approval. Sampled PR fails design and operating tests simultaneously.
- GitHub branch protection settings screenshot per production repo
- Repo audit log export showing admin overrides for the window
- Emergency-change policy defining post-hoc review SLA
- Ticket + retro doc for each override with approver signature
Snapshots exist, retention is correct, but no engineer restored one during the window. Availability-scoped audits fail this control almost universally on year one.
- Restore test runbook and completed test report (dated)
- Screenshot of restored environment or database with row count / checksum
- Ticket linking the restore test to the DR calendar
- Backup-policy document specifying restore-test cadence
Sub-processor added to production, DPA signed 60 days later, security questionnaire filled in for the audit. Reverse the order or the exception writes itself.
- Vendor intake ticket with security-review checklist completed before access
- Executed DPA / MSA with date preceding data flow
- Sub-processor inventory (CSV) with owner, criticality, review date
- Latest SOC 2 / ISO 27001 report from each critical vendor
Break-glass or service accounts exempt from MFA still have interactive login enabled. Enforce non-interactive-only and vault the credentials with monitored access.
- IdP report of accounts exempt from MFA with justification per row
- Vault (1Password/Bitwarden/Secrets Manager) access log for break-glass accounts
- Policy defining break-glass usage, approvers, and post-use review
- Screenshot showing interactive login disabled for service accounts
Why SOC 2 Type II is the SaaS default
SOC 2 Type II has become the compliance lingua franca of B2B software. It is deep enough to prove controls are actually operating, flexible enough to describe modern cloud architectures, and recognized by every enterprise procurement team in North America. For SaaS founders it is almost always the first — and often only — framework needed to unlock enterprise revenue.
Scoping your first audit
Scope is the single biggest driver of cost, timeline, and effort. Every engagement starts with the Security (Common Criteria) category, which is mandatory. Availability, Confidentiality, Processing Integrity, and Privacy are optional and driven by what you promise customers contractually. Under-scope and buyers reject the report; over-scope and you pay for controls no one asked for. A senior CPA leads scoping — not a sales rep.
System description: the part founders under-invest in
Section III of the report — your system description — is what enterprise reviewers read first. It has to accurately describe your infrastructure, sub-service organizations (carve-out method for AWS/GCP is standard), boundaries, and complementary user entity controls (CUECs). We draft it with you and stress-test it against how your product actually works today, not how the marketing site describes it.
Evidence collection without slowing engineering
The traditional audit has junior consultants asking engineers for screenshots. We flip that. Our local model connects directly to GitHub, AWS, Okta, your ticketing system, and your GRC platform (if you have one) and pulls populations and evidence automatically. Your team answers narrow, targeted questions — not open-ended ones — and the CPA reviews signed evidence trails, not ad-hoc emails.
What the final report looks like
You receive a full SOC 2 Type II report — Sections I–V, signed by a licensed CPA and issued under a peer-reviewed firm — that you can share with enterprise buyers under NDA. It covers management's assertion, the independent service auditor's report, your system description, the applicable Trust Services Criteria and tests performed, and any other information. The exact format procurement and InfoSec teams expect, with no ambiguity.
Questions we hear from teams like yours.
Ready to scope your SOC 2 Type II?
Book a call and we'll walk you through timeline, scope, and pricing for your company.