SOC Reports: Definition, Types and Compliance Guide

What are SOC reports?

A SOC report is an independent audit that shows how well a company protects its systems and data. Think of it as a security report card that a neutral third party creates after examining a service provider's internal controls.

These reports matter because they build trust. When you're considering a cloud provider or SaaS vendor, you need proof they can protect your data, with over 77% holding compliance attestations like SOC 2. A SOC report gives you that proof through a formal evaluation by a certified public accountant.

The American Institute of CPAs (AICPA) created SOC reports to standardize security proof. An auditor examines your systems and verifies your controls work as designed. For you as a customer, this report helps you assess risks before sharing sensitive data.

Every SOC report focuses on control objectives and control activities. Control objectives are the security goals a company wants to achieve. Control activities are the specific steps they take to reach those goals. The auditor's job is to verify that these activities actually meet the objectives.

IR Plan Template

While SOC reports verify your controls work, you still need a plan for when incidents occur. Get the template to build response playbooks that complement your compliance program.

Types of SOC reports and when to use them

You'll encounter three main types of SOC reports, and each serves a different purpose. Understanding which one you need depends on what you're trying to verify about a vendor's security.

SOC 1 reports

SOC 1 reports focus on controls that affect your financial reporting. If a vendor processes payroll, handles transactions, or manages data that flows into your financial statements, you'll need their SOC 1 report. Your financial auditors will ask for this because they need to understand how the vendor's controls impact your company's financial audit.

SOC 2 reports

SOC 2 reports examine controls related to security, availability, processing integrity, confidentiality, and privacy. This is the report you'll see most often with cloud providers and SaaS companies. It digs deep into how a vendor protects customer data and keeps systems running reliably.

SOC 3 reports

SOC 3 reports cover the same ground as SOC 2 but with less detail. They're designed for public distribution, so vendors often post them on their websites. You'll get the auditor's opinion on whether the vendor met security standards, but you won't see the detailed control descriptions that appear in a SOC 2 report.

Type 1 vs Type 2 reports

SOC 1 and SOC 2 reports come in two types. A Type 1 report evaluates whether controls are designed correctly at a specific point in time. A Type 2 report goes further by testing whether those controls operated effectively over a period, typically six to twelve months. Type 2 reports give you more confidence because they prove controls didn't just exist on paper—they functioned properly throughout the audit period.

Which type should you request?

Request Type 2 reports for operational assurance. Type 2 reports prove controls operated effectively over 6-12 months, giving you confidence in the vendor's ongoing security practices. Type 1 reports only verify that controls were designed correctly at a single point in time—they don't prove the controls actually worked.

When reviewing Type 2 reports, pay attention to exceptions. These are instances where controls didn't operate as designed during the audit period. Minor exceptions with documented remediation are normal. Multiple exceptions or unresolved issues indicate systemic control problems.

Beyond these standard reports, you might encounter specialized versions. A SOC for Supply Chain report addresses security risks in production and distribution systems.

How SOC reports compare to other frameworks

Organizations often evaluate multiple compliance frameworks simultaneously. Here's how SOC 2 compares to ISO 27001 and FedRAMP:

Framework	Type	Control Source	Issued By	Best For
SOC 2	Attestation report	AICPA Trust Services Criteria	Licensed CPA firm	SaaS vendors, cloud providers serving commercial customers
ISO 27001	Certification	ISO/IEC 27001 Annex A controls	Accredited certification body	Global operations, international customers requiring ISO standards
FedRAMP	Authorization	NIST SP 800-53 controls	FedRAMP PMO (U.S. government)	Cloud services for U.S. federal agencies

SOC 2 focuses on operational controls for service organizations. ISO 27001 certifies an information security management system (ISMS) across an entire organization. FedRAMP authorizes cloud services specifically for federal government use with extensive security requirements.

Trust service criteria in cloud environments

The Trust Services Criteria (security, availability, processing integrity, confidentiality, and privacy) form the foundation of SOC 2 reporting. Security is required in every SOC 2 audit, while organizations select additional criteria based on their service scope and customer needs.

Security

Security is the baseline criterion that every SOC 2 audit must include. It covers how you protect system resources from unauthorized access and modification. In cloud environments, this means implementing strong identity and access management, securing network configurations, and defending against malware.

Availability

