SOC 2 Report: Example, Structure Breakdown and Template

February 20, 2025

Obtaining a SOC 2 report helps establish trust with stakeholders, strengthen your security infrastructure, and secure deals with larger accounts that require SOC 2 compliance.

But what does the final SOC 2 report look like, and what information does it contain?

In this article, we provide a SOC 2 Type 2 report example to help you understand its structure and how to interpret it.

What is a SOC 2 report?

A SOC 2 report, prepared by licensed CPA firms, outlines an organization’s information security controls and their alignment with SOC 2 criteria. It assesses security practices based on the five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy

There are two types of SOC 2 reports: SOC 2 Type 1 and SOC 2 Type 2. SOC 2 Type 1 reviews the design of your controls at a specific point in time, whereas SOC 2 Type 2 assesses the effectiveness of your controls over a defined period, typically ranging from three to twelve months.

SOC 2 reports help build trust with customers, demonstrate compliance with security regulations, and reduce data breach risks. They are crucial for service organizations handling customer data, such as SaaS providers, healthcare providers, and financial institutions.

SOC 2 reports, especially Type 2, are typically conducted annually. Type 1 is often a one-time assessment used as a baseline before moving to Type 2 audits.

How is the SOC 2 report example structured?

A SOC 2 Type 2 report evaluates an organization’s controls related to security, availability, processing integrity, confidentiality, and privacy. It outlines the scope of the audit and the period it covers, helping organizations demonstrate their compliance with SOC 2 Type 2 standards.

The report is usually structured according to the AICPA report example. SOC 2 Type 2 reports have a similar structure, but they can differ depending on the industry, audit criteria, and the specific auditor conducting the assessment.

Note: Here is a SOC 2 Type 2 report example. Of the five trust criteria, our report example covers the controls related to security, confidentiality, and availability.

What is included in a SOC 2 Type 2 report?

1. Independent service auditor’s opinion

Independent service auditor’s opinion Template

Explanation of the example:

Scope of the audit:

In this section, the auditor examines the company’s description of its system over a specified audit period, using the AICPA’s Description Criteria for SOC 2 type 2 reports as the basis. The purpose of the audit is to evaluate the suitability of the system’s design and the operating effectiveness of its controls. This examination focuses on ensuring that the company’s service commitments regarding Security, Confidentiality, and Availability are met according to the Trust Service Criteria. The auditor’s goal is to provide reasonable assurance that the system functions as expected during the audit period.

Service organization (company) responsibilities:

The company is responsible for preparing an accurate and complete system description and ensuring its alignment with the Description Criteria. It must design, implement, and operate effective controls to meet its service commitments and system requirements. Furthermore, the company is tasked with identifying potential risks to achieving its service commitments and implementing appropriate measures to address those risks.

Auditor responsibilities:

The auditor is responsible for expressing an opinion on whether the system description is fairly presented and whether the controls are suitably designed and operating effectively to meet the applicable Trust Service Criteria. The auditor conducts the examination in accordance with the attestation standards set by the American Institute of Certified Public Accountants (AICPA). However, the audit does not cover the controls of complementary user entities or sub-service organizations, such as data center services, which may impact the overall system.

Opinion:

The auditor concludes that the system description accurately reflects the design and implementation of the company’s system over the audit period. The controls are suitably designed and operated effectively to meet the Trust Service Criteria for the duration of the audit period. While acknowledging inherent limitations in the design and effectiveness of controls, the auditor highlights the possibility of risks arising from system changes. The report is marked as restricted, meaning it is intended solely for use by the company, its clients, auditors, and other relevant stakeholders with knowledge of the specific service being provided.

Conclusion:

The auditor’s opinion affirms that the system description is fair and that the controls are designed and operated to meet the required trust services criteria. This provides reasonable assurance that the company’s service commitments were achieved during the audit period, though there are inherent limitations to control effectiveness. The report is tailored for specific parties and should not be used outside of that context.

2. Management assertion

Explanation of the example:

Scope of the assertion:

Management provides a description of the company’s system for the audit period, following AICPA’s criteria for a SOC 2 Type 2 report. This description aims to inform users about the system’s design and how controls meet the Trust Services Criteria for Security, Availability, and Confidentiality. The company uses a third-party Cloud Service Provider, but the assertion does not cover controls at sub-service organizations.

Description and control coverage:

The assertion includes information on system components like infrastructure, software, personnel, procedures, and data. It explains how data is handled with third parties and outlines relevant procedures for ensuring secure processing and storage. The assertion details how controls meet the trust service criteria, covering complementary user-entity controls and subservice organizations’ controls where applicable, but excludes subservice and user-entity controls.

