SOC 2 Security Requirements: A Technical Guide for SaaS Companies
SOC 2 compliance is the security credential that enterprise procurement teams require before signing a SaaS contract. Unlike prescriptive standards such as PCI DSS, SOC 2 is a framework built around five Trust Service Criteria — giving you flexibility in how you meet them, but requiring you to demonstrate that your controls are real, operational, and continuous.
This guide breaks down what SOC 2 Type II actually requires at the technical level: what your infrastructure, application, and web layer need to look like for an auditor to issue a clean opinion.
Check your compliance posture: Free ZeriFlow security scan →
SOC 2 Type I vs. Type II: Why the Distinction Matters
A SOC 2 Type I report evaluates whether your controls are suitably designed at a point in time. A SOC 2 Type II report evaluates whether those controls operated effectively over a defined period — typically six to twelve months.
Enterprise customers almost universally ask for Type II. A Type I is useful as a first step, but it carries limited assurance because it does not prove your controls actually ran. Type II is harder to obtain and more valuable precisely because it requires evidence of continuous operation.
The audit period matters: if you deploy a new authentication control in month one and get audited in month three, you only have three months of evidence. Most auditors want at least six months. This means the clock starts the day you implement a control — not the day you decide to pursue SOC 2.
The Five Trust Service Criteria
The American Institute of CPAs (AICPA) defines five Trust Service Criteria (TSC). Every SOC 2 report must address Security (CC). The other four are optional, but most SaaS companies pursuing enterprise contracts add Availability and Confidentiality.
1. Security (Common Criteria — CC) — The mandatory criterion. Covers logical and physical access controls, threat and vulnerability management, change management, incident response, and risk assessment. This is the largest section and the one with the most direct web-layer implications.
2. Availability (A) — The system is available for operation and use as committed. Relevant SLAs, DDoS protection, redundancy, backup and recovery, and uptime monitoring.
3. Processing Integrity (PI) — Processing is complete, valid, accurate, timely, and authorized. Primarily relevant for financial processing or data pipelines.
4. Confidentiality (C) — Information designated as confidential is protected. Encryption at rest and in transit, data classification, retention and disposal.
5. Privacy (P) — Personal information is collected, used, retained, disclosed, and disposed of in conformity with the entity's privacy notice. Heavily overlaps with GDPR and CCPA compliance.
Encryption in Transit: The Non-Negotiable Baseline
SOC 2 CC6.7 requires that the transmission of confidential information is encrypted. In practice, this means:
- TLS 1.2 minimum, TLS 1.3 preferred across all endpoints — web application, API, internal service-to-service, database connections, and administrative interfaces.
- HSTS enabled to prevent protocol downgrade attacks. Your
Strict-Transport-Securityheader should includeincludeSubDomainsand amax-ageof at least one year. - Certificate lifecycle management — expired certificates are not just a user experience problem; they are an evidence gap. Auditors will check that certificate renewal processes exist and run.
- No weak cipher suites — RC4, DES, 3DES, and export ciphers should be explicitly disabled.
Encryption at rest (CC6.1) requires that sensitive data stored in databases, object storage, and backups is encrypted with documented key management procedures.
ZeriFlow checks your public-facing TLS configuration — protocol versions, cipher ordering, certificate validity, and HSTS — giving you an outside-in view of what an auditor's external scan would surface.
Access Controls and Logical Security
The largest block of Common Criteria requirements (CC6.1 through CC6.8) addresses how you control who can access what. The technical controls that matter most:
Multi-Factor Authentication — Required for all access to production systems, administrative consoles, cloud provider accounts, and any system storing sensitive data. TOTP-based MFA is the minimum; hardware keys (FIDO2/WebAuthn) are preferred for privileged access.
Principle of Least Privilege — User and service account permissions should be scoped to the minimum required. Quarterly access reviews (documented) are the standard evidence item here.
Single Sign-On (SSO) with audit logging — SSO centralizes access control and ensures every authentication event is logged. Logs must be tamper-evident and retained for the audit period.
Privileged Access Management (PAM) — Production database access, cloud root accounts, and infrastructure management should use just-in-time access or break-glass procedures with mandatory logging.
Session management — Application sessions should expire after inactivity, use Secure and HttpOnly cookie flags, and implement CSRF protection.
Security Headers and the Application Layer
SOC 2 CC7.1 requires that the entity uses detection and monitoring procedures to identify changes to configurations. CC6.6 addresses logical access security measures against threats from outside the boundaries of the system. HTTP security headers are a direct technical control in both areas.
The headers most relevant to SOC 2 evidence:
- Content-Security-Policy — Demonstrates active control over what executes in the browser context of your application.
- X-Frame-Options — Prevents clickjacking, relevant to CC6.6.
- X-Content-Type-Options: nosniff — Reduces the attack surface for content injection.
- Referrer-Policy — Controls information leakage via the Referer header.
Missing headers are not automatically an audit finding, but they will appear in a penetration test report — and penetration testing is required evidence under CC4.1.
Logging, Monitoring, and Incident Response
SOC 2 Type II is fundamentally an audit of continuous operation. The most common gap companies discover during their first Type II audit is not missing controls — it is missing evidence that controls ran.
What you need to log: - All authentication events (success and failure) with timestamps, user identifiers, and source IPs. - All administrative actions (permission changes, configuration modifications, data exports). - All access to sensitive data. - Application errors and exceptions. - Infrastructure events (deployments, scaling events, security group changes).
Log management requirements: - Logs must be retained for the audit period plus buffer (typically 13 months). - Logs must be centralized (SIEM or log aggregation platform) — scattered logs across individual servers do not satisfy an auditor. - Log integrity must be protected — logs should be immutable or append-only, and access to modify them restricted.
Incident response — CC7.3 through CC7.5 require that security incidents are identified, contained, and remediated with documented procedures. Your incident response plan must be tested (tabletop exercise is acceptable) and the test must be documented.
Continuous Monitoring: Why SOC 2 Type II Demands Automation
The "Type II" designation means your controls must be continuous, not point-in-time. The most common failure mode for first-time SOC 2 companies is implementing controls in the months before the audit window and then discovering they broke silently at some point during the period.
Effective continuous monitoring for SOC 2 includes:
- Automated vulnerability scanning on a defined cadence (weekly is the common standard).
- Infrastructure drift detection — alerting when cloud configurations deviate from your baseline.
- Dependency vulnerability tracking — SCA (Software Composition Analysis) tools that flag new CVEs in your third-party libraries.
- Uptime and certificate monitoring — automated alerts before certificates expire.
- Web security header monitoring — deployment pipelines can inadvertently strip security headers; automated scanning catches regressions before auditors do.
ZeriFlow provides the continuous external scanning layer — running the same checks an auditor's tool would run, on demand or on schedule, so you catch configuration regressions before they become audit findings.
FAQ
Q: How long does it take to get SOC 2 Type II certified?
A: The audit period itself is typically 6–12 months. Before that, you need a readiness phase to implement missing controls — typically 3–6 months for an early-stage SaaS company. Total timeline from decision to report: 9–18 months. Compliance automation platforms (Vanta, Drata, Secureframe) can compress the readiness phase by providing automated evidence collection and pre-mapped controls.
Q: Is SOC 2 legally required?
A: No — SOC 2 is a voluntary framework. However, it is contractually required by most enterprise customers and many mid-market companies as a condition of vendor onboarding. Some regulated industries (healthcare, finance) may require SOC 2 alongside sector-specific requirements like HIPAA or SOX.
Q: What is the difference between SOC 2 and ISO 27001?
A: SOC 2 produces an auditor's opinion report (not a certificate) and is primarily used in North American markets. ISO 27001 produces a certificate issued by an accredited certification body and is recognized globally, particularly in Europe and Asia. Many companies pursue both: ISO 27001 for international sales and SOC 2 for US enterprise deals. The control frameworks overlap significantly.
Q: Do security headers show up in a SOC 2 audit?
A: Not explicitly — the SOC 2 criteria do not enumerate specific HTTP headers. However, penetration testing (a required activity) will flag missing or misconfigured security headers as findings. If those findings are not remediated and documented, they can affect the auditor's opinion on the effectiveness of your security controls.
Q: Can a startup with 10 engineers realistically achieve SOC 2 Type II?
A: Yes, but it requires deliberate prioritization. The minimum viable SOC 2 program for a small SaaS company typically involves: a compliance automation platform, a cloud provider with good native security tooling (AWS/GCP/Azure), SSO with MFA enforced, a centralized logging solution, an incident response plan, and quarterly access reviews. The technical controls are achievable; the operational overhead — evidence collection, vendor reviews, security awareness training — is where small teams struggle most.
Conclusion
SOC 2 Type II is not a product feature — it is an operational posture that your engineering, security, and compliance teams maintain continuously. The technical foundations are clear: TLS enforced everywhere, access logs centralized and retained, security headers deployed, MFA on all production access, and automated scanning to catch regressions.
The companies that pass their first Type II audit without material exceptions are the ones that treated control implementation as an engineering project, not a documentation exercise — and that verified their controls from the outside in, the same way an auditor would.