Availability ensures your systems stay accessible according to your service agreements. For cloud applications, this involves maintaining high uptime through features like auto-scaling, load balancing across multiple zones, and solid disaster recovery plans.

Processing integrity

Processing integrity verifies that your system handles data completely, accurately, and on time. In the cloud, you need to ensure data moves correctly through services like serverless functions and databases. This requires data validation checks, error handling, and monitoring of processing jobs.

Confidentiality

Confidentiality protects information marked as confidential from unauthorized access. Key controls include encrypting data at rest in storage services and encrypting data in transit using TLS for all communications.

Privacy

Privacy focuses specifically on personal information—how you collect it, use it, store it, and delete it. This criterion requires clear privacy notices, honoring user consent, and securely deleting data when requested.

Wiz Akademie

The SOC Team Roster: Roles & responsibilities

A security operations center (SOC) team is a group of highly skilled professionals responsible for scanning IT environments and identifying and remediating cybersecurity threats and incidents

How to evaluate vendor SOC reports

When you receive a SOC report from a vendor, you need to know what to look for. Use this checklist to systematically evaluate the report:

SOC report review checklist:

Report date range: Verify the audit period is recent (within 12 months) and covers adequate duration for Type 2 reports
Auditor opinion: Look for an unqualified opinion; qualified opinions indicate control failures
System boundaries: Confirm the report covers all services you use from the vendor
Trust Services Criteria: Check which criteria are in scope (security is required; others are optional)
Test procedures and exceptions: Review what the auditor tested and note any exceptions or control failures
Complementary user entity controls (CUECs): Identify controls you must implement on your end
Subservice organizations: Note any third-party dependencies and whether they use inclusive or carve-out methods
Management assertions: Compare vendor claims against auditor findings

Start with the auditor's opinion. An unqualified opinion means the auditor found everything in order—the vendor's system description is accurate and their controls work as designed. A qualified opinion signals problems with one or more controls, which should raise immediate concerns.

Next, check the management assertion. This is where the vendor's leadership confirms their system description is accurate and their controls operated effectively. Compare this assertion against the auditor's findings to spot any discrepancies.

Pay attention to complementary user entity controls. These are security measures the vendor expects you to implement on your end. If you don't put these controls in place, you create security gaps even when the vendor's controls are solid.

Modern cloud security platforms map findings to specific owners—teams, services, or code repositories—and provide code-to-cloud traceability. This ownership mapping speeds remediation by routing issues directly to the engineers who can fix them, while traceability links runtime findings back to infrastructure-as-code templates for permanent fixes.

Look at the report's timing too. If months have passed since the audit period ended, the information might be outdated. In these cases, request a bridge letter (also called a gap letter) from the vendor. This document confirms that nothing material has changed in their control environment since the audit wrapped up.

Finally, identify any subservice organizations mentioned in the report. These are third parties the vendor relies on, and their controls affect your overall security posture. Vendors handle subservice organizations using two methods:

Inclusive method: The auditor tests the subservice organization's controls as part of the vendor's audit. You can rely on the vendor's SOC report for those controls.
Carve-out method: The auditor excludes the subservice organization's controls from testing. You must obtain and review the subservice organization's own SOC report to assess those controls.

When you see carve-out subservice organizations, request their SOC reports directly to complete your risk assessment.

Wiz Akademie

6 Essential SOC Best Practices

Explore the top best practices for an effective security operations center (SOC).

Obtaining SOC reports from vendors

SOC 2 Type I and Type II reports are restricted-use documents. Vendors typically require you to sign a non-disclosure agreement (NDA) before sharing them because the reports contain detailed information about internal controls and system architecture.

SOC 3 reports are general-use summaries designed for public distribution. Vendors often post SOC 3 reports on their websites without requiring an NDA. However, SOC 3 reports contain less detail than SOC 2 reports—you'll see the auditor's opinion but not the detailed control descriptions and test results.

When evaluating critical vendors, request the full SOC 2 report rather than relying solely on a SOC 3 summary.

Watch 5-min demo

atch 5-min demo showing how cloud-native detection catches the risks that emerge between SOC audits.

Watch now

SOC compliance challenges in cloud-native environments

Cloud environments create unique compliance challenges that traditional security approaches can't handle. The dynamic nature of cloud infrastructure means resources appear and disappear constantly, making it hard to maintain consistent controls.

