Understanding SOC2 Requirements

Marcal Santos
Marcal Santos
February 24, 2026
https://secureleap.tech/blog/soc2-requirements
Understanding SOC2 Requirements

Introduction to SOC 2 Requirements

SOC 2 requirements are a set of standards designed to ensure that service organizations securely manage customer data to protect sensitive information and maintain trust with their clients. To achieve SOC 2 compliance, organizations must meet the applicable trust service criteria as determined by the scope of their services and the audit process.

Developed by the American Institute of Certified Public Accountants (AICPA), SOC 2 focuses on the five trust services criteria: security, availability, processing integrity, confidentiality, and privacy. Compliance with SOC 2 involves implementing appropriate controls and demonstrating their design and operating effectiveness through an independent audit, where auditors assess the service organization's controls against the applicable trust service criteria.

The image depicts a cover document placed on an office table, prominently titled "SOC2 Requirements." This document outlines essential controls for service organizations to protect sensitive data and ensure compliance with the five trust services criteria, focusing on security, availability, processing integrity, confidentiality, and privacy.

This framework helps organizations manage risk, ensure regulatory compliance, and requires them to regularly evaluate and document controls to ensure compliance with SOC 2 requirements. It also provides assurance to user entities by evaluating the service organization's controls to confirm that their data is handled securely and reliably.

Defining the Framework and the Trust Services Categories

SOC 2 is an acronym for System and Organization Controls. It is an auditing procedure that ensures your service providers securely manage data to protect the interests of your organization and the privacy of its clients. Unlike other certifications that have a rigid pass or fail checkmark, SOC 2 is an attestation. This means a third party auditor examines your controls and issues an opinion on whether those controls are suitably designed and operating effectively.

The requirements are organized into five Trust Services Categories. Organizations must select the security criteria and any other controls relevant to their operations and justify the inclusion or exclusion of specific criteria:

  • Security: This is known as the Common Criteria. It is the mandatory foundation of every SOC 2 report. It focuses on protecting information and systems against unauthorized access and unauthorized disclosure.
  • Availability: This requirement ensures that systems are available for operation and use as committed or agreed. This is critical for companies providing Service Level Agreements to high value clients.
  • Processing Integrity: This ensures that system processing is complete, valid, accurate, timely, and authorized. Processing integrity controls are essential for companies involved in financial transactions or complex data processing.
  • Confidentiality: This addresses the ability to protect information designated as confidential from its collection through its final disposition, emphasizing the secure handling and protection of confidential data.
  • Privacy: This category focuses on how the entity collects, uses, retains, discloses, and disposes of personal information in conformity with its privacy notice.
SOC2 Trust Services Categories

SOC 1 and SOC 2 differ in their focus. SOC 1 reports are designed to evaluate controls relevant to financial reporting and the integrity of financial data, providing assurance to auditors and stakeholders about the accuracy and reliability of financial information processed by the organization. SOC 2, on the other hand, is focused on the Trust Services Categories described above.

The Common Criteria Requirements (The Foundation)

The Common Criteria are aligned with the seventeen principles of the COSO Internal Control Integrated Framework. Establishing a strong control environment is essential, as it forms the foundation for effective internal controls by ensuring robust policies, procedures, and internal communication mechanisms are in place. These requirements are divided into several series that your organization must satisfy.

Ongoing SOC 2 requirements include regular control testing to verify the effectiveness of your security controls and identify any gaps. For SOC 2 Type 2 compliance, you must also demonstrate the operational effectiveness of controls over time, showing that they are consistently maintained and functioning as intended.

The Control Environment (CC1 Series)

The Control Environment is the set of standards, processes, and structures that provide the basis for carrying out internal control across the organization. For a CEO, this is about corporate culture and accountability.

  • Commitment to Integrity and Ethical Values: The organization must establish a formal Code of Conduct. A real world example would be a company using a platform like Notion to host its employee handbook, requiring every new hire to sign an attestation that they have read and understood the ethics policy before they receive their laptop.
  • Board Oversight: The board of directors must demonstrate independence from management and exercise oversight of the development and performance of internal control. In practice, this means holding quarterly board meetings where security risks and audit progress are documented in formal meeting minutes.
  • Organizational Structure: Management must establish structures, reporting lines, and appropriate authorities. For instance, the CTO should have a clear organizational chart showing that the Security Lead has the authority to stop a production release if a critical vulnerability is found.
  • Commitment to Competence: The entity must demonstrate a commitment to attract, develop, and retain competent individuals. This involves having formal job descriptions for every role and a standardized performance review process conducted annually.
  • Accountability: The organization must hold individuals accountable for their internal control responsibilities. This is often evidenced through a disciplinary policy that outlines consequences for repeated security violations, such as failing multiple internal phishing simulations.

