SOC 2 Compliance Requirements: The Complete Guide

If you sell software to other businesses, sooner or later a prospect's security questionnaire asks a single blunt question: "Are you SOC 2 compliant?" That question stalls deals, and understanding the SOC 2 compliance requirements behind it is the difference between closing enterprise contracts and watching them slip to a competitor. In our engagements at Atlant Security, we have guided dozens of SaaS and technology companies from a blank slate to a clean SOC 2 report, and this guide distills what we have learned into one place. My goal is to give founders, CTOs, and security leads a complete picture: what SOC 2 is, the Trust Services Criteria that define it, the concrete controls you must implement, Type I versus Type II, realistic timelines and costs, and the gaps that trip up most first-time companies.

What SOC 2 Is and Why It Exists

SOC 2 stands for System and Organization Controls 2. It is an attestation framework created and maintained by the American Institute of Certified Public Accountants (AICPA). Unlike a certification you pass or fail, SOC 2 is an independent examination in which a licensed CPA firm evaluates your controls against a defined set of criteria and issues a formal report with their professional opinion. The current criteria are the 2017 Trust Services Criteria, which the AICPA revised in 2022 (the revision refreshed the points of focus and mapped the criteria more cleanly to the underlying COSO framework). When someone talks about the modern SOC 2 requirements, they mean these 2017 criteria as revised in 2022.

SOC 2 exists because of a basic trust problem. When you hand your data to a cloud vendor, you cannot personally inspect their data center, review their access logs, or interview their engineers. SOC 2 solves this by having an independent, qualified third party do that inspection on everyone's behalf and publish a report you can rely on. That is why it has become the de facto security credential for B2B SaaS in North America.

Who Needs SOC 2 and Why

Nobody is legally required to have SOC 2. It is not a law like GDPR or a card-brand mandate like PCI DSS. The pressure is commercial. Enterprise buyers, and increasingly mid-market buyers, will not sign a contract to send you their data without proof that you protect it. Procurement teams and third-party risk management (TPRM) programs use the SOC 2 report as a gate. In practice, you need SOC 2 when:

• You are a SaaS or cloud company selling to businesses that store meaningful data with you.
• Your sales team keeps losing or stalling deals on the security review step.
• A large customer or partner has explicitly named it as a contractual requirement.
• You are raising capital or preparing for acquisition and want to remove security as a diligence risk.

The report is also a sales asset: it shortens security reviews from weeks to days because it answers most of the questionnaire in advance, which is why we treat SOC 2 as a revenue enabler rather than a cost.

The Five Trust Services Criteria (SOC 2 Trust Services Criteria)

The SOC 2 Trust Services Criteria are the backbone of the entire framework. There are five categories, and you choose which ones your report covers based on the promises you make to customers and the nature of your service.

• Security (the Common Criteria). This is mandatory in every SOC 2 report. It covers protection of the system against unauthorized access, disclosure, and damage. Everything else is optional and layered on top. Security is expressed through the Common Criteria, CC1 through CC9, which we break down below.
• Availability. Whether the system is available for operation and use as committed or agreed. Include this when you make uptime commitments in SLAs. It brings in requirements around monitoring, capacity planning, backups, and disaster recovery. Most SaaS companies include it.
• Confidentiality. Whether information designated as confidential is protected as committed. Include this when you handle sensitive business data such as contracts, financials, or intellectual property that is not personal data. It emphasizes data classification, encryption, and controlled disposal.
• Processing Integrity. Whether system processing is complete, valid, accurate, timely, and authorized. Include this when the correctness of your processing is the product itself, for example payment processing, payroll, analytics, or transaction platforms. Companies without such promises usually leave it out.
• Privacy. Whether personal information is collected, used, retained, disclosed, and disposed of in line with your privacy notice and criteria based on the AICPA Privacy Management Framework. Include this when you handle significant volumes of personal data and want to demonstrate privacy governance. Note that Privacy here is about personal information specifically, whereas Confidentiality covers any confidential data. If your obligations are health-related, this often sits alongside HIPAA work rather than replacing it.