The shared responsibility model adds another layer of complexity. Your cloud provider secures the infrastructure, but you're responsible for everything you build on top of it. This includes network configurations, identity permissions, data encryption, and workload security.

Multi-cloud strategies make compliance even harder. When you use AWS, Azure, and GCP together, you need to implement controls consistently across all three platforms. Each cloud has different services and configuration options, so applying a unified compliance framework becomes a major undertaking.

The biggest gap exists between continuous deployment and annual audits. You might be compliant on audit day, but a misconfiguration introduced through an infrastructure-as-code template the next day could create a critical vulnerability. This vulnerability might go undetected until the next audit cycle rolls around.

Risk-based prioritization helps teams focus on what matters. By correlating misconfigurations, vulnerabilities, identities, and data exposure into attack paths, security platforms identify toxic combinations—for example, an internet-exposed server with a critical vulnerability that has admin access to customer databases. These attack paths directly threaten SOC 2 security objectives, while isolated low-severity findings may not.

Traditional audit methods rely on manual evidence collection and periodic reviews. These methods can't keep up with environments that change by the minute. Containers and serverless functions spin up and down automatically, making it nearly impossible to capture the state of your system using static assessment techniques.

SOC reports vs continuous security monitoring

SOC reports and continuous monitoring serve different but complementary purposes. A SOC report provides a formal, independent validation at a specific point in time. Continuous monitoring gives you real-time visibility into your security posture every day.

Think of a SOC report as your annual physical exam. It's thorough and important, but it only tells you about your health on that particular day. Continuous monitoring is like wearing a fitness tracker—it shows you what's happening right now and alerts you to problems as they develop.

SOC reports remain essential for building trust with customers and meeting contractual requirements. They provide the formal attestation that auditors and compliance officers need. However, their backward-looking nature means they can't account for risks that emerge after the audit period ends.

Continuous monitoring fills this gap by scanning for misconfigurations, vulnerabilities, and identity risks in real time. Agentless, API-based discovery across AWS, Azure, and GCP reduces blind spots by building a complete inventory of workloads, identities, and data without installing software on every resource. When security teams can detect and fix issues as they arise, they don't have to wait for an annual audit to uncover problems.

This approach also makes audit preparation much easier. Instead of scrambling to gather evidence when auditors arrive, you can pull reports and demonstrate compliance on demand, with some organizations reporting over 40% less manual prep. Organizations with strong continuous monitoring programs maintain audit readiness year-round.

The industry is moving toward continuous assurance, where trust comes from ongoing commitment to security rather than periodic reports. In this model, SOC reports provide formal validation while continuous monitoring delivers daily proof that your controls remain effective.

How Wiz supports SOC compliance and continuous cloud security

Wiz maintains its own SOC 2 Type II attestation while helping other organizations streamline their compliance journey. The platform automates evidence collection and provides continuous monitoring that makes audit readiness a natural part of your security program.

An agentless, API-based approach builds a complete picture of your cloud posture without installing software on every workload. A security graph models resources, relationships, and risks to show how you prioritize remediation based on actual impact rather than isolated severity scores. This context helps auditors understand your risk-based approach to security.

Wiz's capabilities directly address the Trust Service Criteria that auditors evaluate:

Cloud Security Posture Management (CSPM) continuously monitors for misconfigurations and compliance gaps
Cloud Infrastructure Entitlement Management (CIEM) identifies identity risks and excessive permissions
Data Security Posture Management (DSPM) maps where sensitive data lives and how it's accessed

Infrastructure as code (IaC) scanning provides clear audit trails for change management. When you scan IaC templates before deployment, you create evidence that security checks happen throughout your development process. Real-time threat detection demonstrates that you actively monitor for security incidents rather than just checking boxes.

The platform helps you maintain compliance across multiple cloud providers with consistent policy enforcement. Instead of managing separate tools for AWS, Azure, and GCP, you get unified visibility and control. This makes it easier to show auditors that your security standards apply everywhere.

Ready to turn SOC 2 prep into continuous assurance? See how agentless, code-to-cloud visibility and a security graph make audit readiness part of everyday operations—get a demo.

Detect active cloud threats

Learn how Wiz Defend detects active threats using runtime signals and cloud context—so you can respond faster and with precision.