What SOC 2 Is (and Is Not)

SOC 2 is a voluntary compliance framework developed by American Institute of Certified Public Accountants (AICPA).

It is:

• An attestation report (not a law)

• Used to prove security, availability, and privacy controls

• Required de facto by enterprise customers, banks, healthcare, fintech

It is not:

• A certification

• A one-time checklist

• A government regulation

 

The SOC 2 Trust Services Criteria (TSC)

SOC 2 compliance is measured against five Trust Services Criteria:

 

1️⃣ Security (Mandatory)

Protection against unauthorized access and system misuse.

Required controls include:

• Access controls (least privilege)

• MFA & authentication

• Logging & monitoring

• Incident response

• Risk assessment

• Vendor security oversight

Every SOC 2 report includes Security

2️⃣ Availability (Optional)

System uptime and resilience.

Controls include:

• Uptime SLAs

• Disaster recovery plans

• Backup & restore testing

• Capacity monitoring

3️⃣ Confidentiality (Optional)

Protection of sensitive business data.

Controls include:

• Data classification

• Encryption at rest/in transit

• Secure data disposal

4️⃣ Processing Integrity (Optional)

Systems process data accurately and completely.

Controls include:

• Input validation

• Error detection

• Change management

• QA controls

5️⃣ Privacy (Optional)

Personal data handling aligned to privacy commitments.

Controls include:

• Privacy notices

• Data minimization

• Retention schedules

• DSAR handling

• Breach notification procedures

 

Often paired with GDPR / HIPAA

 

SOC 2 Report Types

SOC 2 Type I

• Snapshot of control design

• Point-in-time (audit date)

• Faster, cheaper

• Used for early sales cycles

SOC 2 Type II

• Tests design + operating effectiveness

• Covers 3–12 months

• Gold standard for enterprises

• Required by most large buyers

​

Core SOC 2 Requirements (Rules in Practice)

🔹 Governance

• Written security & privacy policies

• Risk assessment process

• Defined roles & responsibilities

• Management oversight

 

🔹 Access Controls

• User provisioning/deprovisioning

• MFA for sensitive systems

• Role-based access

• Periodic access reviews

 

🔹 Security Operations

• Logging & monitoring

• Incident response plan

• Vulnerability scanning

• Penetration testing (often expected)

 

🔹 Change Management

• Code review process

• Change approvals

• Rollback procedures

• Environment separation (prod vs dev)

 

🔹 Vendor Management

• Vendor risk assessments

• Security reviews

• Contractual controls

• Ongoing monitoring

 

🔹 Evidence & Logging

Auditors require proof, not promises:

• Screenshots

• Logs

• Tickets

• Training records

• Policy version history

 

What Auditors Actually Test

Auditors verify:

• Controls exist

• Controls are designed properly

• Controls operate consistently

• Evidence matches the control description

Missing evidence = failed control, even if security is strong.

 

Who Needs SOC 2?

SOC 2 is effectively required if you sell to:

• Enterprise SaaS customers

• Financial institutions

• Healthcare orgs

• Government contractors

• AI & data platforms

• B2B infrastructure companies

 

Common SOC 2 Misconceptions

“We use AWS, so we’re SOC 2 compliant”
→ AWS helps, you are still responsible

“SOC 2 is a checklist”
→ It’s a control system + evidence discipline

“We can rush Type II in a month”
→ Minimum 3 months of operation

 

Penalties for Not Having SOC 2

SOC 2 has no fines, but very real consequences:

• Lost enterprise deals

• Failed vendor security reviews

• Procurement rejection

• Lower company valuation

​