SOC 2 Type II for SaaS: What Your Code Needs to Pass

SOC 2 Type II is the standard enterprise customers require before signing SaaS contracts at meaningful deal sizes. Unlike SOC 2 Type I, which evaluates whether your controls are designed correctly at a point in time, SOC 2 Type II audits whether those controls operated effectively over a period — typically six to twelve months.

What most engineering teams underestimate is the degree to which SOC 2 Type II is a code audit. Your policies and documentation matter, but auditors sample actual system behavior. They examine logs, test controls, and in many cases review code to verify that security requirements are implemented at the application layer, not just described in a policy document.

The Trust Services Criteria That Affect Your Code

SOC 2 is organized around Trust Services Criteria (TSC). All engagements must cover the Security criteria (CC series). Additional criteria — Availability, Processing Integrity, Confidentiality, and Privacy — are included based on the services you offer. For most SaaS companies, Security and Confidentiality are the relevant criteria.

Within the Security criteria, the following control categories have direct code-level implications: logical and physical access controls (CC6), system operations (CC7), change management (CC8), and risk mitigation (CC9). Each maps to specific implementation requirements that must exist in your application code and infrastructure.

Access Control: CC6 Requirements at the Code Level

CC6 is where most application-level SOC 2 findings originate. The criteria require that access to data and systems is restricted to authorized users and that access is revoked promptly when no longer needed. For a SaaS application, this translates to specific implementation requirements.

Authentication Strength

Auditors will ask how you authenticate users and service accounts. Password-only authentication without MFA is increasingly flagged as a control weakness. Service account credentials must be managed as secrets — not hardcoded, not in configuration files, not shared between services. Certificate-based or token-based authentication with short expiration windows and rotation schedules satisfies the control better than long-lived static credentials.

Authorization Enforcement

Role-based access control (RBAC) or attribute-based access control (ABAC) must be enforced at the application layer, not just at the UI layer. Auditors routinely test horizontal privilege escalation — attempting to access another user's data by manipulating resource identifiers — and vertical privilege escalation — attempting to perform administrative actions with a standard user account. If your authorization checks exist only in the frontend, they will fail these tests.

Least Privilege

Database accounts used by your application should have only the permissions required for their function. An application account that has administrative privileges on its own database is a control finding. IAM roles for cloud services should follow the same principle: a service that only needs to read from a specific S3 bucket should not have account-wide S3 read permission.

Access Revocation

Session management must support prompt revocation. Long-lived session tokens that cannot be invalidated server-side fail the access revocation requirement. If a user's account is disabled, active sessions must be terminated. Auditors verify this by testing the behavior of tokens issued to subsequently disabled accounts.

Encryption: What Auditors Actually Check

SOC 2 requires encryption of data in transit and at rest for sensitive data. "Sensitive data" is broadly interpreted to include any data that would cause harm to customers if disclosed. For SaaS companies handling customer business data, this effectively means all customer data.

In transit, TLS 1.2 minimum is the current baseline; TLS 1.3 is increasingly expected. Auditors check that HTTP connections are redirected to HTTPS, that API endpoints are not accessible over HTTP, and that certificate configurations do not include deprecated cipher suites.

At rest, auditors verify that database encryption is enabled, that encryption keys are managed separately from the data they protect, and that backup data is encrypted with the same standards as primary data. Application-layer encryption for highly sensitive data fields (SSNs, financial account numbers, health information) provides defense in depth beyond storage-layer encryption.

Audit Logging: CC7 Requirements

CC7 requires monitoring of systems for unauthorized access and anomalous activity. For your application, this means comprehensive audit logging with specific properties that auditors will verify.

Logs must capture: authentication events (login attempts, successes, failures, MFA challenges); authorization events (access denials, privilege escalations); significant data access events (bulk data exports, access to sensitive records); and administrative actions (user creation, permission changes, configuration modifications).

Each log event must include: timestamp (UTC, with millisecond precision), actor identity (user ID or service account), action performed, resource affected, outcome (success or failure), and source IP address. Logs missing these fields are a finding.

Log integrity is a separate requirement: logs must be stored in a tamper-resistant location that is distinct from the system generating the logs. Application logs written only to the same server's local filesystem fail this control because a compromised server could allow log modification or deletion.

Change Management: CC8 at the Code Level

CC8 requires that changes to production systems go through a defined, controlled process. For engineering teams, this maps to your deployment pipeline requirements. Auditors will ask for evidence that all production code changes were reviewed before deployment, that deployments are tracked, and that rollback capabilities exist.

Pull request requirements — mandatory peer review, automated testing gates, and approval workflows — satisfy the code review requirement. Auditors sample merged pull requests from the audit period and verify that required approvals are present. Pull requests merged without required approvals, or direct pushes to production branches that bypass the review process, are findings.

Infrastructure as code (IaC) is increasingly expected: if your infrastructure is provisioned manually rather than through version-controlled templates, auditors may flag the absence of change tracking for infrastructure changes.

Vulnerability Management

SOC 2 does not prescribe a specific vulnerability scanning cadence, but auditors expect evidence of a systematic vulnerability management program. This includes evidence that dependency vulnerabilities are tracked, that a defined SLA exists for remediating critical and high findings, and that the SLA is actually followed based on observable ticket or commit history.

Penetration testing evidence — a third-party pen test report from within the past year and evidence that findings were remediated — is not required by SOC 2 but is expected by enterprise security review teams conducting vendor assessments alongside your SOC 2 report. Planning for penetration testing as part of your SOC 2 preparation saves time in the enterprise sales process.

Common Findings That Delay SOC 2 Type II

Based on patterns across SaaS companies pursuing SOC 2 Type II, the most common code-level findings are: authorization checks missing at the API layer (present only at the UI layer), audit logs missing required fields or stored in revocable locations, database accounts with excessive permissions, hardcoded credentials in configuration files or version control, and session tokens that survive account deactivation.

Each finding triggers a remediation requirement and, in a Type II audit, evidence that the remediated control operated effectively for the remainder of the audit period. A finding discovered late in the audit window can extend the total audit timeline by months if the evidence collection period must restart.

The most efficient path through SOC 2 Type II is a comprehensive code-level security audit conducted before the audit observation period begins, remediation of all findings, and then starting the observation period with a clean baseline.