SOC 2

System and Organization Controls 2

Updated: September 20, 2025 

SOC 2 in General

System and Organization Controls 2 (SOC 2) is an attestation framework developed by the American Institute of CPAs (AICPA) that evaluates whether a service organization’s controls are designed and operating effectively against the Trust Services Criteria (TSC): security, availability, processing integrity, confidentiality, and privacy. It is commonly used by SaaS and cloud providers to demonstrate the maturity of their security and compliance controls to customers and partners.

History and overview

• Origin: Created by the AICPA to replace older SAS 70 style reports with a modern, control objective based evaluation for technology services.
• Focus: Internal controls over systems and data relevant to security, availability, processing integrity, confidentiality, and privacy.
• Report types:
  • Type 1: Point-in-time opinion on the suitability of the design of controls as of a specified date.
  • Type 2: Opinion on both the design and operating effectiveness of controls over a period of time, typically 3 to 12 months.
• Audience: Customers, prospects, and their auditors for vendor risk reviews and due diligence. Reports are restricted use and require NDA or similar access controls.

Type 1 vs Type 2

Why is it relevant

• Demonstrates reliability of internal controls for security and operations.
• Widely requested during vendor due diligence and enterprise procurement.
• Supports handling of PHI and other sensitive data alongside HIPAA programs, although SOC 2 itself is not a law.

Scope of application

Highly relevant for AI and digital health vendors that provide services to healthcare organizations, including:

• AI model hosting and inference platforms for clinical or operational use.
• Data engineering and analytics platforms processing medical or claims data.
• Patient engagement, triage, and virtual assistant applications.
• Data labeling, de-identification, and synthetic data services.
• Cloud-based EHR add-ons, imaging analysis, or decision support modules.

Core concepts and Trust Services Criteria

• Security (common criteria, required): Access control, change management, system operations, and threat detection.
• Availability: Resilience, capacity, backup, disaster recovery, and service continuity.
• Processing integrity: Completeness, accuracy, timeliness, and authorization of processing.
• Confidentiality: Classification, access restrictions, encryption, and secure disposal of confidential data.
• Privacy: Collection, use, retention, disclosure, and disposal of personal information according to stated privacy commitments and criteria.

How it applies to AI in healthcare

• Model lifecycle controls: Secure SDLC for data ingestion, feature engineering, training, validation, deployment, and monitoring.
• Access and segregation: Role based access to training and inference environments, separation of duties, and environment isolation.
• Data protection: Encryption in transit and at rest for PHI and confidential datasets, secrets management, and key rotation.
• Auditability: Logging and evidence for data lineage, model versions, hyperparameters, and inference requests.
• Reliability and integrity: Controls for model drift detection, change approval, rollback, and incident response related to model behavior.
• Third party management: Due diligence and monitoring of subservice organizations such as cloud, data labeling, MLOps, and messaging providers.
• Privacy criteria: Alignment of data collection and use with stated commitments and legal obligations when personal data is involved.

Key obligations and requirements

• Independent audit: SOC 2 Type 1 or Type 2 examinations are conducted by licensed CPA firms. Many organizations undergo these assessments annually to meet customer or contractual expectations, though annual audits are not a legal requirement.
• Defined scope: System boundary, services, and in scope Trust Services Criteria clearly described in the system description.
• Control environment: Documented policies, procedures, and technical controls for security, availability, integrity, confidentiality, and privacy as applicable.
• Monitoring and response: Continuous monitoring, vulnerability and patch management, incident detection, triage, notification, and post incident review.
• Vendor and subservice oversight: Carve out or inclusive method, complementary subservice organization controls, and ongoing vendor monitoring.
• User responsibilities: Complementary user entity controls that customers must implement to rely on the report.

Documentation and governance requirements

• System description: Services, infrastructure, software, people, processes, and data flows.
• Risk management: Risk assessment, treatment plans, and periodic reviews.
• Policies and procedures: Access control, change management, SDLC, secure coding, encryption, backup, DR, vendor management, privacy.
• Evidence and audit trails: Tickets, logs, screenshots, configs, and reports demonstrating control operation across the audit period.
• Security testing: Vulnerability scans, penetration tests, remediation tracking.
• Training and awareness: Security and privacy training with tracked completion.

Risks and challenges

• Cost and effort: Significant investment for control design, operation, and external audit.
• Evidence fatigue: Collecting and maintaining sufficient period evidence can strain small teams.
• Scope creep: Overly broad scope inflates cost and complexity without clear benefit.
• Shared responsibility gaps: Misalignment with customers on complementary user entity controls can lead to residual risk.

Best practices

• Adopt a controls first approach early and map to the Trust Services Criteria.
• Align with a baseline such as NIST CSF or ISO 27001 to structure governance.
• Automate evidence collection with CI pipelines, infrastructure as code, policy as code, and centralized logging.
• Institute secure SDLC and MLOps guardrails: code review, dependency scanning, model registry, and change approvals.
• Harden cloud and Kubernetes using benchmarks, configuration scanning, and secrets management.
• Define and test BCP and DR scenarios relevant to model serving and data stores.
• Maintain a clear subservice inventory and review vendor reports and SLAs at least annually.

Relevant and overlapping laws and frameworks

• HIPAA: SOC 2 supports operational security controls for PHI but does not replace HIPAA legal requirements or BAAs.
• GDPR, PHIPA, PIPEDA: SOC 2 privacy criteria can complement legal obligations but legal compliance is separate.
• NIST AI RMF and ISO 42001: Useful for AI governance and risk management alongside SOC 2 control objectives.
• ISO 27001: Overlapping control domains such as access control, cryptography, supplier management, and operations security.
• FDA AI/ML SaMD: For regulated medical devices, product safety and effectiveness requirements apply in addition to SOC 2.

Future developments

• Incremental updates to AICPA Trust Services Criteria and points of focus.
• Closer alignment between privacy criteria and evolving privacy laws such as CPRA and international equivalents.
• Growing use of AI governance frameworks and model specific control catalogs that map to SOC 2 objectives.

References and official sources

SOC 2 — AICPA Trust Services Criteria / SOC for Service Organizations: https://www.aicpa.org/resources/topic/audit-assurance/audit-and-assurance-greater-than-soc-2

System and Organization Controls (SOC) Suite of Services (AICPA): https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services

System and Organization Controls (SOC) 2 Type 2 (Microsoft description): https://learn.microsoft.com/en-us/compliance/regulatory/offering-soc-2