Our standard advice: almost everyone starts with Security plus Availability, adds Confidentiality if they hold sensitive customer business data, adds Privacy if personal data is central to the product, and adds Processing Integrity only if accurate processing is an explicit promise. Adding categories you do not need only enlarges scope and cost without a commercial payoff.

The Common Criteria (CC1-CC9) Broken Down

The Common Criteria are where the real SOC 2 requirements live. They map to the COSO internal control framework across nine areas, and every control you implement traces back to one of them. Here is what each area demands in practice.

CC1: Control Environment

This is the tone from the top: evidence that your organization treats security as a matter of governance. In practice you need documented commitment to integrity and ethical values, defined organizational structure and reporting lines, leadership oversight of security, job descriptions that include security responsibilities, background checks on new hires, and a code of conduct that employees acknowledge. For a small company this can be lightweight, but it must be real.

CC2: Communication and Information

You must generate and use relevant, quality information to support security, and communicate it both internally and externally. Concretely, that means published internal policies employees can find and acknowledge, security responsibilities communicated to staff, and a way for external parties to learn about your commitments and report issues. Your security policies, acceptable use policy, and a public-facing security or trust page all support CC2.

CC3: Risk Assessment

You must formally identify, analyze, and manage risks to your objectives, including fraud risk and the impact of change. This requires a documented risk assessment performed at least annually: identify assets and threats, rate likelihood and impact, and record how you treat each risk. A living risk register is the single artifact auditors expect here, and many first-timers have none at all.

CC4: Monitoring Activities

You must evaluate whether your controls are actually operating, and remediate deficiencies. This means ongoing monitoring plus periodic evaluation: internal control reviews, vulnerability scans, penetration test findings tracked to closure, and management review of security metrics. CC4 proves you watch your own controls, not just that they exist on paper.

CC5: Control Activities

These are the control activities that mitigate risk to acceptable levels, including selecting, developing, and deploying controls through policies and procedures. CC5 ties your risk assessment to the specific technical and administrative controls you chose, and confirms those controls are embedded in documented procedures rather than living only in someone's head.

CC6: Logical and Physical Access Controls

This is the largest and most scrutinized area. It covers who can get to your systems and data, and how you restrict them. Requirements include identity and access management with the principle of least privilege, multi-factor authentication (MFA) on all critical systems, a formal user provisioning and de-provisioning process (especially prompt off-boarding when someone leaves), periodic access reviews, encryption of data in transit and at rest, secure key management, protection against malware, and physical security of facilities and hardware (for cloud-hosted companies this is largely inherited from AWS, Azure, or GCP through their own SOC 2 reports). Because most real-world incidents start with access, expect deep testing here.

CC7: System Operations

This covers detecting and responding to anomalies and incidents. You need infrastructure and application logging, security monitoring and alerting, vulnerability detection, and a documented, tested incident response process. CC7 is where your logging and monitoring stack, your SIEM or log aggregation, and your incident response plan all get examined, and auditors often ask to see a real alert investigated end to end.

CC8: Change Management

You must authorize, design, develop, test, approve, and implement changes to infrastructure and software in a controlled way. In practice: a defined SDLC, code review before merge, separation between development and production, testing before release, change approval, and the ability to roll back. For engineering-led companies this maps neatly onto pull request workflows and CI/CD pipelines, provided you can produce the evidence trail.

CC9: Risk Mitigation

This addresses how you mitigate risk from business disruptions and from vendors. It requires a vendor and third-party risk management program (assessing the subprocessors and SaaS tools you rely on, often by collecting their SOC 2 reports) and risk mitigation activities such as insurance and business continuity planning. As your supply chain grows, so does CC9, because every critical vendor must be assessed and monitored.

SOC 2 Type I vs Type II Requirements

SOC 2 comes in two flavors, and the distinction matters enormously for both effort and credibility.