Management’s confirmation:

Management confirms that, to the best of their knowledge, the description fairly represents the system throughout the audit period. They assert that the controls were suitably designed to meet the trust services criteria, assuming user-entity and subservice organization controls operate effectively. The description is intended to meet the broad needs of users but may not include every detail individual users may require.

Conclusion

The management assertion affirms the completeness and fairness of the system description and control design. It assures stakeholders that the company’s controls align with SOC 2 criteria for security and availability, helping users assess risks when interacting with the system.

3. System description

Explanation of the example:

This section of the SOC 2 Type 2 report outlines key details about the organization’s system, services, and commitments.

1. Background and overview of services: Introduces the organization and its offerings (details would be filled in).

2. Significant changes during the review period: No significant changes to services during the audit period, indicating stable controls.

3. Subservice organizations: The company relies on third-party cloud service providers for data center services, which are not included in the audit scope. However, the company’s responsibilities regarding these services are covered, and shared controls for security, confidentiality, and availability are defined in SLAs.

4. Principal service commitments and system requirements: The company outlines commitments to users regarding security, availability, and confidentiality, including protecting customer data, ensuring system availability, and having disaster recovery plans. These commitments are supported by internal policies, such as employee background checks, security training, and access controls, and are communicated through contracts and public-facing materials.

5. Components of the system: The system includes key components: infrastructure, software, people, procedures, and data that directly support services to clients. Anything not directly supporting the service is excluded.

6. Boundaries of the system: The scope of the audit includes the relevant products (e.g., “ABC” and “XYZ”) and services. The audit does not cover physical office locations or on-premise servers, as all data is processed in the cloud.

7. Control environment: The organization emphasizes the importance of internal controls across all levels, led by senior management. Policies and procedures are designed to ensure effective information security, which is consistently communicated, implemented, and reviewed within the organization. Employees are expected to adhere to ethical standards and report any violations without fear of retaliation.

8. Risk management and risk assessment: The company conducts annual risk assessments to identify and mitigate risks that could affect its ability to provide reliable services. These assessments evaluate risks based on assets, threats, and vulnerabilities, and are used to guide risk treatment plans and actions. Risks are regularly monitored and managed.

9. Monitoring: Management and information security personnel continuously monitor internal controls and performance. They regularly review system performance and vulnerabilities and take corrective actions as needed to ensure controls operate as intended.

10. Information and communication: The company has documented procedures for all major functions, reviewed regularly by management. Communication is done via email, with security measures like two-factor authentication in place. Information regarding system operations and security is regularly communicated to employees and customers.

11. Components of the system: The company employs network and endpoint protection, including firewalls, antivirus, and content filtering. Continuous monitoring and vulnerability scans are conducted to ensure security. Capacity and patch management processes are in place to maintain system performance and minimize risks.

12. People: The organizational structure is designed to ensure clarity in roles and responsibilities. Regular management meetings address business and security issues, and information security is a shared responsibility across teams, with clear policies for backup, recovery, and data security.

13. Backup and recovery of data: Formal policies govern backup and data recovery, ensuring business continuity and compliance with legal and regulatory requirements. Backup logs are maintained according to established retention periods.

14. Applicable trust services criteria and related controls: The company complies with security, confidentiality, and availability criteria. However, physical access to data centers is managed by the cloud service provider, and the organization does not have office facilities.15. Complimentary user-entity control considerations: User entities must comply with their contractual obligations, maintain their systems, and manage access to the company’s services. They are also responsible for developing their own disaster recovery plans and notifying the company of security breaches.

4. Description of Trust Criteria Service controls and test results

The Description of Trust Criteria Service Controls and Test Results section provides a detailed overview of the key controls implemented by X Company to meet SOC 2’s Trust Service Criteria.

Specific controls are described for each Trust Service Criteria, followed by the test procedures applied by the auditor, and finally, the results of the independent auditor’s audit tests.

1. The “Control Environment” section assesses the organization’s framework for effective internal controls, including examples such as its commitment to integrity and ethical values (COSO Principle 1), the independence of the board and its oversight of internal controls (COSO Principle 2), the clarity of management structures, reporting lines, and responsibilities (COSO Principle 3), efforts to attract and retain competent individuals aligned with objectives (COSO Principle 4), and communication with external parties regarding internal control matters (COSO Principle 15). These elements form the foundation of a strong control environment.