Communication and Information (CC2 Series)

This series focuses on how the organization identifies, captures, and exchanges information in a form and timeframe that enables people to carry out their responsibilities.

  • Internal Communication: The entity must communicate information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. A practical example is using a Slack channel specifically for security announcements where all employees are required members.
  • External Communication: The organization must communicate with external parties regarding matters affecting the functioning of internal control. This involves having a public facing status page, such as one hosted by Atlassian Statuspage, to inform customers of system outages or security incidents.
  • Quality Information: Management must obtain or generate and use relevant, quality information to support the functioning of internal control. This means your logging systems, such as Datadog or Splunk, must be configured to provide accurate and timely data on system performance and security events.

Risk Assessment (CC3 Series)

SOC 2 requires a proactive approach to identifying and managing risk. Effective risk management is essential for fulfilling SOC 2 requirements, as it helps organizations evaluate and control cyber risks, meet trust service principles, and strengthen overall security posture. This is not a one time event but an ongoing requirement.

  • Objective Specification: The entity must specify objectives with sufficient clarity to enable the identification and assessment of risks. For example, a CTO might specify that the production database must have 99.9 percent availability.
  • Risk Identification and Analysis: The organization must identify risks to the achievement of its objectives across the entity. A real world example is conducting an annual Risk Assessment Workshop where leaders from Engineering, HR, and Sales use a risk matrix to rank threats based on likelihood and impact.
  • Fraud Risk Consideration: The organization must consider the potential for fraud in assessing risks. This involves implementing a separation of duties where the person who approves a vendor payment is not the same person who initiated the request in the accounting software.
  • Change Identification and Analysis: The entity must identify and assess changes that could significantly impact the system of internal control. This means when you migrate from an on premise server to a cloud provider like Google Cloud Platform, you must perform a new risk assessment for that specific environment.

Monitoring Activities (CC4 Series)

Monitoring ensures that the internal controls are present and functioning.

  • Ongoing and Separate Evaluations: The entity must select, develop, and perform ongoing or separate evaluations. A concrete example is a CTO setting up automated monthly access reviews where a manager receives a report of everyone on their team who has access to the production AWS environment and must confirm that the access is still required. Organizations can also automate monitoring processes to ensure continuous compliance and reduce manual effort, such as using tools that automatically collect and verify evidence of control enforcement in real-time.
  • Evaluation and Communication of Deficiencies: The organization must evaluate and communicate internal control deficiencies in a timely manner. If an internal audit finds that backups were failing for three days, this must be reported to the executive leadership immediately and tracked in a remediation log until fixed.

Control Activities (CC5 Series)

These are the specific actions established through policies and procedures that help ensure that management’s directives to mitigate risks are carried out.

  • Selection and Development of Control Activities: The entity must select and develop control activities that contribute to the mitigation of risks. This includes technical controls like implementing an Endpoint Detection and Response tool like CrowdStrike on all corporate laptops.
  • Technology General Controls: The entity must select and develop general control activities over technology to support the achievement of objectives. This involves ensuring that your cloud environment is configured according to best practices, such as using the AWS Well Architected Framework. Data protection is a critical part of these control activities, helping organizations meet regulatory and SOC 2 requirements by safeguarding sensitive information and supporting compliance with privacy laws.
  • Policy and Procedure Deployment: The organization must deploy control activities through policies that establish what is expected and procedures that put policies into action. This means having a formal Data Retention Policy that is not just a document but is enforced by automated scripts that delete data older than seven years.
Access control

Logical and Physical Access Controls (CC6 Series)