Type I examines the design of your controls at a single point in time. The auditor confirms that, as of a specific date, you have the right controls in place and they are suitably designed to meet the criteria. It is a snapshot. A Type I report is faster and cheaper to obtain and can be a reasonable first step to show momentum, but it says nothing about whether your controls actually worked over time.

Type II examines both the design and the operating effectiveness of your controls over a period of observation, typically 3 to 12 months (six months is a very common first window, with twelve months for a mature, recurring report). The auditor samples evidence across the whole period to confirm the controls operated consistently, not just on one day. This is what the market actually wants. When a customer asks for "your SOC 2," they almost always mean a Type II report. The SOC 2 Type II requirements are effectively the same controls as Type I, but you must sustain and evidence them continuously throughout the observation window.

Our practical guidance: if a customer needs proof quickly, do a Type I to unblock the deal and begin the Type II observation period immediately afterward. Many companies skip Type I entirely and go straight to a Type II with a short three to six month initial window. There is no rule that you must do Type I first.

The Concrete SOC 2 Requirements: Controls You Must Implement

Criteria are abstract. Here is the concrete work we implement in nearly every SOC 2 readiness project, and it doubles as a de facto checklist of the SOC 2 requirements auditors expect to see.

Policies and Procedures (the roughly 20 policy areas)

SOC 2 is heavily documentation-driven. You need a coherent set of written, approved, and communicated policies. The typical set includes:

1. Information Security Policy (the master policy)
2. Acceptable Use Policy
3. Access Control Policy
4. Password and Authentication Policy
5. Data Classification and Handling Policy
6. Encryption and Key Management Policy
7. Risk Assessment and Management Policy
8. Vendor and Third-Party Management Policy
9. Change Management Policy
10. Secure Software Development (SDLC) Policy
11. Logging and Monitoring Policy
12. Vulnerability and Patch Management Policy
13. Incident Response Policy and Plan
14. Business Continuity and Disaster Recovery Plan
15. Backup Policy
16. Human Resources and Personnel Security Policy (including onboarding and offboarding)
17. Security Awareness and Training Policy
18. Physical and Environmental Security Policy
19. Data Retention and Disposal Policy
20. Asset Management Policy

Some companies add a Privacy Policy, a Remote Work Policy, and a Code of Conduct. The critical point is that policies cannot be shelfware. Auditors test that they are approved by management, communicated to staff, acknowledged, and actually followed.

Access Control and MFA

Enforce least privilege everywhere. Turn on MFA for email, your identity provider, cloud consoles, code repositories, and any production access. Use a central identity provider (SSO) so provisioning and de-provisioning are consistent. Run access reviews at least quarterly and keep the evidence. Remove departing employees' access on their last day and document it.

Encryption

Encrypt data in transit with TLS and data at rest using platform-native encryption (for example, database and storage encryption from your cloud provider). Manage keys properly, restrict who can access them, and document your standards in the encryption policy.

Logging and Monitoring

Centralize logs from infrastructure and applications, retain them for a defined period, and alert on security-relevant events. You should be able to answer "who did what, when" and demonstrate that alerts are triaged.

Vulnerability Management

Run regular vulnerability scans, patch on a defined schedule based on severity, and obtain at least an annual penetration test from a qualified third party. Track findings to remediation and keep the tickets as evidence.

Change Management

Require code review and approval before production deployment, keep development and production separated, and maintain an auditable trail (your Git history and CI/CD logs usually suffice).

Vendor and Risk Management

Maintain an inventory of your critical vendors and subprocessors, collect and review their SOC 2 reports or security documentation, and reassess them periodically. Maintain a risk register that you review at least annually.

Incident Response

Have a written incident response plan with defined roles, severity levels, and communication steps, and test it at least once a year with a tabletop exercise. Keep records of any real incidents and how you handled them.

Business Continuity and Disaster Recovery

Document how you keep the business running through disruption, define recovery objectives (RTO and RPO), back up data, and test that you can restore from backup.

Evidence Collection and the Auditor Relationship