2. The “Risk Assessment” section evaluates how the organization identifies, assesses, and manages risks to achieve its objectives. It includes activities such as defining risk assessment scales (COSO Principle 6), ensuring the risk management procedures are implemented and communicated (COSO Principle 7), assessing fraud risks (COSO Principle 8), and controlling changes that could impact internal controls (COSO Principle 9).

Examples also include conducting regular risk assessments, prioritizing risks based on impact and likelihood, maintaining an up-to-date asset inventory, and ensuring change management processes are in place to mitigate the impact of security threats.

3. The “Monitoring Activities” section assesses how the organization monitors the effectiveness of its internal controls. It includes ongoing evaluations, such as reviewing information systems annually for compliance, conducting quarterly IT system access reviews, performing annual vulnerability assessments and penetration tests, and ensuring an independent internal business assurance function (COSO Principle 16).

Additionally, it evaluates how deficiencies are communicated and addressed, with examples including internal audit tracking, reporting security incidents via a ticketing system, and reviewing the effectiveness of the Information Security Management System (ISMS) (COSO Principle 17).

4. The “Control Activities” section assesses how the organization selects and develops control activities to manage risks and achieve objectives. This includes mitigating risks by segregating duties, conducting annual reviews for compliance with security policies, and performing regular risk assessments. The section also evaluates how general control activities over technology, such as defined access control policies, support these objectives.

Additionally, it focuses on ensuring that policies and procedures are regularly reviewed for effectiveness, clearly define roles and responsibilities, and are implemented through internal business assurance functions to maintain governance and control.

5. The “Logical Access Controls” section evaluates the implementation of controls over the access to and security of protected information and assets to prevent unauthorized access or malicious activities. It covers key areas, including the following:

Access control policies and procedures: Documented procedures are in place, such as access being granted on a least-privilege basis and specific controls for system access (e.g., multi-factor authentication for cloud consoles).
Role-based access and privileged access: Security roles are defined for system access based on job roles, with privileged access allocated only as needed. The organization ensures that access is reviewed regularly to maintain appropriate levels.
Infrastructure security: It is verified that access to cloud infrastructure, production systems, and databases is tightly controlled, with hardened security groups and access control configurations.
Authentication and encryption: Users must authenticate with unique accounts and meet password standards or use SSH keys. Data is encrypted at rest, and communication sessions are protected through encryption during transmission.
Access review and management: The organization ensures that user access is periodically reviewed, with clear procedures for granting, modifying, and revoking access as per job responsibilities or organizational needs.
External threat protection: Antivirus software is enabled, and network traffic is monitored for vulnerabilities and malware. Additionally, production systems are hardened according to security benchmarks to protect against external threats. These controls are all inspected, and no exceptions were noted during the testing process.

6. The “System Operations” section outlines the entity’s procedures for detecting and monitoring configuration changes and vulnerabilities, ensuring compliance with defined configuration and hardening standards, and conducting regular vulnerability assessments and penetration tests.

It emphasizes the importance of incident response, with documented procedures guiding personnel in handling security incidents, including reporting, logging, and evaluating incidents. The entity also monitors and addresses security events, ensuring that corrective and preventive actions are taken.

Additionally, it implements a defined incident response program, reviews all incidents in management meetings, and maintains policies for managing employee misconduct. Root cause analysis is performed for major incidents, and necessary actions are taken to resolve identified vulnerabilities and threats.

7. The “Change Management” section details the entity’s approach to managing changes in infrastructure, software, and procedures. It ensures that application development and testing occur in separate environments from production and that a version control system is used to manage source code, documentation, and release labeling, with controlled access.

The section also mandates that code changes, reviews, and tests are performed by different personnel and that only authorized individuals can make changes to production code. All change requests must include risk assessments, implementation, and rollback plans, and changes are communicated to clients and users when they could impact them.

Additionally, the entity’s change management policies and procedures ensure proper segregation of duties throughout the change process, from request to implementation.

8. The “Risk Mitigation” section outlines the entity’s efforts to identify and manage risks from potential business disruptions. It highlights that the entity has a documented Business Continuity Procedure and Plan, including disaster recovery guidelines, which are tested annually to ensure preparedness.

Additionally, the entity reviews annual SOC reports for its subprocessors to verify the effectiveness of outsourced controls. A vendor management process is in place that requires signed contracts, specifying scope, roles, compliance, and service levels, as well as confidentiality agreements.

Contracts with third-party service providers also include terms of confidentiality and responsibilities for both parties, with signed non-disclosure agreements (NDAs) in place for all customer and vendor contracts.

