If you have SOC 2 and assume HIPAA is incremental, your pipeline disagrees.

SOC 2 audits the policies you chose. HIPAA audits the system you built. At the CI/CD layer, that distinction stops being abstract and starts producing engineering work.

A healthcare engineering team I worked with had Type II SOC 2 in hand. They had passed it the year before on the second attempt. Their pipeline was clean, their evidence binder tidy, their GRC lead had stopped flinching at the word "scope."

Then they closed their first hospital system. The contract came with a Business Associate Agreement and a HIPAA addendum. Legal forwarded it to engineering with a one-line note: "Should be fine, we have SOC 2."

It was not fine. Inside two weeks they had fourteen control gaps. Their pipeline runners sat on a shared pool that handled both staging and a non-PHI demo environment. Their audit logs rolled off at 90 days. Their cosign signature verification was a soft warning in their Helm chart, not a deploy-blocker. Their incident response runbook said the right things about breach notification, but their pipeline emitted nothing the legal team could query against the 60-day clock in 45 CFR § 164.404. They had SOC 2. They did not have the system HIPAA assumes.

Six weeks later, after three pipeline rewrites and a round of running the BAA through outside counsel, they shipped. The 20% gap between SOC 2 and HIPAA is not 20% of the cost. It is the part of the pipeline that has to change to emit evidence on its own.

SOC 2 lets you scope your controls and have your auditor read a narrative. HIPAA hands you the Security Rule, removes most of your scoping latitude, and asks the system itself to produce the evidence. At the pipeline layer, that distinction produces changes you cannot policy your way out of. The rest of this post is a control-by-control map of where those changes live. If you are coming from the earlier HIPAA CI/CD implementation guide, this is the comparison piece beside it. The pillar page covers positioning and control mapping at the architecture level.

Section 01 — The framework difference in one sentence

SOC 2 is a trust services framework. You choose which of the five criteria (security, availability, processing integrity, confidentiality, privacy) you attest against, and which systems are in scope. Your auditor reads your description, looks at evidence for the controls you committed to, and writes a narrative report. If your framework is reasonable and your evidence consistent with what you claimed, you pass.

HIPAA's Security Rule is not a framework you scope. It is a federal regulation. 45 CFR § 164 sets administrative, physical, and technical safeguards. Some are "required"; some are "addressable" (implement or document a defensible alternative). You do not scope out of the Security Rule for an environment that handles PHI. You choose how to implement, not whether.

At the pipeline level, this is the difference that drives everything else. SOC 2 lets you write "production deploys are reviewed by an authorized engineer per documented procedure" and have your auditor confirm the procedure is followed. HIPAA expects the same control implemented in a way that is observable and queryable, with the system itself producing the evidence at the time the control runs. SOC 2 audits the policy. HIPAA audits the artifact.

Once you accept that framing, the rest of the comparison is a series of consequences.

Section 02 — Where HIPAA and SOC 2 controls overlap

Three control areas are roughly equivalent between SOC 2 and HIPAA at the pipeline layer. If you implemented them honestly for SOC 2 Type II, you are most of the way to the HIPAA equivalent. This is the overlap the comparison vendors latch onto.

Pipeline access control. SOC 2's CC6.1 requires logical access controls over systems in scope. HIPAA's § 164.312(a)(1) requires unique user identification, emergency access procedure, automatic logoff, and encryption controls. Both want the same pipeline-layer thing: MFA-protected CI/CD access, no shared service accounts triggering deploys, identity attribution on every job. A SOC 2 implementation with SSO + MFA and no long-lived bearer tokens covers HIPAA's unique user identification cleanly.

Encryption in transit. SOC 2's CC6.7 requires data in transit between components is protected. HIPAA's § 164.312(e)(1) requires transmission security for PHI. Both expect TLS 1.2+ on every channel touching sensitive data: pipeline to registry, pipeline to cloud API, pipeline to deploy target. Same configuration, same evidence shape.

