Skip to main content

SOC 2

SOC 2 (System and Organization Controls 2) is an auditing standard developed by the AICPA for service organizations. It evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy — the Trust Service Criteria (TSC). A SOC 2 Type II report is a standard expectation for any SaaS company or cloud service provider selling to enterprises.

Infracast ships 52 automated rules mapped to the five Trust Service Criteria, focusing on the Security criterion (CC) which is required in all SOC 2 engagements.

Trust Service Criteria Overview​

CriterionRequiredRulesDescription
Security (CC)✅ Always38Protection against unauthorized access
Availability (A)Optional6System availability per SLA commitments
Processing Integrity (PI)Optional3Complete, valid, accurate processing
Confidentiality (C)Optional3Protection of confidential information
Privacy (P)Optional2Personal information lifecycle management

Most organizations pursue SOC 2 for the Security criterion plus Availability and Confidentiality for SaaS contexts.

How Infracast Maps Findings to Trust Service Criteria​

Security Criterion (CC)​

The Security criterion is organized into 9 Common Criteria (CC) categories:

CategoryDescriptionAutomated Rules
CC1Control Environment2
CC2Communication and Information1
CC3Risk Assessment3
CC4Monitoring Activities4
CC5Control Activities5
CC6Logical and Physical Access Controls14
CC7System Operations5
CC8Change Management2
CC9Risk Mitigation2

CC6 — Logical Access (Most Rule-Dense)​

CC6 is where most technical infrastructure controls live, and where Infracast provides the most automated coverage:

Rule IDTSC ControlDescription
SOC2-CC6.1-MFA-ALL-USERSCC6.1MFA required for all user accounts
SOC2-CC6.1-ROOT-MFACC6.1Root account MFA enabled
SOC2-CC6.3-SSH-RESTRICTEDCC6.3SSH not open to 0.0.0.0/0
SOC2-CC6.3-SG-INGRESSCC6.3Security groups restrict inbound access
SOC2-CC6.6-S3-PUBLIC-BLOCKCC6.6S3 public access blocked
SOC2-CC6.7-EBS-ENCRYPTIONCC6.7EBS volumes encrypted at rest
SOC2-CC6.7-RDS-ENCRYPTIONCC6.7RDS instances encrypted
SOC2-CC6.7-TLS-ENFORCEDCC6.7Encryption in transit on load balancers

Control Inheritance​

A single infrastructure finding often maps to multiple TSC controls:

Finding: "S3 bucket has public access enabled"
  ├── CC6.1 — Logical access controls (public = no access control)
  ├── CC6.6 — Logical access security measures
  └── C1.1  — Confidentiality of information

Evidence Collection for Auditors​

SOC 2 auditors (CPA firms) require evidence that controls were operating effectively over the audit period (typically 6–12 months for Type II). Infracast provides continuous evidence collection:

What Infracast Collects​

Evidence TypeHow CollectedRetention
Configuration snapshotsDiscovery jobs12 months
Finding historyAudit trail24 months
Remediation timelineChange tracking24 months
Access control statesIAM discovery12 months

Generating an Auditor Evidence Package​

POST /api/v1/tenants/{tenantID}/evidence/generate
{
  "framework": "soc2",
  "period_start": "2023-07-01",
  "period_end": "2024-06-30",
  "criteria": ["cc6", "cc7", "a1"],
  "format": "zip"
}

The package includes:

  • Monthly compliance score snapshots for the audit period
  • Finding open/close dates (demonstrating timely remediation)
  • Configuration evidence at each discovery checkpoint
  • Attestation records for manual controls (with approval chains)

Scheduling Continuous Evidence​

For SOC 2 Type II, evidence must demonstrate controls operated over time. Schedule weekly collection:

POST /api/v1/tenants/{tenantID}/reports/schedule
{
  "type": "evidence-package",
  "framework": "soc2",
  "frequency": "weekly",
  "day": "monday",
  "time": "06:00",
  "recipients": ["security@company.com"]
}
tip

Start collecting evidence at least 6 months before your SOC 2 audit window. Type II requires a minimum 6-month observation period.

Non-Technical Controls (Attestation-Driven)​

Many SOC 2 controls require policies and human processes rather than infrastructure checks:

CategoryExamplesHow Assessed
CC1 — Control EnvironmentCode of conduct, org structureAttestation
CC2 — CommunicationPolicy distribution, trainingAttestation
CC5 — Control ActivitiesVendor management, background checksAttestation
CC8 — Change ManagementChange approval processAttestation + automated drift detection

Use Infracast's questionnaire workflows to collect and track attestations:

# Create SOC 2 CC8 change management questionnaire
POST /api/v1/tenants/{tenantID}/questionnaires/from-template
{
  "template_id": "soc2-cc8-change-management",
  "title": "Change Management Controls — Q3 2024",
  "assignees": ["engineering-lead@company.com"]
}

Availability Criterion (A)​

For SaaS companies including availability in scope:

RuleTSCDescription
SOC2-A1.1-MULTI-AZA1.1RDS instances deployed multi-AZ
SOC2-A1.1-ALB-HEALTHA1.1Load balancers have health checks configured
SOC2-A1.2-BACKUP-ENABLEDA1.2RDS automated backups enabled
SOC2-A1.2-S3-VERSIONINGA1.2S3 versioning enabled for critical buckets
SOC2-A1.3-RECOVERY-PLANA1.3Disaster recovery plan (attestation)

SOC 2 Compliance Score​

GET /api/v1/tenants/{tenantID}/compliance/summary?framework=soc2

{
  "framework": "soc2",
  "score": 91,
  "criteria": {
    "cc": { "score": 89, "rules": 38, "passing": 34 },
    "a":  { "score": 100, "rules": 6, "passing": 6 },
    "c":  { "score": 100, "rules": 3, "passing": 3 }
  },
  "audit_period_days": 180,
  "evidence_snapshots": 26
}

Generating a SOC 2 Readiness Report​

Before engaging an auditor, generate a readiness assessment:

POST /api/v1/tenants/{tenantID}/reports/generate
{
  "type": "framework",
  "framework": "soc2",
  "format": "pdf",
  "options": {
    "report_subtype": "readiness",
    "include_remediation": true,
    "include_evidence_summary": true
  }
}

The readiness report highlights:

  • Controls currently failing (must remediate before audit)
  • Controls with insufficient evidence history (start collecting now)
  • Manual controls needing attestation
  • Projected SOC 2 score if current remediations complete

Next Steps​