9. The “Additional Criteria for Availability” section describes how the entity ensures system availability and capacity management to meet its objectives. It monitors system performance through a variety of tools, tracking system uptime, CPU usage, memory storage, and other critical metrics.

Load balancing and auto-scaling mechanisms are enforced in the cloud IT environment to distribute network traffic and automatically adjust resources to maintain operational continuity. The entity also continuously monitors processing capacity.

To safeguard data, daily incremental and full backups of production databases are conducted, and the platform is implemented in a high-availability configuration using multiple redundant availability zones. Regular testing of Business Continuity and Disaster Recovery (BCDR) plans is carried out, with any issues identified during these tests being addressed. The entity also ensures that backup restoration procedures are tested at least annually.

10. The “Additional Criteria for Confidentiality” section addresses how the entity handles sensitive, confidential, and personal information to ensure confidentiality. The entity has established a Data Retention and Disposal Policy that defines procedures for the appropriate retention, disclosure, and disposal of such information.

This policy ensures that data is managed in a way that aligns with confidentiality objectives. Furthermore, upon termination of services, the entity securely deletes customer data, adhering to the established guidelines to ensure confidentiality is maintained throughout the data lifecycle.

In short, this section highlights the company’s specific controls related to each Trust Service Criteria and provides the outcome of the auditor’s testing, demonstrating the company’s commitment to maintaining effective security, availability, and confidentiality.

5. Other information: Management’s response (optional)

This section of the SOC 2 Type 2 report provides additional information from the company ([Brand Name]) about its disaster recovery and business continuity practices. This section is optional.

Explanation of the key points:

Informational Purpose Only: The details provided here are for general information and have not been audited by the independent auditor. The auditor has not assessed this information or its accuracy.
Disaster Recovery and Business Continuity: The company outlines how it ensures continuity of operations in case of disruptions, such as service outages or system failures. This is part of the broader concept of business continuity planning.
Logical Controls for Service Continuity: [Brand Name] has implemented technical controls to prevent service interruptions. These include systems to automatically recover from failures, such as spinning up servers across multiple availability zones.
Disaster Recovery Plan: The plan outlines specific roles, critical applications, systems, and data necessary to maintain operations in case of a disaster. It also includes a business impact analysis to ensure high availability and system reliability during interruptions.

In summary, this section describes the company’s proactive measures to ensure it can recover from disruptions and maintain service availability, though the auditor has not verified these details.

The Other Information: Management’s Response section provides important context for the SOC 2 Type 2 report, especially regarding any issues or recommendations raised during the audit. It typically includes the company’s acknowledgment of the audit findings, management’s response to exceptions and minor recommendations, additional supporting documentation, and a statement of commitment to continuous improvement in line with SOC 2 standards. This section ensures that the audit report is comprehensive, demonstrating that management takes responsibility for its controls and is committed to making improvements based on audit feedback.

How can Scrut help?

Scrut simplifies the SOC 2 compliance journey with an automated platform for managing security controls, policies, and compliance processes. Its continuous monitoring feature ensures organizations stay ahead of requirements through real-time alerts and automated tracking.

With over 70 integrations, Scrut automates evidence collection, reducing manual effort by more than 65% and ensuring audit readiness. Its collaboration tools streamline communication with internal teams and auditors, while real-time compliance visibility simplifies verification, helping businesses achieve SOC 2 Type 2 certification faster and with less effort.

If you’d like to explore more about how Scrut can assist you in your SOC 2 journey, feel free to get in touch or schedule a demo!

FAQs

Is the SOC 2 Type 2 report different from the SOC 2 Type 1 report?

Yes, a SOC 2 Type 1 report focuses on the design of controls at a specific point in time, whereas a SOC 2 Type 2 report focuses on the operating effectiveness of the controls throughout the audit period.

What are the requirements for the SOC 2 Type 2 report?

To meet SOC 2 Type 2 report requirements, your organization must address the Security criterion, which is mandatory. Additionally, your organization may choose to include other Trust Service Criteria—availability, processing integrity, confidentiality, and privacy—based on the services provided and the commitments made to users.

Is SOC 2 system description a critical part of a SOC 2 Type 2 report?

Yes, the system description is essential. It outlines the scope, control framework, and systems in place to meet SOC 2 requirements, providing context for the audit process.

How does a SOC 2 Type 2 report help in understanding when a bridge letter is required?

A SOC 2 Type 2 report helps understand when a bridge letter is necessary by detailing the period of coverage for the audit and identifying any gaps in the coverage. This indicates the need for a bridge letter to provide assurance that controls have remained in place and have not materially changed since the last audit period.