What are SOC reports?
System and Organization Controls (SOC) reports are standardized third-party assessments that validate an organization’s security posture. Governed by frameworks from the American Institute of Certified Public Accountants (AICPA), these audits evaluate specific technical operations. They measure how effectively a service organization designs and maintains controls regarding security, confidentiality, availability, privacy, and data processing integrity.
Establishing trust
In modern cloud architectures, SOC reports establish baseline trust between consumers and providers. They deliver a measurable demonstration of compliance, operational transparency, and a structural commitment to security hygiene.
When an organization provides an independent SOC report, customers can meet their own complex regulatory obligations. They can then quantify inherited cloud risks and make strictly informed platform decisions without performing direct infrastructure audits.
Validating vendors
SOC reports provide strategic value by establishing third-party validation for vendor due diligence. For Chief Information Security Officers (CISOs), these streamline third-party risk assessments across the software supply chain.
Enterprise procurement actively demands this validation. In fact, recent industry data indicates that 77% of enterprise clients now require certifications from their service providers before signing contracts. The SOC report acts as an operational currency, unblocking enterprise deals by translating internal security controls into market-recognized assurance.
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 their applications
The System and Organization Controls framework consists of three distinct report categories. Each serves a different audience and operational scope, making it critical to match the right report to your organization's specific services.
SOC 1
SOC 1 reports evaluate internal control over financial reporting (ICFR). They specifically target service organizations, like payroll processors or billing platforms, whose operations directly impact a customer's financial accuracy. Because these documents detail sensitive financial workflows, auditors restrict their distribution strictly to user entities and their internal management.
SOC 2
SOC 2 reports evaluate operational security rather than financial data. They measure an organization against the Trust Services Criteria, or TSC: security, availability, processing integrity, confidentiality, and privacy. This operational focus makes SOC 2 the definitive standard for cloud service providers, SaaS vendors, and modern infrastructure platforms.
SOC 3
SOC 3 reports serve as a public-facing summary of a SOC 2 assessment. They provide a high-level auditor opinion confirming compliance, without exposing proprietary architectural details, specific control configurations, or detailed testing results. Organizations typically publish SOC 3 reports on their trust portals or marketing sites.
Within the SOC 1 and SOC 2 frameworks, assessments break down further into two distinct verification levels: Type I and Type II. Crucially, a vendor can only obtain a SOC 3 summary after fully completing a rigorous SOC 2 Type II audit.
Type I
A Type I report gives a “snapshot” assessment. It validates that an organization's control designs are suitable for their intended purpose on one specific date. For example, an auditor verifies that firewall policies and access controls were correctly configured on Jan. 1. This static snapshot evaluates structural readiness, making Type I audits ideal for evaluating new infrastructure implementations or establishing an initial security baseline.
Type II
A Type II report provides a period-of-time assessment. It tests the actual operating effectiveness of those security controls over a sustained duration, usually spanning 6 to 12 months. Auditors sample system logs, identity access reviews, and real-time infrastructure data across the entire observation window. This uncovers configuration drift, delayed access revocations, or temporary control degradation that a single-day snapshot would miss.
For cloud security teams, Type II validation represents the definitive standard. Enterprise buyers actively mandate Type II reports over Type I because they require concrete proof of consistent security hygiene over time, rather than theoretical control capability on a single day.
Understanding Trust Services Criteria in cloud environments
The structural foundation of every SOC 2 assessment rests on the AIPCA- established Trust Services Criteria. These five categories translate abstract security principles into specific, auditable control families. Organizations tailor their audit scope by selecting the criteria most relevant to the cloud services they deliver, although the baseline requirements remain rigid.
Security (common criteria)
As the operational baseline, Security is the only mandatory criterion in a SOC 2 report. It verifies that cloud infrastructure and applications are protected against unauthorized access, logical or physical system damage, and data exfiltration. Auditors evaluate how effectively teams manage their overall control environment through mechanisms like least-privilege identity and access management (IAM), multifactor authentication, precise network security groups, and continuous vulnerability management.
Availability
Availability validates that cloud systems consistently meet uptime service-level agreements (SLAs). It requires concrete proof of architectural resilience, such as multi-zone redundancy, automated failover mechanisms, and validated disaster recovery planning.
Processing integrity
Processing integrity verifies the operational execution of the system itself, ensuring that cloud-based data processing remains complete, valid, and accurate without hidden omissions, unauthorized modification, or data corruption.
Confidentiality
Confidentiality controls safeguard sensitive corporate data, such as intellectual property (IP), source code, and trade secrets, against unauthorized disclosure. These controls use strict data classification and robust encryption protocols.
Privacy
Privacy directly governs the handling of personally identifiable information (PII) over the course of its entire lifecycle. Cloud teams must successfully demonstrate that customer data is collected, stored, and destroyed in complete alignment with documented usage consents and overarching regulatory frameworks.
Watch 5-min demo
atch 5-min demo showing how cloud-native detection catches the risks that emerge between SOC audits.
Watch now
SOC report structure and key components
A completed SOC report contains five standard sections: the auditor's opinion, management's assertion, the system description, a detailed accounting of control testing results, and optional contextual information. A few components, discussed below, might be especially important for your organization.
The auditor's opinion
Sitting at the very start of the document, the auditor's opinion serves as the critical verdict defining the report's market value:
An unqualified opinion represents a clean report. The organization designed and operated its controls effectively, with any isolated exceptions deemed immaterial to the broader security posture.
A qualified opinion indicates that some controls were either inappropriately designed or failed to operate effectively in specific areas.
An adverse opinion indicates systemic control failures where the organization must implement immediate remediation.
A disclaimer of opinion indicates the auditor lacked sufficient evidence to give a proper verdict.
System description
This section dictates the exact boundaries of the audit. For cloud platforms, this boundary relies heavily on sub-service organizations (e.g., underlying infrastructure providers like AWS, Azure, or Google Cloud). Auditors address these critical dependencies using one of two methods.
The carve-out method
Using a carve-out is the standard approach for modern cloud architecture. It explicitly excludes the sub-service organization's internal infrastructure from the primary audit. Instead, the audited organization maintains compliance by continuously monitoring the underlying cloud provider's own independent SOC report.
The inclusive method
This approach requires the auditor to directly test the sub-service organization's controls as part of the primary engagement. For major infrastructure providers, this would be a highly intrusive and resource-heavy process, so it’s very rarely used in their case.
Complementary User Entity Controls (CUECs)
Because cloud platforms operate on a shared responsibility model, an organization's SOC report only guarantees security if the customer also does their part; for example, encryption controls protect data only when combined with secure credential management. To address this, reports explicitly define Complementary User Entity Controls.
CUECs are the specific, mandatory controls that the customer must implement and maintain to preserve the chain of trust. If a customer fails to implement these required controls, the vendor's SOC report cannot validate the integrity of their deployment.
How to evaluate and implement SOC compliance for cloud services
Evaluating a vendor’s SOC report requires looking past the polished auditor’s opinion to analyze raw technical findings. Security teams must establish a structured review process to validate that a service organization’s compliance posture actively aligns with their internal risk appetite.
Scrutinize exceptions
An unqualified opinion does not guarantee a flawless environment. Reviewers must examine the "Results of Tests" section to analyze specific control failures, formally known as exceptions. Common exceptions include missed quarterly access reviews, delayed deprovisioning of terminated employees, or isolated configuration slip-ups.
Assess the materiality of these failures by evaluating whether they represent isolated human errors or systemic operational breakdowns. When exceptions do occur, carefully read management's response to determine if compensating or mitigating controls (redundant safeguards, operating elsewhere in the environment) successfully neutralized the underlying risk.
Request bridge letters
Because Type II audits cover a strict historical observation period, security teams often receive reports where the evaluation window ended several months prior. To cover the time period between the report's official end date and your current fiscal review, request a bridge letter (also known as a gap letter).
This formally signed document from the vendor's management affirms that the organization has not made material changes to its control environment or experienced significant security incidents since the official audit period concluded, closing the temporal gap.
Reference peer data
While a SOC report provides necessary validation of a vendor's technical controls, it does not assess operational friction. Before finalizing any external tool selection, cross-reference the vendor's compliance claims against independent peer reviews and market data. Validating capabilities against real-world practitioner experiences ensures that the vendor's operational reality matches their documented security architecture.
Evolving SOC compliance for modern cloud architectures
Traditional SOC audits often use periodic sampling, which creates a gap between static evidence and the fluid nature of cloud. Ephemeral resources and configuration drift are the two biggest challenges of SOC compliance in modern, cloud-native architectures. Tackling these necessitates a shift from static snapshots to continuous, automated mapping of controls.
Navigating ephemeral resources
Modern cloud applications rely heavily on compute resources that only exist when actively required. Serverless functions, containerized microservices, and auto-scaling instances spin up to handle workload demand and terminate automatically once the operation completes. A serverless function executing a user authentication request might operate for fewer than five minutes before vanishing entirely.
Ephemeral resources move faster than manual audit cycles, making real-time evidence capture essential for maintaining a continuous audit trail. Traditional compliance processes rely on auditors collecting evidence manually at the end of an observation period. Retrospective sampling becomes impossible when the underlying cloud resource terminates before the audit begins.
Proving that an ephemeral workload maintained the appropriate Trust Services Criteria requires capturing system state, runtime metadata, and identity parameters in real time while the resource is actively running. Continuous evidence collection gives security teams definitive proof of compliance for every workload, regardless of its lifespan.
Managing configuration drift
Cloud engineering teams use continuous integration and continuous deployment (CI/CD) pipelines to push code and infrastructure updates dozens or hundreds of times per day. When runtime environments diverge from their IaC definitions, teams use continuous scanning to identify and resolve configuration drift immediately.
Drift often occurs through routine operational activities or out-of-band modifications. When an engineer manually alters a production network policy through the cloud console to troubleshoot an active outage, they might successfully restore service, but fail to revert the permissive firewall rule afterward.
Automated guardrails flag changes the moment they occur, preventing a single CI/CD update from altering a resource's security posture. Continuous assurance replaces periodic collection, ensuring that the environment remains in a known-good state across every deployment.
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 assists SOC compliance from periodic audits to continuous assurance
Static audits fail in dynamic clouds. To bridge the gap between ephemeral workloads and rigorous compliance standards, security teams must shift from periodic sampling to continuous assurance. Wiz makes this shift practical by replacing manual evidence gathering with real-time, agentless monitoring across the entire cloud estate.
Real-time posture visibility: Wiz CSPM continuously scans your cloud infrastructure against over 1,400 misconfigurations that map directly to Trust Services Criteria. The moment an unauthorized change occurs, Wiz flags the drift, so your environment stays compliant between audits, not just during them. In Wiz's own 2025 SOC 2 Type 2 audit, the platform covered more than 26% of the controls required across Trust Services Criteria, with the strongest overlap in the mandatory Security principle.
Identity and access validation: Because rigorous access oversight anchors the Security TSC, Wiz CIEM identifies overprivileged identities, inactive users, and risky credential configurations. This gives your team direct, automated evidence for mandatory access control audits and quarterly access reviews without pulling spreadsheets from five different consoles.
Data-centric context: For engagements scoped beyond baseline security, Wiz DSPM discovers and classifies sensitive data across your environment, providing concrete evidence for Confidentiality and Privacy TSCs. Security teams can prove they consistently enforce data protection controls around intellectual property, PII, and shadow data stores that manual audits would miss.
Automated evidence collection and audit management: All of this feeds into automated compliance reporting across 100+ built-in frameworks. Wiz reduces audit prep from months to minutes by continuously tracking evidence in a single location, ready for auditor review. Shared boards come pre-loaded with the right widgets, queries, and reports for each audit cycle, creating reusable templates your GRC team refreshes with current data rather than rebuilding from scratch every year.
One platform for GRC and security engineering: The biggest operational shift: GRC analysts and security engineers work from the same platform. Instead of GRC chasing security teams for screenshots and configuration exports, both teams see the same posture data, the same compliance mappings, and the same drift alerts. Compliance becomes a shared operating model, not a handoff between teams working in different tools.
Want to see how continuous compliance works in practice? Get a demo to see how Wiz maps your cloud posture against SOC requirements in real time.
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.