Audit logging baseline. SOC 2's CC7.2 requires monitoring system components for anomalies and security events. HIPAA's § 164.312(b) requires audit controls that record activity on systems containing PHI. Both expect pipeline-level logs capturing who did what, when, on which artifact. If your SOC 2 evidence already streams pipeline logs to a SIEM, the HIPAA baseline is covered.

These three overlap honestly. They are why "we have SOC 2 so we're 80% there" sounds plausible. The problem is what's left after the easy 60%. The pillar page walks the architecture control by control.

Section 03 — Where HIPAA and SOC 2 controls diverge

Five control areas break the SOC 2-to-HIPAA equivalence story. Each is a place where the SOC 2 implementation is acceptable as policy and inadequate as system.

Business Associate Agreement scope. HIPAA requires that every entity touching PHI on your behalf, including downstream services in the pipeline, is covered by a BAA. SOC 2 has no equivalent concept. A pipeline that uses a managed KMS service for cosign signatures, a container registry for PHI-bound images, and a secrets manager for deploy credentials is fine for SOC 2 if your vendor list is current. For HIPAA, every one of those services has to be BAA-covered and the runner orchestrating them has to be covered too. § 164.308(a)(4) sets the requirement.

Six-year retention with immutability. SOC 2 does not specify a minimum audit log retention. Your auditor will accept whatever you wrote. HIPAA § 164.316(b)(2)(i) is specific: documentation must be retained for six years from creation or the date it was last in effect, whichever is later. And it must be defensible, which in practice means immutable. A pipeline that writes audit logs to a default CloudWatch group with 90-day retention is a SOC 2 yes and a HIPAA no.

Encryption verification, not attestation. SOC 2 accepts "TLS 1.2 enforced via load balancer policy, verified during the annual review." HIPAA's § 164.312(a)(2)(iv) and § 164.312(e)(1) expect ongoing assurance that encryption is happening, not that it was once configured. At the pipeline layer, that means deploy-time tests that fail the build when TLS verification breaks, not a once-a-year posture review.

Workforce sanction enforcement. HIPAA § 164.308(a)(1)(ii)(C) requires sanctions applied against workforce members who fail to comply with security policies. SOC 2 expects you to have a sanction policy. HIPAA expects it enforced, which in pipeline terms means a deploy by a workforce member whose access has been revoked fails at the runner, not at the code review.

Breach notification telemetry. HIPAA § 164.404 gives covered entities 60 days from breach discovery to notify affected individuals. SOC 2 has no equivalent regulatory clock. HIPAA expects the system to surface enough provenance that a security event can be scoped against the 60-day window; SOC 2 lets you reconstruct the same evidence over weeks.

These five gaps are where the engineering work lives. They are also where the comparison vendors stop writing. The next four sections walk what each requires from the pipeline, with code.

Decision 01 — Which framework owns your evidence model

Every architectural decision that follows comes down to one question: which framework owns your evidence model? Build the pipeline for SOC 2 evidence and you build something an auditor can read. Build it for HIPAA evidence and you build something an auditor can query.

SOC 2 evidence is built for narrative: screenshots, control descriptions, sample-based attestations, policy documents reviewed annually. The model assumes a human assembles evidence on a schedule, an auditor reads it, and the narrative carries the weight. HIPAA evidence is built for query: signed manifests, append-only audit logs, immutable artifact registries, deploy events with attribution timestamps. The system itself is the source of truth, producing the workflow and the evidence at the same time.

My opinionated stance: if you are building a pipeline that will support both frameworks, architect it for HIPAA evidence. The reverse path does not work. A SOC 2-shaped evidence pipeline will not pass HIPAA's evidence expectations without a rebuild. A HIPAA-shaped evidence pipeline produces SOC 2 evidence as a side effect of operating correctly. Build for the stricter framework; the looser one comes free.

Decision 02 — Pipeline access and BAA scope

SOC 2 lets you document which engineers can deploy. HIPAA expects the runner to enforce it, and extends the requirement to every downstream service the runner touches.