Throughout the observation period you must continuously collect evidence: access review records, tickets, scan results, training completions, meeting minutes, and system configurations. Most companies use a compliance automation platform (Vanta, Drata, Secureframe, or similar) to pull evidence automatically from cloud and SaaS tools. The audit itself must be performed by an independent, licensed CPA firm, and that firm cannot also be the party that built your controls. This is where an independent partner such as our SOC 2 compliance consulting team adds value: we build and operate the program while you engage a separate CPA firm for the attestation.

How Long SOC 2 Takes

Timelines depend on your starting maturity, but the shape is predictable.

Readiness phase (roughly 60 to 90 days). This is where you write policies, implement missing controls, deploy a compliance automation tool, and close the gaps a readiness assessment surfaces. A company with modern cloud infrastructure and decent engineering hygiene is often ready in two to three months; companies starting from nothing need longer.

Type I (optional, about 2 to 4 weeks of audit). If you choose to do one, the point-in-time examination is relatively quick once you are ready.

Type II observation window (3 to 12 months). Your controls must operate throughout this period while you collect evidence. A first Type II often uses a three to six month window; recurring annual reports use twelve months.

Audit fieldwork and report (about 4 to 8 weeks). After the window closes, the auditor tests evidence and issues the report.

Realistically, from a standing start to a Type II report in hand, plan on roughly six to nine months. Focused effort and good tooling compress the front end, but you cannot compress the observation window, because time passing is the whole point.

What SOC 2 Costs

SOC 2 has several cost components, and the audit fee is only one of them.

• The CPA audit. For most SaaS companies, a SOC 2 Type II audit runs from about $15,000 to $50,000 depending on scope, the number of Trust Services Criteria, and the size and complexity of your systems. A narrow Security-only report for a small company sits at the low end; multiple criteria and larger environments push toward the high end. A Type I is typically cheaper.
• Compliance automation tooling. Platforms like Vanta, Drata, or Secureframe generally cost somewhere in the range of $7,000 to $25,000 per year for a small to mid-size company. They pay for themselves in saved evidence-collection time.
• Consulting and readiness support. If you bring in help to build the program, write policies, and manage the audit, this varies widely with scope. Many companies also cover this function with a fractional security leader through virtual CISO services rather than a full-time hire.
• Penetration testing. Budget roughly $5,000 to $30,000 per year for an independent test, depending on scope.
• Internal time. The least visible but very real cost: engineering and operations effort to implement controls and gather evidence.

All in, a first SOC 2 Type II for a small SaaS company commonly lands in the $30,000 to $80,000 range across the first year once you total audit, tooling, testing, and support. Renewals cost less because the heavy lifting is done.

The Most Common Gaps We See and How to Close Them

Across our SOC 2 engagements the same gaps appear again and again. Fixing these early saves months.

• Policies exist but nobody follows them. Templates downloaded and never operationalized. Close it by tailoring policies to how you actually work and building the acknowledgement and review process.
• No risk assessment. CC3 has no artifact. Close it by running a documented annual risk assessment and maintaining a risk register.
• Inconsistent MFA and access reviews. MFA on some systems, not all; access reviews never happen. Close it by centralizing on SSO and scheduling quarterly reviews with saved evidence.
• Sloppy off-boarding. Ex-employees keep access. Close it with a documented, checklist-driven de-provisioning process executed on the last day.
• No centralized logging or alerting. Logs scattered and unmonitored. Close it by aggregating logs and defining security alerts.
• Untested incident response and disaster recovery. Plans on paper, never exercised. Close it with an annual tabletop and a real backup restore test.
• Vendor management as an afterthought. No inventory, no reviews of subprocessors. Close it by building a vendor register and collecting their reports.
• Evidence collected in a panic at the end. Scrambling for a whole period's evidence at audit time. Close it by automating evidence collection from day one of the observation window.

If you want an objective read on where you stand before committing to an audit, an independent IT security audit will surface these gaps faster than a self-assessment, because an outside reviewer is not blind to the controls you assume are working.