This is the most technical and detailed section of the SOC 2 requirements. It focuses on how you prevent unauthorized access to your systems and data. Logical access controls are critical for protecting system resources from unauthorized access, and are a key focus during SOC 2 audits to demonstrate effective control over user access and system security.

  • Inventory of Assets: You must maintain a complete inventory of all hardware and software. A real world example is using a tool like Kandji or Jamf to track every MacBook issued to employees, including its serial number and encryption status.
  • Registration and Authorization: The entity must register and authorize new users before granting them access. This is handled through a formal onboarding ticket in a system like Jira. When a new engineer joins, the ticket must show that their manager approved specific access to the production environment.
  • Access Revocation: Access must be removed immediately upon termination. For instance, your HR system, such as Rippling or Workday, should be integrated with your Single Sign On provider like Okta. When an employee is marked as terminated in Rippling, their access to Slack, GitHub, and AWS should be automatically deactivated.
  • Multi Factor Authentication: MFA is a non negotiable requirement for SOC 2. You must enforce MFA for every corporate application. A real world example is using Duo Security or Google Authenticator. Strong authentication mechanisms are essential to ensure that only authorized users can access sensitive systems, providing a reliable layer of protection against unauthorized access. If an auditor sees even one user who can log in to a sensitive system with only a password, that is a significant deficiency.
  • Least Privilege: You must restrict access to only what is necessary for an individual to perform their job. An example is ensuring that the marketing team has no access to the production database, and even engineers only have read only access unless they are performing a specific, approved maintenance task.
  • Encryption: Data must be protected at rest and in transit. This means your AWS S3 buckets must have AES 256 encryption enabled, and your web traffic must be forced over HTTPS using TLS 1.2 or higher.
  • Physical Access: While many companies are now remote, physical access controls still apply to data centers. If you use a provider like Equinix, you must obtain their SOC 2 Type II report annually to prove they are using biometric scanners and security guards to protect the physical servers.

System Operations (CC7 Series)

This requirement focuses on how you monitor your systems and respond to incidents.

  • Vulnerability Management: You must perform regular scans to find weaknesses in your system. A real world example is running a weekly vulnerability scan using a tool like Tenable or Qualys against your public facing IP addresses. You must also prove that critical vulnerabilities are patched within a specific timeframe, such as forty eight hours.
  • Change Detection: You must have mechanisms to alert you when unauthorized changes are made to critical files. This is often achieved using File Integrity Monitoring tools or by configuring AWS CloudTrail to alert you whenever a security group is modified.
  • Incident Response: The entity must respond to identified security incidents by executing a defined incident response program. This requires a written Incident Response Plan. A real world example is having a predefined "War Room" in Slack where the incident commander coordinates the response when a potential data breach is detected.
  • Post Incident Review: After an incident is resolved, you must perform a root cause analysis. You must document what happened, why it happened, and what changes you are making to prevent it from happening again. This documentation is a key piece of evidence for the auditor.
Change mgmt

Change Management (CC8 Series)

Change management is the process of ensuring that changes to the system are made in a controlled and authorized manner. This prevents accidental outages and malicious code injections.

  • Authorization and Testing: Every change to the production environment must be authorized. A real world example is using a GitHub pull request template. A developer writes code, and the system prevents them from merging that code until at least one other senior engineer has reviewed and approved it.
  • Segregation of Environments: You must maintain separate environments for development, testing, and production. Developers should never be able to test their code directly in the production environment.
  • Backout Plans: Every significant change should have a backout plan. If a new software deployment causes the system to crash, you must have a documented and tested process to immediately roll back to the previous stable version.
  • Emergency Changes: There must be a process for making emergency changes when a critical bug is found. This still requires documentation and a retrospective approval, but it allows for faster action during a crisis.

Risk Mitigation and Vendor Management (CC9 Series)

Your security is only as strong as your weakest vendor. This series focuses on how you manage third party risk.

  • Vendor Due Diligence: Before signing a contract with a new vendor like a CRM or an email provider, you must perform a security review. This involves asking for their SOC 2 report and reviewing it for any gaps that might affect your own security.
  • Contractual Requirements: Your contracts with vendors must include security and confidentiality clauses. This ensures that they are legally obligated to protect your data and notify you if they experience a breach.
  • Ongoing Vendor Monitoring: You must review your critical vendors annually. This means creating a spreadsheet of all vendors who have access to customer data and documenting that you have reviewed their latest security certifications. It is especially important to evaluate vendors that handle customer data to ensure they meet SOC 2 security standards and mitigate potential risks.
SOC 2 Additional Trust Services

Section 7: Additional Trust Services Criteria Requirements

While the Common Criteria cover Security, the other four trusts have specific additional requirements. System availability is especially important, as it ensures ongoing functionality and uptime of systems, which is critical for maintaining service quality and meeting SOC 2 requirements.

Availability Requirements

  • Capacity Management: The entity must maintain and evaluate current processing capacity and use of system components. For example, using AWS Auto Scaling to ensure that as traffic increases, more servers are automatically added to prevent a system crash.
  • Disaster Recovery: Disaster recovery plans play a critical role in business continuity by outlining how your organization will restore operations and maintain stability after disruptions. You must have a Disaster Recovery Plan that is tested annually. A real world example is a CTO conducting a “Tabletop Exercise” where the leadership team walks through the steps they would take if their primary cloud region was completely destroyed by a natural disaster.
  • Backups: You must perform regular backups and, more importantly, test those backups. An auditor will want to see evidence that you successfully restored a database from a backup within the last year.