§ 164.308(a)(4) requires that workforce access to PHI is granted only to those whose role justifies it. The Security Rule extends that obligation to systems accessing PHI, including CI/CD systems and the downstream services they call. A pipeline runner with IAM credentials reaching PHI-bearing workloads is itself in BAA scope. So is every service it touches. That produces three pipeline-level requirements SOC 2 does not check:

• The runner is on infrastructure covered by a BAA, your own or a cloud provider's BAA-covered service.
• Every downstream service the runner calls (KMS, registry, secrets manager, deploy target) is BAA-covered.
• The deploy attempt fails if any service in the chain falls outside that scope.

The third requirement is where policy-as-code earns its place. An OPA policy at the deploy gate inspects the deploy context, verifies every service touched is in the BAA-covered set, and blocks the deploy if any is not. The pipeline does not depend on a human knowing which services are covered. The policy does.

# policies/baa_scope.rego
# Block HIPAA pipeline deploys that touch a service outside BAA scope.
# Evaluated by the parent pipeline before any deploy stage runs.

package deploy.hipaa

import rego.v1

# Services covered under an active BAA, with effective date.
# Sourced from a maintained registry, not hand-edited per build.
baa_covered := {
    "kms.googleapis.com":              "2025-01-15",
    "artifactregistry.googleapis.com": "2025-01-15",
    "secretmanager.googleapis.com":    "2025-01-15",
    "container.googleapis.com":        "2025-01-15",
    "logging.googleapis.com":          "2025-01-15",
}

# Workforce members with current PHI access entitlement.
# Sourced from IdP group membership at evaluation time.
authorized_actors := {"alice@example.com", "bob@example.com"}

default allow := false

allow if {
    actor_authorized
    every_service_covered
    runner_in_scope
}

actor_authorized if {
    input.deploy.actor in authorized_actors
}

every_service_covered if {
    not unscoped_service_exists
}

unscoped_service_exists if {
    some s in input.deploy.services_touched
    not baa_covered[s]
}

runner_in_scope if {
    input.runner.tag == "hipaa-prod-runner"
    input.runner.signed == true
}

# Deny messages surface in the pipeline log for the auditor.
deny contains msg if {
    some s in input.deploy.services_touched
    not baa_covered[s]
    msg := sprintf("service %s is outside BAA scope; deploy blocked", [s])
}

deny contains msg if {
    not input.deploy.actor in authorized_actors
    msg := sprintf("actor %s lacks current PHI entitlement", [input.deploy.actor])
}

The policy is small on purpose. It runs against the same evidence bundle the parent pipeline aggregates, the same one referenced in the parent/child architecture in the implementation guide. The BAA registry is its own resource, kept in code with PRs gated on legal review. When a new service is introduced, the deploy fails until legal confirms coverage. Engineering does not have to keep the BAA list in their head.

For SOC 2, the policy is overkill. For HIPAA, this is the minimum that survives an evidence pull.

Decision 03 — Audit log retention and immutability

SOC 2 retention is whatever you wrote in your policy. HIPAA retention is six years, immutable, recoverable. § 164.316(b)(2)(i) is direct about this, and it is one of the harder controls to retrofit later because retroactively making logs immutable is not a thing you can do.

Three pipeline implications:

• Audit events go to a write-once destination at the time the event happens, not at end of pipeline.
• The destination supports object retention locks for the full six-year window, with no path to early deletion.
• The pipeline emits a signed manifest of every audit event, so tampering is detectable at audit time.

On AWS, the cleanest implementation is S3 Object Lock in compliance mode with a six-year retention. On GCP, Bucket Lock with equivalent duration. Both work; neither is set up by default.

# .github/workflows/audit-emit.yml
# Reusable workflow: emit a HIPAA-aligned audit event to an Object Lock bucket.
# Caller workflows invoke this on every pipeline state change worth recording.

name: emit-audit-event
on:
  workflow_call:
    inputs:
      event_type:
        required: true
        type: string
      artifact_digest:
        required: true
        type: string