A Practical SOC 2 Readiness Checklist

1. Decide which Trust Services Criteria apply (Security always, plus Availability, Confidentiality, Privacy, or Processing Integrity as relevant).
2. Decide Type I versus Type II and the length of your observation window.
3. Define your system boundary and scope (which products, environments, and data are covered).
4. Select and deploy a compliance automation platform and connect it to your cloud and SaaS tools.
5. Write, approve, and publish the full policy set, and collect employee acknowledgements.
6. Run a documented risk assessment and build a risk register.
7. Enforce MFA everywhere and centralize identity with SSO.
8. Implement least-privilege access and schedule quarterly access reviews.
9. Encrypt data in transit and at rest and document key management.
10. Centralize logging and configure security alerting.
11. Stand up vulnerability scanning, a patch schedule, and an annual penetration test.
12. Formalize change management with code review, approvals, and environment separation.
13. Build a vendor inventory and collect subprocessor security reports.
14. Document and tabletop-test incident response, business continuity, and disaster recovery, including a backup restore test.
15. Deliver security awareness training and record completion.
16. Run a readiness assessment or gap analysis and remediate findings.
17. Engage an independent CPA firm and begin the observation period.
18. Collect evidence continuously, then complete audit fieldwork and receive your report.

Work through this list in order and you will have covered the substance of the SOC 2 compliance requirements before an auditor ever opens your environment.

SOC 2 Compliance Requirements FAQ

Is SOC 2 a certification?

No. SOC 2 is an attestation report issued by an independent CPA firm, not a pass or fail certification. The auditor examines your controls against the Trust Services Criteria and expresses a professional opinion. You receive a report you can share with customers under NDA, not a certificate or logo you passed a test to earn.

Which Trust Services Criteria do I actually need?

Security (the Common Criteria) is mandatory in every SOC 2 report. Most SaaS companies add Availability. Add Confidentiality if you hold sensitive customer business data, Privacy if personal data is central to your product, and Processing Integrity if the accuracy of your processing is an explicit promise. Only include what genuinely applies, because each added category increases scope and cost.

What is the difference between SOC 2 Type I and Type II?

Type I evaluates whether your controls are suitably designed at a single point in time. Type II evaluates both design and operating effectiveness over a period of 3 to 12 months. The market generally expects Type II, because it proves your controls actually worked over time rather than just existing on one day.

How long does SOC 2 take?

Readiness typically takes about 60 to 90 days, followed by a Type II observation window of 3 to 12 months and roughly 4 to 8 weeks of audit fieldwork and reporting. From a standing start, plan on roughly six to nine months to a Type II report. You cannot shorten the observation window because sustained operation over time is the point.

How much does SOC 2 cost?

The CPA audit alone generally runs from about $15,000 to $50,000 for a Type II. Add compliance automation tooling (roughly $7,000 to $25,000 per year), an annual penetration test, and consulting or internal time. A first-year total for a small SaaS company commonly lands in the $30,000 to $80,000 range, with cheaper renewals thereafter.

Do I need a compliance tool like Vanta or Drata?

You are not required to use one, but for most companies it is worth it. These platforms automate evidence collection from your cloud and SaaS systems, monitor controls continuously, and dramatically reduce the manual work of an audit. Remember that the tool is not the auditor; you still need an independent CPA firm to perform the examination.

How is SOC 2 different from ISO 27001, PCI DSS, or HIPAA?

SOC 2 is a flexible attestation against the Trust Services Criteria, dominant in North American B2B SaaS. ISO 27001 is an international certification of an information security management system. PCI DSS is a prescriptive standard for payment card data, and HIPAA is a US law governing protected health information. They overlap heavily in controls, so a strong SOC 2 program is a solid foundation for the others.

Ready to get started? Atlant Security helps companies close security gaps and pass compliance fast, led personally by a former Microsoft security consultant with 200+ assessments across 14 countries. Book a free strategy call and get a fixed-price proposal within 24 hours.