Compliance
Security
What Is SOC 2? A Technical Guide for Cloud Engineering Teams
TL;DR: SOC 2 audits your security controls against the AICPA's Trust Service Criteria. Most guides target compliance managers - this one targets the engineers who configure the infrastructure those managers audit. Type II reports (12+ months of operational evidence) are the standard for enterprise sales. The controls map directly to AWS, GCP, and Azure configuration you can query with SQL.
Most SOC 2 guides are written for compliance managers and GRC teams. This one is written for the engineers who actually have to configure the infrastructure those compliance managers audit.
The gap matters. When your auditor asks "demonstrate that CloudTrail logging is enabled with log file validation in all regions," you can't delegate that to a compliance platform checkbox. Someone has to look at the actual AWS configuration and produce evidence. That someone is usually an engineer.
In this article:
What Is SOC 2? #
SOC 2 (System and Organization Controls 2) is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA) that evaluates whether a service organization's systems and processes meet defined security and availability criteria.
The audit produces a SOC 2 report - a document from a licensed CPA firm that either confirms or identifies gaps in your controls. When a customer's security team asks "do you have a SOC 2 report?", they want a Type II report from an accredited auditor stating that your security controls were in place and operating effectively over a sustained period.
SOC 2 is not a certification - you can't "become SOC 2 certified." It's an attestation. An independent auditor examines your controls against the Trust Service Criteria (TSC) and issues a report with an opinion on whether your controls are designed and operating effectively. A clean report with no exceptions is the goal.
What SOC 2 is not:
- A technical standard with prescriptive controls (unlike PCI DSS, which tells you exactly what to do)
- A legal requirement in most industries (unlike HIPAA for healthcare)
- A one-time assessment - Type II reports need renewal, typically annually
What SOC 2 actually evaluates:
The TSC are principle-based. "The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events." That's a criterion, not a checklist item. Your auditor assesses whether your implementation meets the intent.
What's the Difference Between SOC 2 Type I and Type II? #
The progression: most organizations get a Type I first (faster, cheaper, demonstrates intent), then pursue Type II once the observation period accumulates. Type II is what enterprise procurement teams and large customers require because it proves consistent operation, not just design.
For cloud teams, the practical difference is significant. Type I evidence is mostly configuration screenshots and policy documents. Type II requires time-series evidence - logs showing your CloudTrail was continuously enabled, access reviews conducted quarterly throughout the period, incident response records if anything occurred. This is where automation - and tools like CloudQuery - provide the most value.
What Are the 5 Trust Service Criteria? #
SOC 2 is built around five Trust Service Criteria, though only Security is mandatory. Which criteria you include determines what your auditor evaluates.
Security (mandatory) #
The Security criterion - the Common Criteria (CC) - is required for every SOC 2 report. It covers logical and physical access controls, system operations, change management, and risk mitigation. For cloud teams, this is the bulk of the work.
Security is organized into CC categories: CC1 (Control Environment), CC2 (Communication), CC3 (Risk Assessment), CC4 (Monitoring), CC5 (Control Activities), CC6 (Logical and Physical Access), CC7 (System Operations), CC8 (Change Management), CC9 (Risk Mitigation).
For cloud infrastructure, CC6 and CC7 drive the most audit evidence:
- CC6.1: Logical access controls - IAM policies, MFA enforcement, access key management
- CC6.2: New access provisioning - user onboarding workflows, access approval records
- CC6.3: Removal of access - offboarding procedures, access review findings
- CC6.6: System boundary security - network controls, public-facing resource monitoring
- CC7.1: Configuration monitoring and detection - CSPM-style checks, config change alerts
- CC7.2: Monitoring for anomalies - CloudWatch, GuardDuty, log analysis
Availability (optional) #
Covers whether your system is available for operation as committed in your SLA. For cloud teams: RTO/RPO commitments, backup configuration, multi-region failover, and disaster recovery testing. Most SaaS companies include Availability.
Processing Integrity (optional) #
Covers whether system processing is complete, valid, accurate, timely, and authorized. Most relevant for transactional systems (payment processors, data pipelines). Requires input/output validation controls and processing error detection.
Confidentiality (optional) #
Covers whether confidential information is protected as committed. Encryption of data at rest and in transit, access controls for sensitive datasets, and confidentiality policies. Most companies include this if they handle any sensitive customer data.
Privacy (optional) #
Covers the collection, use, retention, disclosure, and disposal of personal information in line with commitments. More specific than Confidentiality - Privacy is about PII specifically, aligned with the AICPA Privacy Management Framework (updated 2020, formerly the Generally Accepted Privacy Principles). Companies handling regulated personal data often include this criterion.
How Do You Define Your SOC 2 Scope? #
Scope determines what your auditor examines - and getting it wrong in either direction is expensive. Too narrow and enterprise buyers will challenge your report during procurement. Too broad and you're generating evidence for systems that don't need to be audited, multiplying prep time and audit fees.
System boundary: Your SOC 2 scope covers the systems that store, process, or transmit customer data. For most SaaS companies, this means your production environment: the AWS accounts or GCP projects where customer data lives, the services that process it, and the access management systems that control who can reach it. Dev/test environments, internal tooling, and staging systems are typically out of scope unless they can access production data.
What to exclude deliberately: Every system in scope requires evidence collection throughout the audit period. CI/CD pipelines, employee laptops, internal analytics tools - if these don't touch customer data, keep them out of scope. Your auditor will push back if the scope seems artificially narrow, but "we excluded this system because it cannot access customer data, and here's the network diagram showing that" is a defensible answer.
Which criteria to include: Security is mandatory. Availability is worth including for most SaaS products - your customers care about uptime and it's relatively low overhead to demonstrate. Confidentiality is worth including if you handle any sensitive customer data. Processing Integrity and Privacy add meaningful scope and audit cost - include them only if your customers specifically require them or if your product makes them directly relevant (payment processing for PI, PII-heavy products for Privacy).
Start with Security + Availability + Confidentiality for your first Type II. Add criteria in subsequent cycles once the base program is running smoothly.
How SOC 2 Maps to Cloud Infrastructure Controls #
The TSC don't prescribe specific technologies, but here's how the Security criterion maps to common cloud infrastructure controls.
The shared responsibility reality: AWS, GCP, and Azure each publish their own SOC 2 Type II reports, covering the infrastructure layer they're responsible for (physical data centers, hypervisor, networking). Your audit covers the configuration and workload layer - everything above the platform. If you leave an S3 bucket publicly accessible, that's a finding in your audit, not Amazon's.
Querying Your SOC 2 Posture with CloudQuery #
The most efficient way to stay audit-ready is to query your cloud configuration continuously rather than scrambling to gather evidence when an audit starts. We've watched teams spend three weeks pulling manual exports and scheduling emergency access reviews right before an audit window - work that continuous queries would have made unnecessary.
The CloudQuery Platform syncs configuration data from AWS, GCP, Azure, and 70+ other sources into a SQL database you control, making your SOC 2 posture queryable at any time.
CC6.1 - IAM users with console access but no MFA:
SELECT
u.account_id,
u.user_name,
u.arn,
u.create_date,
u.password_last_used
FROM aws_iam_users AS u
LEFT JOIN aws_iam_mfa_devices AS m
ON u.user_name = m.user_name
WHERE u.password_enabled = true
AND m.user_name IS NULL
ORDER BY u.account_id, u.password_last_used;
CC7.1 - CloudTrail not enabled for multi-region logging in all accounts:
SELECT account_id
FROM aws_accounts
WHERE account_id NOT IN (
SELECT DISTINCT account_id
FROM aws_cloudtrail_trails
WHERE is_multi_region_trail IS TRUE
AND is_logging IS TRUE
);
CC6.6 - S3 buckets with public access not blocked:
SELECT
account_id,
name,
region
FROM aws_s3_buckets
WHERE
block_public_acls = false
OR block_public_policy = false
OR ignore_public_acls = false
OR restrict_public_buckets = false
ORDER BY account_id;
These become CloudQuery Policies - running on every sync, alerting when a violation appears. The output isn't just a dashboard; it's the time-series evidence that a Type II auditor needs. A policy that's been running for 9 months with no violations is exactly the "controls operating effectively over a period of time" that SOC 2 Type II requires.
What SOC 2 Evidence Collection Actually Looks Like #
A Type II audit covering 12 months will require evidence demonstrating your controls were active throughout that period. Here's what auditors typically request and what produces it.
Logical access evidence
- User access list at audit start and end - export from your IAM system showing who had access to what
- Quarterly access review records - documented reviews showing someone checked that access is appropriate
- Provisioning and de-provisioning logs - records showing new accounts were created with approval and departing employees were deprovisioned promptly
Audit logging evidence
- CloudTrail configuration screenshots (or continuous policy evidence) showing multi-region logging was enabled throughout the period
- Evidence that log file validation is enabled (tamper protection)
- Log retention policy confirming logs are kept for at least the audit period plus buffer
Vulnerability management evidence
- Regular vulnerability scan outputs (typically monthly or quarterly) showing identified vulnerabilities and remediation status
- Patch management records demonstrating critical patches were applied within your stated SLA
Incident response evidence
- Incident register covering the audit period (even "no incidents" should be documented)
- Any incident postmortems from the period
Change management evidence
- Change records showing infrastructure changes went through an approval process
- Deployment logs or CI/CD pipeline records showing changes were reviewed before production
The engineering shortcut: automate as much evidence collection as possible before the audit period starts. Running CloudQuery with scheduled policies that log violations gives you audit-ready evidence from day one of the observation period - not scrambled exports after the fact.
When the audit finds something
Most Type II audits produce at least one exception - a control that wasn't operating as described or a gap in evidence. This is normal. An exception doesn't fail the audit; your auditor documents it and you write a management response explaining the gap and your remediation plan. Security-conscious buyers read the exceptions section carefully, but a well-documented exception with a clear remediation plan reads better than a suspiciously blank one.
The exceptions that actually concern enterprise buyers are systemic ones: CloudTrail disabled for extended periods, access reviews that were visibly backdated, or critical findings with no remediation response. Isolated point failures with documented root causes and fixes are routine and expected.
How Does SOC 2 Compare to ISO 27001 and HIPAA? #
For most US SaaS companies, SOC 2 comes first because US enterprise customers require it. ISO 27001 is often added when targeting European or enterprise contracts that reference ISO standards. HIPAA is required if you process protected health information - it's not optional for companies in scope.
Query Your SOC 2 Posture with SQL
Sync cloud configuration from AWS, GCP, and Azure into a queryable database. Write SQL policies against CC6, CC7, and CC8 controls and get continuous evidence that your SOC 2 controls are operating. Or check out the documentation.
FAQ #
What does SOC 2 stand for? #
SOC 2 stands for System and Organization Controls 2. It's an auditing standard developed by the American Institute of Certified Public Accountants (AICPA) for service organizations. The "2" distinguishes it from SOC 1 (which focuses on financial reporting controls) and SOC 3 (a public-facing summary version of a SOC 2 report).
Who needs a SOC 2 report? #
Any company that stores, processes, or transmits customer data on behalf of other businesses. In practice, this is most SaaS companies, cloud service providers, and managed service providers. Enterprise customers typically require a SOC 2 Type II report as part of their vendor security review process before signing contracts.
How long does SOC 2 certification take? #
SOC 2 is an attestation, not a certification - but the common question is about the timeline to a report. Type I: typically 6–12 weeks once your controls are in place. Type II: you need to run with controls active for a minimum of 6 months (the observation period), then add time for the audit itself. End-to-end from starting your compliance program to a clean Type II report is typically 9–18 months for organizations starting from scratch.
What's the difference between SOC 2 Type I and Type II? #
Type I attests that your controls are designed appropriately at a single point in time. Type II attests that your controls operated effectively over a period of time (minimum 6 months). Type II is significantly more valuable - it proves your controls are consistently working, not just that you designed them correctly. Most enterprise customers and security-conscious buyers require Type II.
Does SOC 2 require specific cloud configurations? #
No - SOC 2 is principle-based, not prescriptive. The Trust Service Criteria don't say "use AWS CloudTrail" - they say "implement logging and monitoring controls." Your auditor assesses whether your specific implementation meets the intent of those criteria. The practical result is that most cloud-native SOC 2 programs use CloudTrail/Cloud Audit Logs/Azure Monitor for logging, MFA everywhere, encryption at rest and in transit, and vulnerability scanning - because these are what auditors accept as evidence for the relevant criteria.
Should early-stage startups prioritize SOC 2? #
Not automatically. SOC 2 Type II is a meaningful investment - typically 200–500 hours of internal engineering time plus $20K–70K in audit fees, with ongoing maintenance after that. For teams under 20 people or pre-Series B, that competes directly with product development.
The practical trigger is enterprise customer requirements. Pursue SOC 2 when buyers start requiring it as a procurement condition. Until then, a documented security program and honest answers to security questionnaires close most deals at early stages.
That said, starting your compliance program early - even without a formal audit - pays off. Your Type II observation period starts when your controls are in place, not when you engage an auditor. Building controls into your infrastructure from the beginning is much cheaper than retrofitting them onto a production system later.
Can I use CloudQuery for SOC 2 compliance? #
The CloudQuery Platform isn't a compliance platform - it doesn't generate SOC 2 reports or replace an auditor. What it provides is continuous SQL-based visibility into your cloud configuration across AWS, GCP, Azure, and other sources. This means you can write queries that check whether your CloudTrail is active in all regions, whether any IAM users lack MFA, or whether any storage is publicly accessible - and schedule those queries as policies that run on every sync. The resulting data serves as continuous evidence that your infrastructure controls are operating, which is exactly what a Type II audit requires.
How much does a SOC 2 audit cost? #
Audit fees vary significantly by auditor and scope. According to Secureframe SOC 2 audit cost analysis, Type I audits typically run $15K–$25K and Type II audits $20K–$70K+ for specialist firms. Big Four and large national firms charge substantially more. These are auditor fees only - internal engineering and compliance time to prepare evidence and address findings adds significantly to the total program cost. Organizations working through the audit for the first time typically spend 200–500 hours of internal time on top of auditor fees.