jobs:
  emit:
    runs-on: hipaa-prod-runner
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Assume audit writer role
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/hipaa-audit-writer
          aws-region: us-west-2

      - name: Compose audit event
        run: |
          # Event schema mirrors the SIEM ingestion contract.
          # Hash the inputs so any field tampering invalidates the manifest.
          cat > event.json <<EOF
          {
            "event_type": "${{ inputs.event_type }}",
            "artifact_digest": "${{ inputs.artifact_digest }}",
            "actor": "${{ github.actor }}",
            "pipeline_id": "${{ github.run_id }}",
            "occurred_at": "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
          }
          EOF
          sha256sum event.json | awk '{print $1}' > event.sha256

      - name: Write to Object Lock bucket
        run: |
          # Compliance mode: no override path, even for the root account.
          # Retention set on the object itself, not a bucket policy that can be relaxed.
          aws s3api put-object \
            --bucket hipaa-audit-logs \
            --key "events/${{ github.run_id }}/$(date -u +%s).json" \
            --body event.json \
            --object-lock-mode COMPLIANCE \
            --object-lock-retain-until-date \
              "$(date -u -d '+6 years' +%Y-%m-%dT%H:%M:%SZ)"

Retention is set on the object itself, not on a bucket policy that can be relaxed later. Compliance mode means the retention cannot be shortened even by the AWS root account. The manifest hash is computed before write, so tampering is detectable. A query "who deployed artifact X" returns the workforce member, the runner, the artifact digest, and the timestamp in one row.

For SOC 2, this is more than your auditor will ask for. For HIPAA, this is the floor.

Decision 04 — Encryption verification, not attestation

SOC 2 lets you say "TLS 1.2 enforced via load balancer policy." HIPAA expects the pipeline to verify it on every deploy.

§ 164.312(a)(2)(iv) on encryption and § 164.312(e)(1) on transmission security both map to SOC 2's CC6.7, which accepts annual attestation. HIPAA does not. The expectation is that encryption posture is verified at deploy time, with failure modes that block the deploy. Two verifications matter at the pipeline layer:

• Artifact signature verification. Every container deployed to a PHI-bearing environment carries a cosign signature; the deploy fails if signature verification fails.
• Transit verification. Every PHI-touching endpoint the pipeline reaches negotiates TLS 1.2+ with a current cipher; the deploy fails if any endpoint downgrades or refuses.

#!/usr/bin/env bash
# scripts/verify-encryption.sh
# Run at the end of the deploy stage. Blocks the deploy on any verification miss.
# HIPAA-aligned: § 164.312(a)(2)(iv) and § 164.312(e)(1).

set -euo pipefail

IMAGE_DIGEST="${1:?image digest required}"
PHI_ENDPOINTS=(
    "https://api.hipaa-app.internal/v1/healthz"
    "https://audit.hipaa-app.internal/ingest"
)

verify_signature() {
    local digest="$1"
    # Verify against the production-only Fulcio identity.
    # Any other signer fails the build.
    cosign verify "${digest}" \
        --certificate-identity "platform-team@example.com" \
        --certificate-oidc-issuer "https://accounts.google.com" \
        > /dev/null
}

verify_transit() {
    local url="$1"
    # Require TLS 1.2+, refuse on downgrade.
    # Surface the negotiated protocol for the audit log.
    local proto
    proto=$(curl --silent --tls-max 1.3 --tlsv1.2 \
        --write-out "%{ssl_version}" --output /dev/null \
        "${url}")
    case "${proto}" in
        TLSv1.2|TLSv1.3) echo "ok ${url} ${proto}" ;;
        *) echo "fail ${url} ${proto}" >&2; return 1 ;;
    esac
}

echo "== verifying artifact signature"
verify_signature "${IMAGE_DIGEST}"

echo "== verifying transit posture"
for endpoint in "${PHI_ENDPOINTS[@]}"; do
    verify_transit "${endpoint}"
done

echo "== encryption verification ok"

