SOC 2 Type II for Healthcare Data Platforms: What Engineers Need to Know

Introduction

SOC 2 Type II is now a standard procurement requirement for healthcare data platform vendors. Health plans, hospital systems, and health IT buyers ask for SOC 2 reports before signing contracts — and the absence of one is increasingly a disqualifier. But SOC 2 is not just a compliance checkbox for vendors. For internal healthcare data teams building shared platforms, SOC 2 provides a useful framework for the security and availability controls that should exist regardless of auditor requirements.

This guide focuses on what engineers actually build — the access controls, audit logging, change management processes, and monitoring capabilities that SOC 2 Type II audits examine over a 6–12 month period.

---

SOC 2 vs HIPAA: The Intersection

SOC 2 and [HIPAA](/terms/HIPAA) address overlapping but distinct concerns.

For a healthcare data platform, the two frameworks are complementary. HIPAA requires you to protect PHI. SOC 2 requires you to demonstrate that your security controls are operating effectively over time — not just at a single audit moment.

---

The Five Trust Service Criteria

SOC 2 audits evaluate up to five Trust Service Criteria (TSC). For healthcare data platforms, the three most relevant are:

1. Security (CC): Controls over logical and physical access, change management, risk assessment, and incident response.

2. Availability (A): System performance, uptime monitoring, disaster recovery, and backup procedures.

3. Confidentiality (C): Protection of confidential information — encryption, access restrictions, disposal procedures.

Privacy (P) and Processing Integrity (PI) are optional but increasingly expected by healthcare customers.

---

What Engineers Must Build: Security (CC)

Logical Access Controls (CC6.x)

The most granular SOC 2 requirements are in the CC6 criteria — logical access.

CC6.1 — Restrict logical access to data based on least privilege
CC6.2 — Authenticate users before granting access
CC6.3 — Remove access for departed employees promptly
CC6.6 — Restrict access to data from outside the system boundary
CC6.7 — Transmit data only over authorized channels

Implementation checklist:

• All data access requires authentication (no anonymous reads, even for internal APIs)
• Role-based access control enforced; no individual user accounts with direct DB access
• Access reviews conducted quarterly (evidence: export of user roles, review sign-off)
• Terminated employee access revoked within 24 hours of departure (evidence: HR offboarding log + access review)
• All data transmission encrypted in transit (TLS 1.2+ minimum; evidence: certificate records)
• Multi-factor authentication required for all privileged access

Change Management (CC8.x)

SOC 2 requires evidence that software and infrastructure changes go through a controlled process.

CC8.1 — Manage changes to infrastructure, data, software, and procedures

For a data platform:

• All DDL changes must go through PR review with a second approver
• Schema changes to PHI-bearing tables require documented approval from the data owner
• Infrastructure changes (Terraform) applied only through CI/CD with audit trail
• Rollback procedures documented and tested annually

Your change management log:

CREATE TABLE governance.change_log (
  change_id             VARCHAR(36)   NOT NULL,
  change_ts             TIMESTAMP     NOT NULL,
  changed_by            VARCHAR(100)  NOT NULL,
  approved_by           VARCHAR(100)  NOT NULL,
  change_type           VARCHAR(30),             -- DDL, PIPELINE, ACCESS, INFRASTRUCTURE
  change_desc    VARCHAR(1000) NOT NULL,
  affected_systems      VARCHAR(500),
  ticket_reference      VARCHAR(100),            -- Jira, ServiceNow ticket ID
  rollback_plan         VARCHAR(1000),
  change_outcome        VARCHAR(20),             -- SUCCESS, FAILED, ROLLED_BACK
  PRIMARY KEY (change_id)
);

---

What Engineers Must Build: Availability (A)

Monitoring and Alerting (A1.2)

SOC 2 auditors will ask for evidence of system monitoring and incident response. For a healthcare data platform, this means:

# Minimal monitoring checklist for SOC 2 Availability
monitoring_controls = {
    "pipeline_failure_alerting": "PagerDuty/Opsgenie alert within 5 min of Airflow failure",
    "data_freshness_monitoring": "Alert if claims data not updated within 24 hours",
    "warehouse_availability": "Uptime monitoring with SLA tracking (99.5% target)",
    "backup_validation": "Daily backup + weekly restore test + evidence log",
    "error_rate_alerting": "API error rate > 1% triggers alert within 10 minutes",
    "disk_capacity": "Alert at 80% storage capacity on all data stores"
}

Disaster Recovery (A1.3)

For SOC 2, DR is not enough — you must test it and produce evidence:

• RTO (Recovery Time Objective) and RPO (Recovery Point Objective) defined and documented
• DR test conducted at least annually
• DR test results documented (what was tested, what worked, what did not)

---

What Engineers Must Build: Confidentiality (C)

Encryption Standards

C1.1 — Identify and maintain confidential information
C1.2 — Dispose of confidential information to meet obligations

For healthcare data:

• Encryption at rest: AES-256 (or platform equivalent)
• Encryption in transit: TLS 1.2+ for all connections
• Key management: Documented key rotation schedule (annual minimum, 90 days for PHI encryption keys)
• Data disposal: Documented procedure for secure deletion of PHI when retention period expires

---

Common SOC 2 Gaps in Healthcare Data Teams

1. No formal access review process: Engineers know who has access to what, but there is no quarterly review cycle with documented sign-off.

2. Shared database credentials: Service accounts shared across multiple pipelines make it impossible to attribute access to a specific system or event.

3. No change management for data model changes: DDL changes deployed directly to production without PR review or approval.

4. Backup testing documentation absent: Backups run automatically but restore tests are not documented — auditors want evidence of tested recoverability.

5. Alerting exists but is not monitored: Monitoring dashboards are built but nobody is on-call to respond to alerts.

---

Key Takeaways

• SOC 2 Type II evaluates controls over time (6–12 months), not at a single point. The controls must be consistently operating — not just in place the week before the audit.
• Quarterly access reviews with documented sign-off are the most commonly missing SOC 2 control in data platform teams.
• Change management for DDL is a SOC 2 requirement, not just an engineering best practice. All schema changes need PR approval, a documented approver, and an audit trail.
• DR plans must be tested, documented, and producing evidence — "we have backups" is not sufficient; "we have backups and restored from them on this date" is.
• Before running any untested SQL against production PHI data, validate it with the [SQL Linter](/tools/sql-linter) to catch anti-patterns before they become a change management incident.