Confidentiality Requirements

  • Identification of Confidential Information: You must have a process to identify what information is confidential. This often involves data tagging within your cloud environment.
  • Destruction of Confidential Information: When confidential information is no longer needed, it must be destroyed. For a digital company, this means using secure deletion protocols or physical destruction of hard drives by a certified vendor like Shred IT.

Processing Integrity Requirements

  • Input and Output Validation: The system must validate that data entered is accurate and that the output matches expectations. Validating data inputs is essential to ensure accuracy, completeness, and proper authorization throughout the data processing lifecycle. For a payroll company, this means having automated checks to ensure that a decimal point error doesn’t result in an employee being paid a million dollars. Processing integrity controls are especially important for healthcare organizations handling protected health information, as they help safeguard sensitive patient data and support compliance with regulations like HIPAA.
  • Processing Records: You must maintain a complete record of all data processing activities. This audit trail allows you to reconstruct events if a data error is discovered months later.

Privacy Requirements

  • Privacy Notice: You must provide a clear and conspicuous privacy notice to your users. This notice must explain exactly what data you collect and how you use it.
  • Consent and Choice: You must obtain explicit consent from users before collecting sensitive personal information. This is often handled through a cookie consent banner or a checkbox during the account sign up process.
  • Access and Correction: Users must have the ability to access their data and correct any inaccuracies. Your software must have a built in feature that allows users to download their personal data profile.

Readiness Assessment and Preparation

A readiness assessment is the essential first step for any organization embarking on the SOC 2 compliance journey. This process involves a comprehensive evaluation of your current internal controls, security controls, and operational processes to identify gaps relative to the trust services criteria. By conducting a readiness assessment, your organization can pinpoint areas where controls may not be designed or operating effectively, allowing you to address these issues before the formal audit begins. This proactive approach not only helps you identify gaps but also provides a clear roadmap for remediation, ensuring that your controls align with SOC 2 requirements. Ultimately, a thorough readiness assessment streamlines the audit process, reduces the risk of non-compliance, and positions your organization for a successful SOC 2 attestation.

Training and Awareness

Building a culture of security awareness is fundamental to achieving and maintaining SOC 2 compliance. Regular training ensures that every employee understands the importance of protecting customer data and sensitive data, as well as their specific responsibilities regarding access controls and data security. Effective security awareness training should cover topics such as recognizing phishing attempts, proper handling of confidential information, and the procedures for reporting security incidents. By keeping staff informed about evolving threats and best practices, organizations strengthen their overall security posture and reduce the risk of accidental data breaches. Ongoing training and awareness initiatives empower employees to play an active role in safeguarding customer data and supporting the organization’s SOC 2 compliance objectives.

Technology and Tools

Leveraging the right technology is critical for supporting SOC 2 compliance and protecting both customer data and sensitive data. Implementing robust access controls ensures that only authorized personnel can access confidential information, while intrusion detection systems provide real-time alerts for potential security incidents. Encryption technologies safeguard data both at rest and in transit, reducing the risk of unauthorized disclosure. Additionally, vulnerability management tools help organizations identify and remediate weaknesses before they can be exploited, and incident response platforms enable swift action when security incidents occur. By integrating these technologies and tools into your security framework, your organization can better protect sensitive data, prevent data breaches, and demonstrate a strong commitment to SOC 2 compliance.

Automating Monitoring and Evidence Collection

Automation is a game-changer for organizations seeking to maintain SOC 2 compliance efficiently. By automating monitoring and evidence collection, you can continuously track access controls, system configurations, and security events without the manual overhead. Automated tools can collect and organize logs, screenshots, and other evidence required to demonstrate compliance with the trust services criteria, making it easier to respond to auditor requests and prove that controls are operating as intended. Furthermore, automated monitoring helps organizations quickly detect and respond to security incidents, minimizing potential risks to customer data. Embracing automation not only simplifies compliance efforts but also ensures that your organization is always prepared to demonstrate compliance and protect sensitive information.

Incident Response and Management

A well-defined incident response and management program is vital for any organization aiming to achieve SOC 2 compliance. Your incident response plan should outline clear procedures for identifying, containing, and eradicating security incidents to protect customer data and sensitive data. This includes steps for notifying affected parties, conducting root cause analysis, and implementing corrective actions to prevent future incidents. Regular incident response training and tabletop exercises ensure that your team is prepared to act swiftly and effectively when a security incident occurs, maintaining your organization’s security posture and minimizing the impact on operations. By prioritizing incident response and management, you demonstrate your commitment to SOC 2 compliance and the ongoing protection of your clients’ most valuable information.