Two things matter. First, it is a deploy gate, not a post-deploy check. A failed signature or a TLS downgrade blocks the deploy before any PHI-touching code reaches a runtime handling a request. Second, the verification output is itself an audit event, written to the Object Lock bucket from Decision 03. The auditor's question, "show me that encryption was verified on the deploy that touched record X," has a one-query answer.

SOC 2 tells you the load balancer config is correct. HIPAA tells you the deploy on May 13 at 09:14 UTC verified TLS 1.3 to the audit endpoint and TLS 1.2 to the API endpoint with this cipher.

Section 04 — HIPAA SOC 2 control mapping, opinionated

The table below is the version of "HIPAA vs SOC 2" I would hand a platform team on day one of an engagement. It maps the control areas where the frameworks diverge against the pipeline pattern we would build, the pattern we would accept under time pressure, and the pattern we would refuse to ship.

"Recommended" passes both audits without ambiguity. "Acceptable" is what you sit in under time pressure, with a written remediation date. "Avoid" produces audit findings.

Section 05 — What SOC 2 to HIPAA migration looked like in production

Six weeks. Eight engineers across two squads. Roughly 5,200 lines of new pipeline code, 1,800 lines retired. That was the shape of the engagement that triggered this post.

The team came in with passing Type II SOC 2, a closed contract with a regional hospital system, and a BAA addendum that assumed evidence the pipeline could not yet produce. We mapped their existing SOC 2 evidence against the Security Rule. The overlap was real: pipeline access was already SSO with MFA, transit was already TLS 1.2+, audit logs already streamed to a SIEM. The gaps were the ones in Section 03. None were unfamiliar; all required engineering work.

The work split four weeks pipeline and four weeks the runtime and IAM context the pipeline depended on. Pipeline rewrites cost less time than expected; parent/child separation was already partially in place, and the OPA gate for BAA scope fit cleanly into the structure they had. The expensive work was outside the pipeline: an IAM redesign to scope the audit writer role away from any operator who could shorten retention, legal review of every cloud service in the deploy path (which surfaced three uncovered services no one had noticed), and the cosign deploy gate catching a staging cluster pulling unsigned dev images through a cached registry mirror. None of those was a pipeline bug. All were pipeline-adjacent.

What shipped at week six was a pipeline that emitted evidence on its own, against the Security Rule, with the same control set the SOC 2 auditor had read about in narrative. The first internal HIPAA audit took the platform lead 90 minutes instead of the four days the prior SOC 2 evidence pull had taken. That is the difference between a system that produces evidence and a human who produces evidence about a system.

Section 06 — Common mistakes

Three calls show up in nearly every "we have SOC 2, adding HIPAA" conversation. Each one is wrong in a specific way.

• "We're 80% there because we have SOC 2." The overlap is 60% on control inventory and much smaller on implementation work. The 40% gap is where the architecture has to change. SOC 2 was built for narrative; HIPAA was built for query. Most of the engineering cost lives in the conversion.
• "We can use the same auditor." Sometimes true, often beside the point. Your SOC 2 auditor reads your control framework against criteria you chose. Your HIPAA controls have to satisfy a regulation you did not choose. The evidence shape has to change regardless of who reads it. The earlier post on five things healthcare engineering teams get wrong about HIPAA CI/CD walks five places where SOC 2-style evidence passes and HIPAA-style evidence does not.
• "Our pipeline doesn't really touch PHI." It almost always does, once you trace artifact provenance. The artifact you build runs against PHI in production. The cosign key signs it. The deploy credential places it. The audit log records the placement. Every one of those is a HIPAA touchpoint. The pipeline does not have to read PHI to be in scope.

Each call is reasonable on its face. Each underbudgets the engineering work by a factor of three. The vendors making the call get paid for the conclusion; the platform team pays for the rewrite.

Section 07 — Frequently asked

Do I need HIPAA compliance if I already have SOC 2?

Yes, if your environment touches PHI. SOC 2 is a voluntary trust services framework where you scope your own controls. HIPAA is a federal regulation that does not let you scope out of the Security Rule for any environment handling PHI. SOC 2 compliance covers about 60% of HIPAA's control inventory at the pipeline layer, but does not satisfy HIPAA's evidence requirements. The remaining 40% is engineering work.

How long does it take to add HIPAA to a SOC 2 pipeline?

Three months is a defensible estimate if the engineering team is honest about the work involved. The expensive parts are BAA scope mapping across every service the pipeline touches, audit log retention architecture with six-year immutability, and encryption verification gates at deploy time. Thirty days is the number comparison vendors quote and the platform team regrets accepting.

Is SOC 2 enough for selling into healthcare?

No. SOC 2 Type II is table stakes for B2B SaaS but does not satisfy HIPAA requirements for handling Protected Health Information. Hospital systems and other covered entities require a Business Associate Agreement and HIPAA-compliant controls, which SOC 2 alone does not provide. SOC 2 plus HIPAA is the combination most healthcare engineering teams need.

What's the difference between HIPAA and SOC 2 audit log requirements?

SOC 2 does not specify a minimum audit log retention; your auditor accepts whatever you wrote in your policy. HIPAA § 164.316(b)(2)(i) requires six years of retention from creation or last effective date, whichever is later, with practical immutability requirements. A pipeline writing audit logs to default CloudWatch retention with 90-day rollover passes SOC 2 but fails HIPAA.

Does SOC 2 compliance satisfy a Business Associate Agreement?

No. BAA is a HIPAA construct with no SOC 2 equivalent. Every entity that touches PHI on your behalf, including downstream services in your CI/CD pipeline, must be covered by a BAA. SOC 2 has no mechanism for this requirement. The runner orchestrating deploys, the KMS service signing artifacts, the registry holding PHI-bound images, and the secrets manager providing deploy credentials all need BAA coverage under HIPAA.

Can I use the same auditor for HIPAA and SOC 2?

Sometimes, but it's often beside the point. Your SOC 2 auditor reads your control framework against criteria you chose. Your HIPAA controls have to satisfy a federal regulation you did not choose. The evidence shape has to change regardless of who reads it. A SOC 2-shaped evidence pipeline will not pass HIPAA expectations without a rebuild; the opposite is not true.

How much does it cost to upgrade from SOC 2 to HIPAA-compliant CI/CD?

Pricing depends on the size of your engineering team, the number of pipelines in scope, and the maturity of your existing SOC 2 controls. A two-week fixed-fee HIPAA CI/CD audit produces a written remediation roadmap with effort estimates sized to your specific environment. Stonebridge runs audit and build engagements as fixed-fee, so you know the scope, the deliverables, and the price before any work starts.

Section 08 — Closing

SOC 2 audits the policies you chose. HIPAA audits the system you built. The overlap is real and worth using. The divergence is real and worth budgeting for. Three months is a defensible estimate if the team is honest about the work; thirty days is the number the comparison vendors quote and the platform team regrets accepting.

Compliance is a property of the system, not a process humans run. Build the pipeline to emit HIPAA evidence on its own, and SOC 2 evidence falls out of normal operation. Build it the other way and the gap closes by rewrite, not retrofit.

If you are in the SOC 2-to-HIPAA conversation right now: Stonebridge runs two-week HIPAA CI/CD audits that map your existing SOC 2 controls against the Security Rule and produce a written remediation roadmap. Fixed fee, founder-led, the report holds up under first-party review.

Keep reading: the practitioner's walkthrough of every Security Rule control before an audit lives in the HIPAA CI/CD audit checklist for engineering teams.

About the author

Lucas Jones is the Founder and Principal Platform Engineer at Stonebridge Tech Solutions. Six years building cloud infrastructure and CI/CD pipelines in regulated environments, including HIPAA, FedRAMP, and SOC 2 work for healthcare and defense engineering teams across AWS, GCP, Azure, and OCI. Based in Sacramento, California.

This post originally appeared on Stonebridge Tech Solutions.