SOC 2 audit Process

The Audit Process: A Roadmap for Leadership

Satisfying the requirements is only half of the journey. The other half is proving it to the auditor. The audit process is crucial because it demonstrates the organization's ability to securely manage and protect sensitive data, which is essential for building trust and credibility with customers and partners. This process generally follows three phases:

  • Gap Assessment: This is a readiness exercise. You compare your current state against the SOC 2 requirements to find out what is missing. For most startups, the gaps are usually in formal documentation and automated logging.
  • Remediation: This is where the work happens. The CTO and their team implement the necessary technical controls, while the CEO and HR lead finalize the policies. This phase can take anywhere from three to nine months depending on the size of the organization.
  • The Examination Period: For a SOC 2 Type I, the auditor looks at your controls at a single point in time. For a SOC 2 Type II, the auditor examines your controls over a period of time, usually six or twelve months. During this period, you must collect evidence for every single control. For example, if your policy says you perform quarterly access reviews, you must provide four sets of dated, signed reports as proof.

How SecureLeap Supports Your SOC 2 Audit Journey

SecureLeap focuses specifically on seed to Series B technology startups and SMB SaaS companies that need SOC 2 compliance, often for the first time, and lack a full time security leader.

Core Services

SecureLeap provides practical support across the entire SOC 2 journey:

  • SOC 2 readiness assessments to identify gaps and create remediation roadmaps
  • Control design and implementation tailored to cloud native startups
  • Virtual CISO leadership for ongoing security guidance without full time headcount
  • Policy drafting that reflects how your team actually operates
  • Evidence management and coordination with CPA audit firms
  • Risk assessment and risk management program development

Compliance Automation Integration

SecureLeap helps implement and manage compliance automation platforms like Drata, Vanta, and Secureframe. Integration with your existing cloud stack (AWS, Azure, GCP, GitHub, GitLab) enables automated evidence collection and operational effectiveness monitoring throughout your audit period.

Bundled Solutions

Enterprise customers often require both a SOC 2 report and an annual application or API penetration test. SecureLeap bundles these services together, handling both your compliance preparation and your technical security validation in a coordinated engagement.

Getting Started

SecureLeap offers free SOC 2 audit readiness consultations for startup CEOs and CTOs. During this call, you will receive:

  • Custom timeline based on your deal deadlines
  • Recommended Trust Services Criteria for your market
  • Scope recommendations based on your infrastructure
  • Estimated budget range for your specific situation

Schedule your consultation to validate your assumptions about scope and avoid over engineering controls that do not match your actual risk profile or customer requirements.

FAQ for SOC2 Requirements

What are the five SOC 2 trust services criteria?
The five trust services criteria are security, availability, processing integrity, confidentiality, and privacy. Security is known as the Common Criteria and is the mandatory foundation for every SOC 2 report.

What is the difference between SOC 1 and SOC 2 reports?
SOC 1 reports evaluate controls relevant to financial reporting and the integrity of financial data. SOC 2 reports focus on the five trust services categories related to system security and data privacy.

What is the difference between a SOC 2 Type 1 and Type 2 audit?
A SOC 2 Type 1 audit examines the design of controls at a single point in time. A SOC 2 Type 2 audit evaluates the operational effectiveness of controls over a period of 6 to 12 months.

Why is multi-factor authentication mandatory for SOC 2?
Multi-factor authentication is a non-negotiable requirement because it provides a reliable layer of protection against unauthorized access. If an auditor finds even one user without MFA on a sensitive system, it is considered a significant deficiency.

How does SecureLeap help startups with SOC 2 compliance?
SecureLeap provides readiness assessments, control design, and virtual CISO leadership tailored to cloud-native startups. They also manage compliance automation tools like Drata, Vanta, and Secureframe to streamline evidence collection.

Relevant Articles

View all

SOC 2 Vulnerability Management

Avoid common audit pitfalls as a SOC 2 vulnerability manager. Discover the exact lifecycle, remediation SLAs, and tools you need to pass.
Read more

Understanding SOC2 Policies: The SOC 2 Policy Stack

Building your compliance program? Discover the 12 essential SOC 2 policies required to pass your audit and safeguard customer data.
Read more

SOC 2 Audit: Practical Guide for SaaS Startup Founders

Need a SOC 2 compliance audit to close enterprise deals? Discover what a SOC audit requires, key criteria, and how to pass quickly.
Read more