DEV Community: Stonebridge Tech Solutions LLC

GitLab CI/CD parent/child pipelines for HIPAA workloads

Stonebridge Tech Solutions LLC — Tue, 26 May 2026 15:58:39 +0000

What moves to the parent, what stays in the child, and why the boundary is itself a compliance control.

GitLab gives you the strongest parent/child pipeline primitives of any major CI platform. Most HIPAA teams using GitLab still throw the advantage away.

A healthcare platform team I worked with on GCP had a 1,200-line .gitlab-ci.yml at the root of their monorepo. It shipped. Tests ran. Containers built. The platform was stable across roughly 32 production VM-backed services that mixed Tomcat, Node.js, and Ubuntu in ways nobody had inventoried. They had a 3PAO assessment scheduled in five weeks. The compliance officer wanted to know how the pipeline answered the Security Rule. The pipeline file was 1,200 lines and growing.

The pipeline could not, in any useful sense, answer the Security Rule. Production approval gates, scanner evaluations, evidence emission, deploy authorization, and per-service build logic all lived in the same file. Every YAML change risked dropping a compliance gate that nobody noticed was load-bearing. The auditor's question, "show me that production deploys are gated", required reading the entire file to answer. We rebuilt the pipeline before the assessment. The change that mattered most wasn't a new scanner or a tightened IAM role. It was the parent/child split.

This post is the GitLab-specific deep dive on that split. What moves to the parent, what stays in the child, how the artifact contract between them works, and how the pattern handles a polyrepo with five separate repos for backend, frontend, infrastructure, networking, and security. Argo CD comes in briefly at the deploy stage; the depth on that lives in the upcoming Kubernetes platform engineering posts.

If you've read the broader HIPAA CI/CD implementation guide, this is the GitLab-specific implementation of the parent/child architecture introduced there. The cloud examples here cover GCP because that is where this engagement lived, but the pattern ports directly to AWS with EKS plus IRSA in place of GKE plus Workload Identity.

Section 01 — Why GitLab is the strongest HIPAA CI primitive

Three GitLab features make the parent/child split nearly free. Used together, they're the cleanest primitives any major CI platform offers for HIPAA compliance work.

The trigger: keyword. A job in the parent pipeline triggers a downstream pipeline (the child), waits for it to complete, and consumes its artifacts. The parent does not need to know how the child builds its service. The child does not need to know which compliance gates the parent enforces. The interface is the artifact bundle.

Multi-project triggers. The same trigger: primitive crosses repository boundaries with trigger: project:. A parent pipeline in a compliance-platform repo can fan out to children in the backend, frontend, infrastructure, networking, and security repos. The compliance team owns the parent; service teams own their respective children. Code review, branch protection, and access controls are scoped per repo.

Tag-based runner targeting. Self-hosted runners register with one or more tags. The pipeline's tags: array determines which runner picks up the job. A job that requires the hipaa-prod-runner tag is only ever picked up by a runner with that tag registered. Runner registration is itself controlled by GitLab admins. Combined with scoped IAM per runner, the runner tag becomes a structural compliance control, not a procedural one.

None of these is exotic. All three are built into GitLab CE and have been stable for years. The three architectural decisions at the pillar page compose them into the audit-ready pattern this post implements.

Section 02 — What moves to the parent pipeline

The parent pipeline owns environment-level concerns. It changes rarely. The compliance team approves every merge to the repo that holds it. Every job in the parent is tied to a specific Security Rule control.

Five responsibilities sit in the parent:

Identity verification. Before any child runs, the parent confirms the triggering user is authorized for the target environment. § 164.308(a)(4).
Child orchestration. The parent triggers each child pipeline, in order or in parallel, and waits for completion.
Evidence aggregation. The parent collects signed evidence artifacts from each child into a single bundle, then writes the bundle to the evidence bucket. § 164.312(b).
Policy gate. The parent invokes OPA against the evidence bundle. The gate returns allow or deny. § 164.308(a)(8) and § 164.312(c)(1).
Deploy authorization. If the gate allows and a named approver clicks the deploy button, the parent triggers the deploy stage on the prod-only runner. § 164.312(e)(1).

Everything outside that list belongs in a child. Unit tests are not the parent's job. Container builds are not the parent's job. Lint checks are not the parent's job. The parent owns the gates; the children own the code.

# compliance-platform/.gitlab-ci.yml
# Parent pipeline. Owns gates, evidence, deploy authorization.
# Children live in the five service repos and are triggered below.

stages:
  - authorize
  - trigger-children
  - aggregate-evidence
  - policy-gate
  - deploy

variables:
  HIPAA_ENVIRONMENT: $CI_COMMIT_BRANCH
  EVIDENCE_BUCKET: "gs://hipaa-evidence-prod"

authorize:
  stage: authorize
  image: google/cloud-sdk:slim
  script:
    - ./scripts/verify-identity.sh "$GITLAB_USER_LOGIN" "$HIPAA_ENVIRONMENT"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

trigger-backend:
  stage: trigger-children
  trigger:
    project: hipaa-app-org/backend
    branch: main
    strategy: depend

trigger-frontend:
  stage: trigger-children
  trigger:
    project: hipaa-app-org/frontend
    branch: main
    strategy: depend

trigger-infra:
  stage: trigger-children
  trigger:
    project: hipaa-app-org/infrastructure
    branch: main
    strategy: depend

trigger-networking:
  stage: trigger-children
  trigger:
    project: hipaa-app-org/networking
    branch: main
    strategy: depend

trigger-security:
  stage: trigger-children
  trigger:
    project: hipaa-app-org/security
    branch: main
    strategy: depend

aggregate-evidence:
  stage: aggregate-evidence
  image: google/cloud-sdk:slim
  script:
    - ./scripts/collect-child-evidence.sh "$CI_PIPELINE_ID"
    - gsutil cp evidence-bundle.json
        "$EVIDENCE_BUCKET/parent-$CI_PIPELINE_ID/bundle.json"
  needs:
    - trigger-backend
    - trigger-frontend
    - trigger-infra
    - trigger-networking
    - trigger-security

policy-gate:
  stage: policy-gate
  image: openpolicyagent/opa:0.62
  script:
    - opa eval -d policies/ -i evidence-bundle.json
        "data.deploy.hipaa.allow" --format=raw | grep -q true
  needs: ["aggregate-evidence"]

deploy-production:
  stage: deploy
  tags: ["hipaa-prod-runner"]
  environment: production
  when: manual
  script:
    - ./scripts/deploy-signed.sh
  needs: ["policy-gate"]

That's the entire parent. Roughly 60 lines, every job tied to a Security Rule control, every stage doing one thing. The compliance team can read this file in two minutes and tell the auditor exactly which job satisfies which control. When something changes, the change is small and reviewable.

Section 03 — What stays in the child pipeline

The child pipeline owns the service. Every service repo has its own .gitlab-ci.yml. The service team owns the file. They can change it freely as long as the artifact contract back to the parent stays intact.

The child's responsibilities:

Build. Compile, package, produce a container image with a tagged digest.
Test. Unit, integration, contract. Whatever the service team needs.
Scan. SAST, container CVE, IaC, secret, dependency. Each scan produces a signed evidence artifact.
Sign. Cosign signs the image with a KMS-backed key. The signature is itself an artifact.
Emit evidence. Every scan output, every signature, every build event is written into the artifact bundle the parent will collect.

The child does not deploy. The child does not approve. The child does not decide whether a scan result is acceptable. Those are parent concerns. Keeping the boundary clean is what lets each child evolve independently.

# backend/.gitlab-ci.yml
# Child pipeline. Service team owns this file.
# Triggered by the parent in compliance-platform.

stages:
  - build
  - test
  - scan
  - sign
  - emit

variables:
  IMAGE: "us-east1-docker.pkg.dev/hipaa-app-prod/backend/backend"

build:
  stage: build
  tags: ["hipaa-build-runner"]
  script:
    - docker buildx build -t $IMAGE:$CI_COMMIT_SHA --output type=docker .
    - docker push $IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      dotenv: build.env

scan-container:
  stage: scan
  tags: ["hipaa-build-runner"]
  image: aquasec/trivy:latest
  script:
    - trivy image --severity HIGH,CRITICAL --format json
        --output trivy.json $IMAGE@$IMAGE_DIGEST
  artifacts:
    paths: [trivy.json]
    reports:
      container_scanning: trivy.json

scan-sast:
  stage: scan
  tags: ["hipaa-build-runner"]
  image: returntocorp/semgrep:latest
  script:
    - semgrep ci --config=p/hipaa --json --output=semgrep.json
  artifacts:
    paths: [semgrep.json]
    reports:
      sast: semgrep.json

sign:
  stage: sign
  tags: ["hipaa-build-runner"]
  script:
    - cosign sign --key gcpkms://projects/hipaa-app-prod/locations/us-east1/keyRings/hipaa/cryptoKeys/signing
        $IMAGE@$IMAGE_DIGEST
    - cosign verify --key gcpkms://...signing $IMAGE@$IMAGE_DIGEST > signature.json
  artifacts:
    paths: [signature.json]

emit-evidence:
  stage: emit
  tags: ["hipaa-build-runner"]
  script:
    - ./scripts/bundle-evidence.sh
        trivy.json semgrep.json signature.json
        > child-evidence.json
  artifacts:
    paths: [child-evidence.json]
    expire_in: 30 days

Notice what's not here. No deploy job. No approval gate. No reference to a production environment. The child does not know it is part of a HIPAA pipeline; it produces evidence and exposes it as artifacts. The parent does the rest.

Section 04 — The artifact contract between parent and child

The boundary between parent and child is the artifact contract. The parent triggers the child with strategy: depend; the parent's job stays in running state until the child finishes and exposes its artifacts. The parent then collects those artifacts and aggregates them.

Two GitLab artifact mechanisms carry the contract:

artifacts:reports:dotenv propagates structured variables (like IMAGE_DIGEST) from one job to the next in the same pipeline. The parent can read these once the trigger job completes.
artifacts:reports:<type> (container_scanning, sast, secret_detection, dependency_scanning) are typed report formats GitLab understands. The parent's evidence collection script reads them from the child's pipeline directly via the GitLab API.

The parent's collect-child-evidence.sh script walks the API: list child pipelines triggered by this parent, list each child's jobs, fetch the artifact archives, extract the structured reports, and write the combined JSON bundle to the evidence bucket.

#!/usr/bin/env bash
# scripts/collect-child-evidence.sh
# Walks the GitLab API to assemble the evidence bundle from
# every child pipeline triggered by this parent run.

set -euo pipefail

PARENT_ID="$1"
API="https://gitlab.com/api/v4"
TOKEN="$EVIDENCE_READ_TOKEN"

# Find every downstream pipeline this parent triggered
CHILD_IDS=$(curl --silent --header "PRIVATE-TOKEN: $TOKEN" \
  "$API/projects/$CI_PROJECT_ID/pipelines/$PARENT_ID/bridges" |
  jq -r '.[].downstream_pipeline.id')

bundle="{}"

for CHILD in $CHILD_IDS; do
  meta=$(curl --silent --header "PRIVATE-TOKEN: $TOKEN" \
    "$API/projects/$CI_PROJECT_ID/pipelines/$CHILD")
  project=$(echo "$meta" | jq -r '.project_id')

  curl --silent --header "PRIVATE-TOKEN: $TOKEN" \
    "$API/projects/$project/jobs/artifacts/main/raw/child-evidence.json?job=emit-evidence" \
    -o "child-$CHILD.json"

  service=$(jq -r '.service' "child-$CHILD.json")
  bundle=$(echo "$bundle" | jq \
    --slurpfile child "child-$CHILD.json" \
    --arg svc "$service" \
    '.[$svc] = $child[0]')
done

bundle=$(echo "$bundle" | jq \
  --arg pipeline "$PARENT_ID" \
  --arg actor "$GITLAB_USER_LOGIN" \
  --arg env "$HIPAA_ENVIRONMENT" \
  --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  '. + {parent_pipeline_id: $pipeline, actor: $actor, environment: $env, timestamp: $ts}')

echo "$bundle" > evidence-bundle.json

The script is intentionally readable. Forty lines an auditor can walk in five minutes. Every API call uses a scoped token that can only read pipeline metadata and job artifacts; the parent cannot modify anything in the child repos. The output bundle is the input to OPA, and it's also what gets written to the evidence bucket with Object Lock. The chain of custody is queryable months later: parent pipeline ID joins to actor, joins to artifact digest, joins to scanner results, joins to deploy outcome.

Section 05 — Multi-project pipelines for a five-repo polyrepo

The team this pattern came from split their code across five repos: backend, frontend, infrastructure (Terraform), networking (VPC / firewall as code), and security (IAM, KMS, policy bundles). The split matched their team boundaries. The compliance constraint was that every deploy to production had to evaluate evidence from every repo, in the same run, before the gate opened.

Multi-project pipelines handle this cleanly. The parent in compliance-platform triggers a child in each of the five repos via trigger: project:. With strategy: depend, the parent waits for every child to complete before moving to evidence aggregation. The five children run in parallel; the slowest determines the total wait.

Three behaviors of multi-project triggers matter for HIPAA:

Token scope. The trigger uses a CI job token from the parent. The downstream repo's CI/CD settings explicitly list which repos can trigger pipelines via job token. A repo outside that allow-list cannot trigger.
Branch pinning. The parent triggers branch: main on each child. A feature branch on a child cannot be triggered from the production parent pipeline. The child can be tested independently on feature branches; production deploys always come from main.
Artifact passthrough. Artifacts from child pipelines are reachable via the GitLab API using the parent's scoped read token. The parent does not need write access to any child repo; it only needs to read artifacts.

A small note on the monorepo-vs-polyrepo question. For healthcare teams under 30 engineers, my default is monorepo plus include:. The polyrepo split makes sense when the team boundaries are firm, code review ownership is genuinely separable, and each repo is large enough on its own that combining them slows everyone down. The team in this engagement was past that threshold; their five repos already existed for organizational reasons unrelated to CI. The parent/child pattern works either way. Don't split repos to support the pattern; the pattern supports whichever split you already have.

Section 06 — Compliance runner tags as a deploy boundary

GitLab self-hosted runners register with one or more tags. The pipeline declares which tags it needs. GitLab routes the job to a runner whose tags match. The tag becomes a structural compliance control because the alternative requires an admin to register a new runner.

Three runner pools in this engagement:

hipaa-build-runner handles every child pipeline job: build, test, scan, sign, emit. Read-only access to the artifact registry; no production IAM.
hipaa-evidence-runner handles the parent's evidence aggregation and policy gate. Read access to the GitLab API and write access to the evidence bucket. No deploy permissions.
hipaa-prod-runner handles only the deploy stage. Has the production IAM role bound via Workload Identity. Used only when the policy gate has already allowed and a named approver has clicked.

# /etc/gitlab-runner/config.toml on the prod-only runner host

[[runners]]
  name = "hipaa-prod-runner-01"
  url = "https://gitlab.com/"
  token = "REDACTED"
  executor = "kubernetes"

  [runners.kubernetes]
    namespace = "gitlab-runners-prod"
    service_account = "hipaa-prod-runner-sa"
    image = "registry.example.com/runner-images/hipaa:v1.4.2"
    pull_policy = "always"
    [runners.kubernetes.node_selector]
      "stonebridge.io/runner-pool" = "hipaa-prod"
    [[runners.kubernetes.volumes.secret]]
      name = "hipaa-prod-kms-rolebinding"
      mount_path = "/etc/runner/kms"
      read_only = true

The runner image is signed and version-pinned. The pod runs on a tainted node pool that only accepts pods tolerating the runner taint. The runner's pod service account is bound to a GCP service account via Workload Identity; the GCP SA can deploy to the prod GKE cluster and nothing else.

The combined effect: a job in the parent that declares tags: ["hipaa-prod-runner"] can only land on this runner, which can only deploy to one cluster, which can only happen after the policy gate allowed. The pipeline YAML cannot lift its own privileges.

Section 07 — Where Argo CD comes in

The parent pipeline above triggers a deploy by calling kubectl directly. For most HIPAA engagements past a certain size, I move that deploy step to Argo CD with GitOps semantics. The parent pipeline writes a signed manifest update to a config repo; Argo CD reconciles the cluster against the config repo; the deploy event lands in Argo CD's audit log as well as the parent's evidence bundle.

The HIPAA-relevant property is that the running cluster state is continuously verified against the config repo, not just at deploy time. Drift detection becomes a control rather than a periodic check.

I'll cover the Argo CD side in depth in upcoming Kubernetes platform engineering posts. For the parent/child architecture, what matters is that the deploy stage's interface stays the same: the parent emits a signed deploy event, the evidence bundle records it, and downstream consumers can reconcile.

Section 08 — What the rebuild looked like at the 32-host platform

The team I opened with had 32 production VM-backed services on GCP, a 1,200-line monorepo pipeline, and five weeks before their 3PAO assessment. Their compliance officer wanted to know which hosts complied with the required baseline (Tomcat 9.0.62+, Node.js 18+, Ubuntu 20.04+). They had not had the cycles to walk every host.

We split the engagement in two. Track one was the host inventory: an Ansible plus Python tool that connected to each VM through GCP Identity-Aware Proxy, scraped the running versions, and produced a compliance matrix. The compliance team had the inventory inside a week. Track two was the pipeline rebuild.

The pipeline rebuild took four weeks. We split the 1,200-line file into a 60-line parent in a new compliance-platform repo and five children in their existing service repos (backend, frontend, infrastructure, networking, security). The polyrepo split predated us; the team had organized along those lines a year earlier for code review reasons. The parent/child pattern took advantage of the split instead of fighting it.

Three structural changes carried the audit:

The parent owns the gates. Identity verification, evidence aggregation, OPA policy, deploy authorization. The compliance team approves merges to this repo. Service teams have no write access.
Children own their service. Build, test, scan, sign, emit. Service teams have full control. Changes to the child pipeline don't risk dropping a compliance gate because the gates live in the parent.
Three runner pools with scoped IAM. The build runner has no production IAM. The evidence runner has no deploy IAM. The prod runner has no read access to other clusters. A dev pipeline cannot reach production via any path.

The audit cleared on first-party review. The next quarterly internal review passed without remediation work because the architecture made future regressions structurally difficult. The 32-host inventory tool became part of the compliance team's continuous monitoring practice. The pipeline rebuild was the lasting change.

The same pattern is what we recommend on every GitLab-based HIPAA engagement now, regardless of cloud. The shape stays constant; the runner infrastructure and the deploy target swap by cloud.

Section 09 — Tooling recommendations

Opinionated picks for GitLab on HIPAA. The architecture matters more than the tool.

Layer	Recommended	Acceptable	Avoid
Pipeline structure	Parent in compliance repo, children in service repos	Parent + children in same monorepo via `include:`	Single thousand-line `.gitlab-ci.yml`
Cross-repo orchestration	`trigger: project:` with `strategy: depend`	Pipeline scheduling via API	Cron jobs that hope children are fresh
Artifact contract	Structured `reports:` (container_scanning, sast, dotenv)	JSON artifacts collected via API	Logs scraped from job traces
Runner isolation	Three runner pools per environment, tag-enforced	Two pools (build, deploy) with scoped IAM	One shared runner pool with broad IAM
Policy gate	OPA in the parent, evidence bundle as input	Conftest in a required job	Slack notification, advisory only
Deploy	Argo CD pulling from config repo	`kubectl` in the prod runner	SSH and shell scripts
Evidence storage	GCS Bucket Lock or S3 Object Lock, 6-year retention	Versioned bucket with retention policy	GitLab artifact storage alone

Section 10 — Common mistakes to avoid

Five quick callouts. Each one shows up in real GitLab pipelines I'm called in to fix.

Thousand-line .gitlab-ci.yml. Refactor to parent/child before the file passes 500 lines. Past 1,000 it's an audit finding waiting to surface.
Children pinned to branch: main from the parent but no protection on main. If anyone can push to main on the child, the parent can be tricked into running unreviewed code. Branch protection on every child's main is non-negotiable.
Shared runner pool with broad IAM. Three pools per environment, scoped IAM, no exceptions. A build runner with prod IAM is the most common audit finding I see.
Artifact bundles assembled inline in YAML. Move the assembly to a versioned script in the compliance repo. The script is reviewable; inline YAML rotting over months is not.
The parent triggering children by branch name from the YAML. Hardcode main in the parent. A misconfigured pipeline shouldn't be able to point at an unreviewed branch.

The longer-form versions of these failure modes live in five patterns that fail HIPAA audits.

Section 11 — Conclusion

GitLab's parent/child primitives are the strongest any major CI platform offers for HIPAA work. The teams that use them well treat the boundary between parent and child as a compliance control, not a stylistic preference.

The parent owns the gates: identity verification, evidence aggregation, policy gating, deploy authorization. The compliance team owns the parent. The children own the services: build, test, scan, sign, emit. Service teams own each child. The artifact contract between them is the only interface. Tag-scoped runners make the deploy boundary structural; multi-project triggers handle polyrepo splits without compromising the gates.

Build the pipeline this way and the auditor's questions become queries against the evidence bundle. Build it the other way and you spend the next assessment cycle rebuilding what you should have built once.

If you're running GitLab in a HIPAA environment: Stonebridge runs two-week HIPAA CI/CD audits that map your existing GitLab pipeline against the Security Rule and produce a written remediation roadmap. Fixed fee, founder-led, the report holds up under first-party review by your auditor.

Keep reading: the broader architecture pattern across CI platforms is in the HIPAA CI/CD implementation guide. The parallel post for teams on GitHub Actions is GitHub Actions for HIPAA-compliant deployments. The pre-audit walkthrough of every Security Rule control is in the HIPAA CI/CD audit checklist.

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.

GitHub Actions for HIPAA-compliant deployments

Stonebridge Tech Solutions LLC — Thu, 21 May 2026 20:39:25 +0000

OIDC trust scope, self-hosted runner discipline, reusable workflows as the compliance contract.

Most "GitHub Actions for HIPAA" content reads like generic CI security with HIPAA labels pasted on top. This one is platform-specific.

A healthcare SaaS team I worked with earlier this year had six weeks to make their GitHub Actions pipeline audit-ready. They were a clinical workflow platform on AWS, four squads, roughly 90 active workflow files spread across a primary application repo and three sibling repos for infrastructure, data, and integrations. They had passed SOC 2 Type II the prior year. They had just closed their first hospital system contract and the BAA addendum had landed on engineering with a familiar one-line note from legal: "should be fine."

It wasn't fine. Their GitHub Actions pipeline was clean by SOC 2 standards. By HIPAA standards the auditor could ask three questions that the pipeline couldn't answer in seconds. Which named human approved this production deploy? Which signing key produced the artifact running in the prod cluster? What happens if a critical CVE shows up during a deploy? None of those answers were structurally encoded in the workflows. They were tribal knowledge spread across Slack and a shared Notion page.

Three GitHub-specific decisions separate a HIPAA-aligned GitHub Actions pipeline from a SOC 2 one. The OIDC trust scope. The runner labeling discipline. The reusable workflow boundary as the compliance contract. The rest of this post is each of those, with the AWS code that makes them work, plus the policy gate that ties them together.

If you've read the broader HIPAA CI/CD implementation guide, this is the GitHub Actions-specific deep dive on the same architectural pattern. The parent/child concept ports cleanly; GitHub calls it reusable workflows. The runner isolation pattern ports cleanly; GitHub calls it self-hosted runner labels. The cloud examples here cover AWS specifically because that is where most US healthcare SaaS GitHub Actions deployments live.

Section 01 — What HIPAA actually needs from a GitHub Actions pipeline

HIPAA's Security Rule doesn't mention GitHub Actions. It also doesn't mention pipelines. It specifies safeguards. A correctly built GitHub Actions pipeline satisfies those safeguards continuously, instead of producing them as quarterly evidence runs before audit windows.

Five controls touch the pipeline most directly. The wording matters; auditors quote the regulation back at you, not the vendor checklist.

§ 164.308(a)(5)(ii)(C) Log-in monitoring. Every deployment is attributable to an authenticated identity with audited access. GitHub Actions translates this to OIDC tokens issued to specific workflow paths, not long-lived secrets in repository settings.
§ 164.308(a)(8) Periodic evaluation. Security evaluations happen on every change. Scanners and policy evaluations run on every push, not on a cron the platform team forgets to maintain.
§ 164.312(b) Audit controls. The pipeline records who deployed what, when, against which approval chain. GitHub's workflow_run history is not the audit log; it's a UI on top of one. The HIPAA audit log lives in S3 with Object Lock.
§ 164.312(c)(1) Integrity controls. Artifacts are signed, signatures are verified before deployment, and tampering is structurally detectable. Cosign signing inside a reusable workflow that the application repo cannot override.
§ 164.312(e)(1) Transmission security. Deploys to PHI-bearing environments use mutually authenticated, encrypted channels. No bearer tokens to production, no plain HTTP anywhere on the path.

None of these are exotic. All of them are routinely missed in pipelines built without HIPAA in mind from day one. The framing that helps most: HIPAA tells you what evidence the pipeline must produce. Once you accept that, the architecture follows. The full control mapping at the pillar page covers each Security Rule section against a specific pipeline touchpoint.

Section 02 — Three GitHub-specific gaps

The architecture maps cleanly across CI platforms. The gaps don't. Three places GitHub Actions makes HIPAA harder than GitLab or Argo CD, and what to do about each.

OIDC trust scope. The default GitHub OIDC subject claim is repo:org/name:ref:refs/heads/main or similar. The default sample IAM trust policy that everyone copies trusts the entire org. A misconfigured trust policy gives any workflow in your org a credential path to production. Scope the trust to a specific repo, a specific workflow file, and a specific environment.

Runner labels as the only deploy boundary. Self-hosted runners are addressed by label. There is no platform-enforced separation between a runner labeled prod and a runner labeled prod-staging if both are registered to the same org. The compliance boundary is the label, plus the runner's IAM trust, plus the workflow's runs-on: clause. Get any one of those wrong and a dev pipeline can target a prod runner.

Reusable workflow drift. Reusable workflows (workflow_call) are the GitHub-native parent/child pattern. They work well. The drift mode is teams write reusable workflows, then let application repos copy the YAML inline "just this once" because the reusable workflow doesn't yet support some new step. After three of those, the compliance contract has rotted. Lock the reusable workflow into a repo the application teams cannot write to.

Each of these has a fix. The next three sections walk them with code.

Section 03 — OIDC federation, scoped to one workflow

OIDC federation between GitHub Actions and AWS removes the entire category of long-lived credentials in repository secrets. No more AWS_ACCESS_KEY_ID rotated quarterly by a developer who remembers. The runner exchanges its GitHub-issued JWT for an STS session every time the workflow runs. The session is short-lived, attributable, and audit-logged in CloudTrail with the workflow identity intact.

The trust policy is the load-bearing piece. Most sample policies you'll find trust the entire org, which is too broad for HIPAA. The auditor will look at the trust policy and ask "what stops a dev branch from assuming this role?" The honest answer needs to be a StringEquals on the subject claim, scoped to one repo, one workflow file, and one environment.

# Terraform: HIPAA-aligned GitHub OIDC trust for AWS

# One OIDC provider per AWS account. Hosted by GitHub; the
# thumbprint changes rarely. Keep this in the security account.
resource "aws_iam_openid_connect_provider" "github" {
  url             = "https://token.actions.githubusercontent.com"
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]
}

# Production deploy role. Scoped to ONE repo, ONE workflow file,
# ONE environment. A dev branch cannot assume this role no matter
# what YAML it writes.
resource "aws_iam_role" "hipaa_prod_deploy" {
  name = "hipaa-prod-deploy"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = aws_iam_openid_connect_provider.github.arn
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
          # Subject is the load-bearing scope. Pin to:
          #   - exact repo
          #   - exact environment (GitHub environment, not branch)
          # No wildcards. A wildcard here is the audit finding.
          "token.actions.githubusercontent.com:sub" =
            "repo:hipaa-app-org/clinical-platform:environment:production"
        }
        StringLike = {
          # Belt and suspenders: explicit job_workflow_ref check
          "token.actions.githubusercontent.com:job_workflow_ref" =
            "hipaa-app-org/compliance-workflows/.github/workflows/deploy-prod.yml@refs/tags/v*"
        }
      }
    }]
  })
}

The two pieces that matter. First, the subject claim pins the role to a single repo and a single GitHub environment (which is itself behind required reviewers; we'll get to that). Second, the job_workflow_ref condition pins to a specific tagged version of a reusable workflow living in a separate compliance-workflows repo. That second condition is what stops a developer from writing inline deploy steps in the application repo and bypassing the reusable workflow.

The workflow side is short. The role assumption happens once per job, with no static credentials anywhere:

# .github/workflows/deploy-prod.yml (excerpt)
# Lives in the compliance-workflows repo, pinned by tag in the
# application repo's caller workflow. Application teams cannot
# modify this file.

name: HIPAA production deploy
on:
  workflow_call:
    inputs:
      image_digest: { type: string, required: true }
      target_cluster: { type: string, required: true }

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: [self-hosted, hipaa-prod, linux, x64]
    environment: production
    steps:
      - name: Assume scoped prod role
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/hipaa-prod-deploy
          aws-region: us-east-1
          role-session-name: gha-${{ github.run_id }}

      - name: Verify image signature
        run: |
          cosign verify \
            --certificate-identity-regexp \
              "https://github.com/hipaa-app-org/compliance-workflows/.github/workflows/build-sign.yml@.*" \
            --certificate-oidc-issuer https://token.actions.githubusercontent.com \
            ${{ inputs.image_digest }}

      - name: Deploy by digest, not tag
        run: |
          aws eks update-kubeconfig --name ${{ inputs.target_cluster }}
          kubectl set image deployment/hipaa-app \
            hipaa-app=${{ inputs.image_digest }}

The deploy uses the image digest, not the tag, so a race between tag-and-deploy can't substitute a different image. The cosign verification is keyless, using Sigstore's Fulcio identity tied to the building workflow's OIDC subject. The certificate identity regex restricts trusted signers to the compliance-workflows repo's build workflow. A signature from any other workflow fails verification.

Section 04 — Self-hosted runners on hardened infrastructure

Take the strong position here: GitHub-hosted runners are not appropriate for the deploy stage of a HIPAA pipeline. They're acceptable for build and scan, where no production credentials are in play. They are not acceptable for the job that holds the production OIDC role.

The reasoning isn't about GitHub's security posture. It's about evidence shape. A GitHub-hosted runner is shared infrastructure outside your BAA scope. CloudTrail records the AWS API calls. CloudTrail does not record what else ran on that runner in the same job. The host is ephemeral, the logs are GitHub's, the network egress is GitHub's. If an auditor asks "show me that the runner that performed this deploy was within your BAA-covered infrastructure," you have no answer for GitHub-hosted.

For PHI-touching deploys, run on self-hosted runners in your own AWS account, on EKS, with IRSA scoping the runner pods to specific IAM roles. The runner labels become the deploy boundary. The runs-on: clause in the workflow becomes the contract that says "this job runs only on a runner labeled hipaa-prod, which only exists in the prod runner pool."

# Terraform: HIPAA prod runner pool on EKS

resource "aws_eks_node_group" "hipaa_prod_runners" {
  cluster_name    = aws_eks_cluster.hipaa.name
  node_group_name = "hipaa-prod-runners"
  node_role_arn   = aws_iam_role.runner_node.arn
  subnet_ids      = var.private_subnet_ids

  scaling_config {
    desired_size = 2
    min_size     = 2
    max_size     = 6
  }

  # Taints keep general workloads off the runner pool
  taint {
    key    = "workload"
    value  = "hipaa-runner"
    effect = "NO_SCHEDULE"
  }

  labels = {
    "stonebridge.io/runner-pool" = "hipaa-prod"
  }

  ami_type = "BOTTLEROCKET_x86_64"

  tags = {
    Compliance = "HIPAA"
    Boundary   = "production"
  }
}

# IRSA: the runner pod's SA can assume a runner role.
# The runner role can in turn assume the deploy role,
# but only from this specific namespace + SA.
resource "aws_iam_role" "runner_irsa" {
  name = "hipaa-prod-runner-irsa"

  assume_role_policy = jsonencode({
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = aws_iam_openid_connect_provider.eks.arn
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "${replace(aws_iam_openid_connect_provider.eks.url, "https://", "")}:sub" =
            "system:serviceaccount:gha-runners:hipaa-prod-runner"
        }
      }
    }]
  })
}

Two things matter. The taint keeps general workloads off the runner pool, so the prod-runner host isn't co-tenanted with dev jobs. The IRSA trust policy scopes the runner pod's IAM to one namespace and one service account. A dev workflow that tries to schedule onto these nodes via a forged runs-on: value fails because the dev runner pool has a different label and a different IRSA chain.

The runner registration itself is gated at the GitHub org level: in Org Settings → Actions → Runner groups, the hipaa-prod runner group is restricted to a specific GitHub team's repos. A repo outside the team cannot target the label even if a developer reads it from a Slack screenshot and tries.

Section 05 — Reusable workflows as the compliance contract

Reusable workflows are GitHub's native parent/child pattern. The application repo's caller workflow handles build-time decisions; the reusable workflow in compliance-workflows handles every compliance-relevant step: signing, scanning, evidence emission, deploy.

The compliance contract is the input shape. The reusable workflow defines exactly which inputs it accepts. The caller workflow provides them. Anything else, including any inline shell that wants to bypass a gate, is structurally invisible to the reusable workflow.

# Caller in the application repo: .github/workflows/release.yml
# Application teams own this file. They cannot bypass the gates;
# the gates live in the reusable workflow they invoke.

name: Release to prod

on:
  push:
    tags: ['v*.*.*']

jobs:
  build_and_sign:
    uses: hipaa-app-org/compliance-workflows/.github/workflows/build-sign.yml@v3.2.1
    permissions:
      id-token: write
      contents: read
      packages: write
    secrets: inherit

  deploy_prod:
    needs: build_and_sign
    uses: hipaa-app-org/compliance-workflows/.github/workflows/deploy-prod.yml@v3.2.1
    with:
      image_digest: ${{ needs.build_and_sign.outputs.image_digest }}
      target_cluster: hipaa-prod-east
    permissions:
      id-token: write
      contents: read
    secrets: inherit

The reusable workflow is in a separate repo with branch protection: the compliance team approves every merge, the application teams have no write access. Tagged versions are immutable. The application repo pins by tag (@v3.2.1), not by branch (@main). Pinning by tag is the audit-grade choice; pinning by branch is how reusable workflows drift out of compliance after they were originally written correctly.

Two organization-level controls hold this together. First, an organization ruleset that requires all production deploys to use workflows from the compliance-workflows repo, enforced by the required_workflows policy. Second, the OIDC trust policy from Section 03 pins to the job_workflow_ref of the compliance-workflows file. Even if a developer copies the workflow inline and removes the uses: reference, the role assumption fails.

Section 06 — Environment protection and required reviewers

GitHub environments are the platform-native approval gate. They're underused outside enterprise accounts, but they're the cleanest way to satisfy § 164.308(a)(1)(ii)(B) sanction enforcement and § 164.308(a)(4) information access management.

Three settings on the production environment carry the compliance weight:

Required reviewers from a separate team. The approver cannot be the deploy author. The HIPAA Security Rule wants a separation of duties; a self-approved deploy fails audit.
Wait timer of 5 to 15 minutes. A minimum delay between approval and execution gives the platform team a chance to catch a click that shouldn't have happened. For PHI-bearing deploys, the cost of the delay is trivial; the cost of a misclick is not.
Deployment branch restrictions. Production deploys allowed only from refs/tags/v*. A main branch push, even one that built successfully, cannot deploy to production without a tag. The tag is a positive action with provenance.

# Terraform: GitHub environment protection for production

resource "github_repository_environment" "production" {
  repository  = "clinical-platform"
  environment = "production"

  reviewers {
    teams = [data.github_team.hipaa_approvers.id]
    # Important: empty users list. Approvers via team only,
    # so adds/removes flow through team membership audit.
  }

  wait_timer = 10

  deployment_branch_policy {
    protected_branches     = false
    custom_branch_policies = true
  }
}

resource "github_repository_environment_deployment_policy" "prod_tags" {
  repository  = "clinical-platform"
  environment = github_repository_environment.production.environment
  tag_pattern = "v*.*.*"
}

Belt-and-suspenders: the reviewer is a team, not a list of named users. Team membership is itself an audit artifact in GitHub's audit log, with adds and removals attributed to whoever performed them. The quarterly access review walks the team membership history and confirms it matches the current authorized list.

Section 07 — The policy gate that ties it together

Everything above is GitHub-native. The last piece is platform-agnostic: an OPA policy that evaluates the evidence bundle and returns allow or deny before the deploy job runs.

The policy receives a JSON document containing the signature attestation, the scanner outputs, the approver identity, and the target environment. It returns a boolean. The deploy job's first step is the policy check; if it returns deny, the job exits non-zero and the deploy never happens. The signature, the scans, and the approval all have to be valid for the policy to allow.

# policies/github_deploy.rego
# Policy gate for HIPAA GitHub Actions production deploys.

package deploy.hipaa

import future.keywords.if
import future.keywords.in

default allow := false

allow if {
    scans_passed
    signature_valid
    approver_authorized
    workflow_ref_pinned
}

scans_passed if {
    input.scans.container.timestamp_ns > time.now_ns() - 3600 * 1e9
    input.scans.sast.timestamp_ns      > time.now_ns() - 3600 * 1e9
    input.scans.container.critical == 0
    input.scans.sast.critical      == 0
    input.scans.secrets.findings   == 0
}

signature_valid if {
    input.artifact.cosign_verified == true
    startswith(
        input.artifact.signed_by,
        "https://github.com/hipaa-app-org/compliance-workflows/",
    )
}

approver_authorized if {
    input.approver != input.deploy_author
    input.approver in data.approvers.production
}

workflow_ref_pinned if {
    regex.match(
        `compliance-workflows/.github/workflows/.*\.yml@refs/tags/v\d+\.\d+\.\d+$`,
        input.workflow_ref,
    )
}

deny[msg] if {
    not workflow_ref_pinned
    msg := sprintf(
        "workflow_ref %v is not pinned to a semver tag (HIPAA § 164.312(c)(1))",
        [input.workflow_ref],
    )
}

The policy is small on purpose. Forty lines that a third-party auditor can read in one sitting and a junior engineer can debug at 2am. Each condition is checkable, each is auditable, each fails closed. When the auditor asks "how do you stop a deploy if a scanner finds a critical CVE," the answer is a thirty-line Rego file plus the run log showing the deny message.

Section 08 — What this looked like at the 90-workflow team

Back to the clinical workflow platform from the lede. Six weeks, four engineers half-time on the engagement, 90 workflows down to the same compliance footprint via three changes.

Week one and two: stand up the compliance-workflows repo. Move the production deploy logic out of the application repo into a tagged reusable workflow. Pin the application repo's caller workflow at tag v1.0.0. Confirm OIDC federation works end-to-end against a temporary IAM role with broad permissions.

Week three: tighten the OIDC trust policy. Add the job_workflow_ref condition. Rotate the previous broad role out. The first time we tried this we broke a staging deploy because the staging caller workflow was pinned to @main instead of a tag; that surfaced the drift mode in real time and reinforced why pinning by tag is the discipline.

Week four: stand up the self-hosted runner pool on EKS. Move the deploy job's runs-on: from ubuntu-latest to [self-hosted, hipaa-prod]. Confirm the runner taints, the IRSA trust, and the org-level runner group restrictions all hold under attempts to deploy from a non-approved repo.

Week five: wire the OPA policy gate into the deploy workflow. Migrate the existing Slack-notification scanners to evidence-emitting scanners that write JSON into an S3 bucket with Object Lock. Add the cosign verification step. Add the environment protection rules in Terraform.

Week six: dry-run the 3PAO assessment internally. The platform lead walked the auditor's expected questions and answered each with a query. The audit cleared on first-party review two weeks later. More importantly, the same pipeline kept passing through the next quarterly internal review without remediation work.

The pattern is repeatable. Most healthcare SaaS teams I work with on GitHub Actions can hit this footprint in 4 to 8 weeks of focused effort, depending on how much existing inline workflow logic has to be migrated into the reusable workflow.

Section 09 — Tooling recommendations

Opinionated picks for GitHub Actions on HIPAA. Substitutions are fine; the architecture matters more than the tool.

Stage	Recommended	Acceptable	Avoid
Identity	OIDC federation, scoped to repo + environment	OIDC scoped to repo only	Long-lived access keys in repo secrets
Runner (build/scan)	GitHub-hosted (acceptable for non-PHI stages)	Self-hosted on EKS	Self-hosted on a developer laptop
Runner (deploy)	Self-hosted on EKS with IRSA, labeled per env	Self-hosted on EC2 with instance profile	GitHub-hosted for PHI-touching deploys
Workflow boundary	Reusable workflows in a separate repo, tag-pinned	Reusable workflows in the same repo, tag-pinned	Inline workflow logic, branch-pinned
Signing	Cosign keyless, Fulcio identity from compliance repo	Cosign with KMS-backed keys	Docker Content Trust (Notary v1)
Policy gate	OPA evaluated in a deploy job step, fails closed	Conftest in a separate job, required check	Slack notification, advisory only
Audit logs	S3 Object Lock in compliance mode, 6-year retention	CloudWatch Logs to a logging account, retention locked	GitHub Actions run history alone

Section 10 — Common mistakes to avoid

Five quick callouts from the field. Each fails audits more often than it should.

Org-wide OIDC trust policy. The default sample IAM trust trusts the entire org. Scope to repo + environment + workflow ref. A wildcard in the subject claim is an audit finding.
GitHub-hosted runners for the deploy job. Acceptable for build and scan. Not acceptable for the job that holds production credentials. Move PHI-touching deploys onto self-hosted runners in your BAA-covered infrastructure.
Reusable workflows pinned to @main. Tag-pin everything that touches production. Branch pinning is how compliance contracts rot over time without anyone noticing.
GitHub environment with Required reviewers: anyone with write access. The approver must be a separate team. Self-approval satisfies nothing.
CI run history as the audit log. GitHub rotates run history aggressively. The audit log lives in S3 with Object Lock, written by the workflow at the time the event occurs.

For longer-form versions of these failure modes against GitLab as well, the broader writeup on five patterns that fail HIPAA audits walks each.

Section 11 — Conclusion

The team that ships well on GitHub Actions in regulated environments isn't the one with the most YAML. It's the one whose workflows make compliance violations structurally difficult.

OIDC federation scoped to a single workflow file removes the credential-rotation problem and pins the trust to a verifiable subject. Self-hosted runners on hardened EKS infrastructure keep the deploy job inside your BAA scope and make the audit story crisp. Reusable workflows in a separate repo, tag-pinned and protected, are the compliance contract that application teams cannot bypass. An OPA policy gate evaluating evidence at the moment of deploy turns checklists into enforcement.

Build the GitHub Actions architecture this way and the platform's primitives carry the weight of the Security Rule. Build it the other way and you spend the next audit cycle rebuilding what you should have built once.

If you're working through this on a healthcare SaaS team: Stonebridge runs two-week HIPAA CI/CD audits that map your existing GitHub Actions setup against the Security Rule and produce a written remediation roadmap. Fixed fee, founder-led, the report holds up under first-party review by your auditor.

Keep reading: the broader architecture pattern across CI platforms is in the HIPAA CI/CD implementation guide. The pre-audit walkthrough of every Security Rule control is in the HIPAA CI/CD audit checklist. Where this pattern diverges for teams coming from SOC 2 is mapped in HIPAA CI/CD vs SOC 2 CI/CD.

About the author

This post originally appeared on Stonebridge Tech Solutions.

The HIPAA CI/CD audit checklist for engineering teams

Stonebridge Tech Solutions LLC — Tue, 19 May 2026 14:54:10 +0000

The practitioner's control map I use during 2-week audit engagements, with the CFR section, the auditor's question, and the architectural fix for each one.

A HIPAA CI/CD audit is not a paperwork exercise. The auditor will examine the pipeline and ask specific questions, and the architecture has to be able to answer them in seconds, not weeks.

A healthcare engineering team called me four weeks before their first 3PAO assessment. They had a CI/CD pipeline that shipped well. They had no idea whether it would survive scrutiny. Their compliance officer had sent them a checklist. Their auditor had sent a different checklist. The procurement reviewer at their largest customer had sent a third. None of the three agreed on what specifically the auditor would examine in the pipeline itself.

We pulled the latest production deploy log together. The pipeline ran. The deploy succeeded. But the deploy authorization was attributable to a CI service account, not a human. The signed artifact lived in a registry the engineering team could write to. The scanner results were stored as pipeline run artifacts that expired after 90 days. The HIPAA Security Rule asks for audit controls (§ 164.312(b)), integrity controls (§ 164.312(c)(1)), and access management (§ 164.308(a)(4)). The pipeline could not answer any of them.

The fix was architectural, not procedural. Over six weeks we rebuilt the pipeline so the auditor's questions could be answered in seconds. Signed artifacts with retention-locked evidence. Identity-attributable deploys. Continuous scanning with policy gates. Evidence stored separately from CI infrastructure. The assessment cleared on first-party review.

That engagement is also where this checklist comes from. It is the same control map I use during 2-week HIPAA CI/CD audits at Stonebridge, organized in the order I would actually walk a pipeline through it. Each control maps to a specific CFR section, the auditor's actual question, what passes, what fails, and the architectural fix. Use this before an audit. Use it during scoping when you do not know whether you have a problem. Use it as the basis for the remediation roadmap your compliance officer asks for.

01 — What this checklist is, and what it is not

This checklist covers the technical safeguards of the HIPAA Security Rule (45 CFR Part 164 Subpart C) as they apply specifically to the build, test, and deploy pipeline. The scope is the pipeline itself: source repositories, CI runners, registries, signing infrastructure, deployment targets, and the evidence the pipeline produces along the way.

It does not cover Business Associate Agreement management. It does not cover PHI access controls inside the running application. It does not cover workforce training, sanction policy, or the administrative safeguards required by § 164.308(a)(1) and § 164.308(a)(5). Those are real obligations, but they are not what your auditor will examine when they ask to see the pipeline.

It is also not a substitute for a real audit. A 2-week Stonebridge engagement produces a written control mapping, a prioritized remediation roadmap, and effort estimates. This checklist gets you to the point where you know what the engagement would surface. For deeper architectural context on the patterns referenced below, the HIPAA CI/CD implementation guide covers the parent/child pipeline architecture, isolated runners, and policy gates that satisfy most of these controls structurally.

02 — Pull evidence first. Then walk the controls.

The most common mistake teams make before a HIPAA CI/CD audit is trying to fix gaps before they know what the gaps are. I have watched engineering teams spend two weeks rebuilding their signing chain only to discover their bigger exposure was a logging account with read-only access for the wrong people.

Run the checklist in this order. Spend the first two hours pulling evidence onto a single shared document, then walk the controls with the evidence visible. Each control either has supporting evidence or it does not; trying to remember from memory whether something is configured correctly is how teams sign off on findings that fail under scrutiny.

The evidence pull at minimum:

Pipeline configuration files for every active branch (the entire .gitlab-ci.yml or .github/workflows/ tree)
The latest 30 days of pipeline run logs for production deploys
The most recent scanner outputs (SAST, SCA, container CVE, IaC, secrets) for the production branch
The signing chain: signing keys, key rotation history, signature verification logs
The current contents of the evidence bucket, including retention configuration
The IAM, RBAC, or equivalent identity grants for every account or principal that can deploy to a PHI-bearing environment
The CloudTrail, audit log, or equivalent showing the last 90 days of admin actions on production

With that on the table, the rest of the checklist becomes a query, not a memory test. The patterns below are organized by control family, not in the order the Security Rule presents them, because the practitioner walk is faster when you group by where the evidence lives. The architecture pattern I use emits this evidence as a property of how the pipeline runs, so the pull becomes a one-line query instead of a forensic exercise.

03 — Identity and access: who can deploy to PHI-bearing environments

This is the first thing auditors actually look at, and it is the most commonly broken in pipelines designed without compliance posture in mind. The relevant Security Rule sections are § 164.308(a)(3) (workforce security), § 164.308(a)(4) (information access management), and § 164.312(a)(1) (access control). All three reduce to the same engineering question: who, by named identity, can change production state.

§ 164.308(a)(4) · Information access management

Deploy authorization is attributable to a named human identity.

"Show me, by named identity, every human who has deployed to production in the last 90 days."

Passes: Federated identity from corporate IdP (Okta, Entra ID, IAM Identity Center) to CI. Every deploy runs under a role assumed by a named human via SSO with phishing-resistant MFA. The deploy event log shows the human, the timestamp, and the role assumed.

Fails: Long-lived CI service account credentials. Shared "deploy" tokens passed in environment variables. Deploy keys checked into a vault any developer can read. "The pipeline did it" is not a name.

Fix: OIDC federation between CI and cloud (GitHub OIDC to AWS, Workload Identity Federation for GCP). Short-lived role assumption per pipeline run. Named-human approval required at the production gate, recorded with identity and timestamp.

§ 164.308(a)(3) · Workforce security

Access grants and revocations are auditable and time-bounded.

"Show me when this developer was granted production access and when it was revoked."

Passes: Access is granted through the IdP with a documented approval workflow. Time-bounded role assumption (hours, not days). Quarterly access reviews logged. Revocation propagates from IdP through CI within minutes.

Fails: Permissions held directly in CI (GitHub repo collaborator, GitLab project member) without IdP gating. No record of when someone was granted access. Revocation requires a person to remember to remove the user.

Fix: IdP groups gate all CI access. Group membership is the source of truth. Access reviews run quarterly, output flows to the central log account.

§ 164.312(a)(1) · Access control

Phishing-resistant MFA is enforced at the deploy gate.

"Show me the MFA challenge for this production deploy."

Passes: WebAuthn or FIDO2 enforced at the IdP for any session that can trigger a production deploy. SMS-based or app-based MFA is not sufficient for production-PHI paths. The MFA event is logged with the same identity that appears on the deploy.

Fails: SMS MFA only. MFA at IdP login but no re-challenge for high-risk actions. Service accounts bypassing MFA via static tokens.

Fix: Phishing-resistant MFA enforced at IdP. Step-up authentication required for any role that can write to a PHI-bearing environment. Log the auth event in the same store that holds deploy events so the auditor can join them on identity and time.

The structural pattern underneath all three: no human credential survives longer than the pipeline run that uses it. Every action is attributable to a named identity that exists in your corporate IdP. The CI system is downstream of identity, not a parallel identity store.

04 — Audit logging: every deploy emits tamper-evident evidence

HIPAA § 164.312(b) is one of the few Security Rule sections that names the requirement directly: "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." For a pipeline, that means every deploy event, every signature verification, every policy decision, and every access grant lands in a log that engineers cannot edit.

§ 164.312(b) · Audit controls

Logs are centralized in an account engineers cannot write to.

"Show me the deploy event for this production release, with the approver identity and timestamp."

Passes: A dedicated logging account (AWS), project (GCP), or subscription (Azure) with S3 Object Lock or equivalent retention lock. Production accounts write logs; nobody in production can read or delete them. CloudTrail organization trail captures every admin action with the assumed-role chain intact.

Fails: Pipeline logs only in the CI run output, expiring after 30-90 days. Logs in the same account where deploys happen. CloudTrail enabled but writable by the same role that performs deploys. "We ship to Datadog" with no retention policy mapped to the regulation.

Fix: Centralized logging account with S3 Object Lock in compliance mode, retention configured to your HIPAA retention requirement (typically 6 years for documents under § 164.316(b)(2), longer in practice). Cross-account replication is one-way: production writes, logging stores, nobody deletes.

§ 164.312(b) · Audit controls

Every deploy is queryable by identity, environment, and artifact hash.

"Show me every production deploy this user made in Q1, and the SHA-256 of the artifact deployed."

Passes: Pipeline emits a structured deploy event on every run: who, when, what (artifact digest), where (environment), why (change ticket reference). The event lands in the logging account with the same retention as access logs. The auditor can answer the query above with one SQL or Athena query.

Fails: Deploy history lives in the CI tool only (GitLab pipelines, GitHub Actions runs). Artifact hashes are not recorded against the deploy event. Answering the query requires correlating five systems and a Slack search.

Fix: Pipeline writes a structured deploy event to the logging account at the moment of cutover. Schema: deploy_id, timestamp, actor_identity, environment, artifact_digest, change_ticket, approval_chain. Treat it as a first-class output of the pipeline, not telemetry.

05 — Integrity controls: every artifact deployed has a signature you can verify

§ 164.312(c)(1) requires "policies and procedures to protect electronic protected health information from improper alteration or destruction." For pipelines, that is the supply chain: from the source commit to the running container, you have to be able to demonstrate that what is in production is what was reviewed and approved.

I recommend Cosign for signing container images. The Sigstore ecosystem has matured to the point where Cosign integrates with KMS-backed signing keys natively, and the verification policy lives in admission control where it can fail closed. Do not use Docker Content Trust for new HIPAA pipelines. Notary v1 is effectively unmaintained, and the verification story does not survive auditor questioning.

§ 164.312(c)(1) · Integrity

Container images are signed before deploy and verified on admission.

"Show me the signature for this container, the key used to sign it, and the admission decision that allowed it into production."

Passes: Cosign or equivalent signs every image at build time using a KMS-backed key. The cluster admission controller (Kyverno or OPA Gatekeeper) verifies the signature against the trusted public key. Unsigned or improperly-signed images are rejected at admission, the rejection logged.

Fails: Images deployed without signature verification. Signing keys held in a developer's keyring or in plaintext in the CI environment. Signature checks performed in CI but not enforced at the cluster.

Fix: Cosign signing at build with a KMS-stored key. Kyverno admission policy enforcing verification at the cluster. Drift detection comparing running images against the signed-and-approved list.

The admission policy itself is short and worth showing. This is the Kyverno-equivalent pattern in OPA Rego, derivative from public Sigstore examples and Stonebridge's reference patterns:

# File: policies/hipaa/admission/signed_images.rego
# Enforces signed-image admission for any pod entering a PHI-bearing namespace.
# Maps to 45 CFR § 164.312(c)(1) integrity controls and § 164.308(a)(4)
# information access management for production-PHI workloads.

package kubernetes.admission

import future.keywords.if
import future.keywords.in

# Namespaces that hold PHI workloads. The deny list is explicit so a
# misconfigured namespace cannot accidentally accept unsigned images.
phi_namespaces := {"prod-phi", "staging-phi", "validation-phi"}

# Public keys we trust. In production these live in a ConfigMap mounted
# at runtime, sourced from KMS public key endpoints.
trusted_keys := {
  "cosign-prod-key-2026": "-----BEGIN PUBLIC KEY-----...",
  "cosign-prod-key-2025-rotation": "-----BEGIN PUBLIC KEY-----...",
}

# Hard deny: any image in a PHI namespace without a verified signature
# from a trusted key fails admission. The reason string lands in the
# audit log so the rejection is queryable.
deny[msg] if {
  input.request.namespace in phi_namespaces
  some container in input.request.object.spec.containers
  not image_signed_by_trusted_key(container.image)
  msg := sprintf("HIPAA integrity violation: image %v not signed by trusted key in namespace %v (45 CFR 164.312(c)(1))", [container.image, input.request.namespace])
}

# Soft warning: even non-PHI namespaces should reject unsigned images.
# A warning lets the platform team see drift without breaking dev.
warn[msg] if {
  not input.request.namespace in phi_namespaces
  some container in input.request.object.spec.containers
  not image_signed_by_trusted_key(container.image)
  msg := sprintf("Unsigned image %v in non-PHI namespace %v. Cluster baseline requires signatures.", [container.image, input.request.namespace])
}

# Helper: returns true if any trusted key verified the image signature.
# The actual verification happens in a sidecar that pre-populates the
# image annotations with verification results. This keeps Rego pure.
image_signed_by_trusted_key(image) if {
  annotation := input.request.object.metadata.annotations[sprintf("cosign.verified/%v", [image])]
  annotation.verified == true
  annotation.key_id in object.keys(trusted_keys)
}

The policy fails closed. A PHI-bearing namespace will not accept an unsigned image, period. The denial message includes the CFR citation so when the auditor pulls the admission log, the regulatory mapping is already in the record. The longer write-up of the parent-child pipeline architecture that produces signed artifacts in the first place is in the HIPAA CI/CD implementation guide.

06 — Transmission security: modern TLS, mutually authenticated where it matters

§ 164.312(e)(1) requires safeguards against unauthorized access during transmission. For pipelines, the relevant transmission paths are the CI-to-registry path, the registry-to-cluster path, the cluster-to-PHI-database path, and the deploy-evidence-to-logging-account path. Each needs encryption in transit; the PHI-bearing paths need mutual authentication.

§ 164.312(e)(1) · Transmission security

Encrypted transit for every PHI-bearing path, with mutual auth where the threat model warrants.

"Show me the TLS configuration for the path between the pipeline and the production database. Which ciphers are accepted? Is the client authenticated?"

Passes: TLS 1.2 minimum, TLS 1.3 preferred. Modern cipher suites only. Mutual TLS (mTLS) on internal PHI-bearing service-to-service calls, typically via a service mesh (Istio, Linkerd) or platform-native (AWS App Mesh, GCP Cloud Service Mesh). Private connectivity (PrivateLink, Private Service Connect) where cross-network paths exist.

Fails: TLS 1.0 or 1.1 still accepted on any PHI-touching endpoint. Plain-HTTP internal calls. Service-to-service auth via bearer tokens with no transport-level identity. Network ACLs treated as the encryption layer.

Fix: Enforce TLS 1.2+ at every load balancer. Adopt a service mesh for internal mTLS. Use private connectivity for cross-VPC PHI paths. Run a scheduled scanner against your endpoints (sslyze, testssl.sh) and ship the report to the evidence bucket.

07 — Continuous evaluation: scanners as policy gates, not as advisory notifications

§ 164.308(a)(8) requires periodic technical evaluation of the security posture. The way that maps to pipelines is straightforward: scanners run on every change, the results gate deploys, and the findings flow into the evidence trail. Auditors will look for five scanner types in a HIPAA pipeline. Each maps to a category of risk; missing any one is a finding.

Scanner type	Recommended tool	What it catches	Maps to
SAST	Semgrep, CodeQL	Source-code vulnerabilities in your application	§ 164.308(a)(8)
SCA	OSV-Scanner, Snyk	Known CVEs in third-party dependencies	§ 164.308(a)(8), § 164.312(c)(1)
Container CVE	Trivy, Grype	Vulnerable OS packages and libraries in container images	§ 164.308(a)(8)
IaC	tfsec, Checkov	Misconfigured cloud resources, public buckets, open security groups	§ 164.312(a)(1), § 164.312(e)(1)
Secrets	Gitleaks, TruffleHog	Hardcoded credentials, API keys, tokens in source	§ 164.308(a)(4)

The crucial structural detail: scanners are policy gates, not advisory notifications. A CVE result that sends a Slack message and lets the deploy proceed is not a control. The gate has to fail closed. The pattern looks like this in GitHub Actions, derivative from public open-source patterns:

# File: .github/workflows/hipaa-build.yml
# Build, scan, and gate. Every scanner is a policy gate, not a notification.
# Maps to 45 CFR § 164.308(a)(8) continuous evaluation and § 164.312(c)(1)
# integrity. Failed gates block deploys; results emit to the evidence bucket.

name: HIPAA pipeline

on:
  push:
    branches: [main]

jobs:
  scan:
    runs-on: self-hosted-hipaa-baseline   # Hardened, network-isolated runner
    steps:
      - uses: actions/checkout@v4

      - name: SAST (Semgrep)
        run: semgrep --config p/hipaa --error --json > sast.json

      - name: SCA (OSV-Scanner)
        run: osv-scanner --format json --output sca.json ./

      - name: Container CVE (Trivy)
        run: trivy image --severity HIGH,CRITICAL --exit-code 1 --format json --output trivy.json ${{ env.IMAGE }}

      - name: IaC (Checkov)
        run: checkov -d ./terraform --output json --output-file iac.json --soft-fail false

      - name: Secret scan (Gitleaks)
        run: gitleaks detect --no-git -v --report-format json --report-path secrets.json

      # Policy gate. Any HIGH/CRITICAL finding from any scanner blocks the
      # pipeline. The gate runs after every scanner so partial failures are
      # visible in the run log.
      - name: HIPAA policy gate
        run: |
          python3 .ci/policy_gate.py \
            --sast sast.json \
            --sca sca.json \
            --trivy trivy.json \
            --iac iac.json \
            --secrets secrets.json \
            --baseline hipaa-2026

      # Evidence emit. Every scanner output is signed and pushed to the
      # retention-locked evidence bucket. This is the artifact the auditor
      # will read, so the schema is stable and queryable.
      - name: Emit signed evidence
        run: |
          cosign attest --predicate sast.json     --type vuln $IMAGE
          cosign attest --predicate sca.json      --type vuln $IMAGE
          cosign attest --predicate trivy.json    --type vuln $IMAGE
          aws s3 cp ./*.json s3://hipaa-evidence-prod/pipeline-runs/${{ github.run_id }}/

Three things to notice. First, the runner itself is a hardened, network-isolated self-hosted runner. Public hosted runners reaching production PHI infrastructure is a finding on its own. Second, every scanner output is signed (Cosign attest) before being stored, so the evidence has its own integrity chain. Third, the policy gate is a script, not a YAML flag. The script encodes the baseline in version control, can be unit tested, and the failure conditions are auditable.

08 — Environment isolation: the runner that builds dev cannot reach prod

The single biggest pipeline-level finding I see in HIPAA-environment audits is runners that can reach environments they should not. A pipeline runner with credentials for production, used to build a dev branch, is the textbook example of why the network and identity layers have to be scoped per environment.

§ 164.308(a)(4), § 164.312(a)(1)

Per-environment runners with scoped IAM and explicit egress.

"Show me which runner deployed this artifact, and demonstrate the runner cannot reach any other environment."

Passes: Separate runner pool per environment (dev, staging, prod-PHI). Runners run on dedicated nodes with environment-scoped IAM roles. Egress is controlled by VPC Service Controls (GCP), AWS PrivateLink, or equivalent. A dev runner trying to reach prod-PHI gets a network denial, not an IAM denial.

Fails: Shared runner pool. Runner credentials with permissions across environments. "We use namespaces" as the only isolation. CI runner with internet egress to anywhere.

Fix: Dedicated runner pools per environment. IAM scoped to the single account the runner serves. Egress allowlist per runner. Network policy at the cluster level if runners run on Kubernetes.

09 — Evidence collection and retention: the audit trail has to outlive the pipeline that created it

Evidence retention is where most pipelines fail the audit even when the pipeline itself is well-built. CI tools rotate their run logs aggressively (30 to 90 days by default). HIPAA documentation retention is six years under § 164.316(b)(2). The arithmetic does not work, so the evidence has to live outside the CI tool from the moment it is produced.

The pattern: every pipeline run emits a structured set of artifacts (deploy event, scanner outputs, signature attestations, policy decisions) to an evidence bucket in a separate account, with retention locks configured. The Terraform for that bucket is short, and worth getting right:

# File: terraform/hipaa-evidence/main.tf
# Retention-locked evidence bucket for HIPAA CI/CD pipeline artifacts.
# Maps to 45 CFR § 164.312(b) audit controls and § 164.316(b)(2)
# documentation retention. The bucket lives in a dedicated logging
# account; production accounts have write-only access via a scoped role.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Evidence bucket. Object Lock in COMPLIANCE mode means even the root
# account cannot delete objects within the retention window. This is
# the property that satisfies the auditor's "can engineers tamper with
# the evidence?" question.
resource "aws_s3_bucket" "hipaa_evidence" {
  bucket              = "hipaa-evidence-${var.env}-${var.account_suffix}"
  object_lock_enabled = true

  tags = {
    Purpose      = "HIPAA pipeline evidence"
    CFRSection   = "164.312(b),164.316(b)(2)"
    Retention    = "6y"
  }
}

# Retention configuration. COMPLIANCE mode is non-negotiable for HIPAA
# evidence. GOVERNANCE mode lets privileged users override; that is a
# finding waiting to happen.
resource "aws_s3_bucket_object_lock_configuration" "hipaa_evidence" {
  bucket = aws_s3_bucket.hipaa_evidence.id

  rule {
    default_retention {
      mode = "COMPLIANCE"
      days = 2190  # 6 years; matches § 164.316(b)(2) documentation retention
    }
  }
}

# Versioning is a prerequisite for Object Lock. Without it the lock
# applies to a single object that can be overwritten with a new version.
resource "aws_s3_bucket_versioning" "hipaa_evidence" {
  bucket = aws_s3_bucket.hipaa_evidence.id
  versioning_configuration {
    status = "Enabled"
  }
}

# Encryption at rest with a customer-managed key. The key policy denies
# deletion by anyone but a designated break-glass role with MFA.
resource "aws_s3_bucket_server_side_encryption_configuration" "hipaa_evidence" {
  bucket = aws_s3_bucket.hipaa_evidence.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.hipaa_evidence.arn
    }
    bucket_key_enabled = true
  }
}

# Public access is blocked at the bucket level. There is no scenario in
# which HIPAA evidence should be public, so the block is total.
resource "aws_s3_bucket_public_access_block" "hipaa_evidence" {
  bucket                  = aws_s3_bucket.hipaa_evidence.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

The key property is Object Lock in COMPLIANCE mode. Once an object lands in this bucket, no one can delete it inside the retention window. Not the engineering team, not the platform team, not the root account. That is the architectural property that turns "we keep our evidence" into a verifiable statement. The same pattern translates to GCS Bucket Lock and Azure Immutable Blob Storage.

The cross-cutting principle here is one of the architectural decisions in the pipeline architecture pattern I use: the evidence outlives the pipeline that produced it, and lives where the pipeline cannot reach back to modify it. That is what makes the audit trail trustworthy under scrutiny.

10 — Change management: approval chains that survive auditor questioning

Every production deploy needs an approval chain that ties a named human to the artifact being deployed. The relevant question from § 164.308(a)(1)(ii)(B) is whether your sanction policy can be enforced: if a developer deploys an unreviewed change to a PHI environment, can you identify who, what, and when after the fact. If the answer is "we would have to dig," the control fails.

§ 164.308(a)(1)(ii)(B), § 164.312(b)

Production deploys require named-human approval, recorded against the artifact.

"For this production deploy, show me who approved, what they approved, and the change ticket they referenced."

Passes: Production environment is a protected environment in GitHub or a protected branch in GitLab. Approval is required from a named human in a defined approver group, not the deploy author. The approval event records the approver identity, the artifact digest, and the linked change ticket. The chain lands in the evidence bucket.

Fails: Auto-deploy from a green build. Approval clicks with no identity ("approved by user 'admin'"). Approver can be the same person who authored the change. The approval lives in the CI tool only and expires with the run log.

Fix: Protected environment with required reviewers from a separate approver group. The approval webhook emits a structured event into the evidence bucket, joining the approver identity, the artifact digest, and the change ticket reference. Treat the approval chain as a first-class deploy output.

11 — A representative engagement: what I found at a 32-host healthcare platform on GCP

I worked with a healthcare platform team running production workloads on GCP across roughly 32 VM-backed services that mixed Tomcat, Node.js, and OS versions in ways nobody had inventoried. Their compliance officer had a required baseline (Tomcat 9.0.62+, Node.js 18+, Ubuntu 20.04+). Their auditor was scheduled in five weeks. They did not know which hosts complied.

The first day we pulled their pipeline configurations and ran the evidence pull. The pipeline shipped well. Tests ran. Containers were built. The platform was stable. But: every deploy ran under a CI service account with full project-level IAM. The signing chain did not exist. Scanner output lived in pipeline artifacts that aged out after 90 days. The deploy event was not stored anywhere outside the CI tool. They had every individual capability needed to pass the audit, just not connected in the way the Security Rule expected.

We split the remediation into two parallel tracks. Track one: write an Ansible and Python tool that connected to each VM through GCP Identity-Aware Proxy, scraped the running versions of Tomcat, Node.js, and OS, and produced a compliance matrix mapping each host to the required baseline. That gave the compliance team the inventory they needed inside the first week instead of the four weeks a manual walk would have taken. Track two: rebuild the pipeline so the same baseline could not regress. We added Cosign signing with a KMS-backed key, Trivy and OSV-Scanner as policy gates that failed closed, Workload Identity Federation to eliminate the long-lived service account, a centralized logging account with Object Lock at 6-year retention, and a deploy-event emitter that wrote structured records to the evidence bucket on every cutover.

The audit cleared on first-party review. The compliance team kept the inventory tool as part of their continuous monitoring practice. The pipeline architecture is what the HIPAA CI/CD service page describes generically, but the engagement-specific detail that mattered: the baseline enforcement happens at plan time, not at deploy time. By the time the pipeline tries to ship a non-compliant container, the policy gate has already rejected the build. Future regressions are structurally impossible.

The pattern translates directly to AWS (CloudTrail organization trail + S3 Object Lock + IAM Identity Center) and Azure (Activity Log + Immutable Blob Storage + Entra ID federation). Where the integration patterns differ across SOC 2 and HITRUST is covered in HIPAA CI/CD vs SOC 2 CI/CD; the structural pattern is the same.

12 — The five questions auditors always ask

Across roughly a dozen HIPAA-environment engagements over the last few years, these five questions come up in some form every single time. Pre-answering them in your runbook is the single highest-leverage prep activity for an audit. Each maps to a control family already covered above; the value is having the answer in one paragraph that a non-engineer can read aloud to an assessor.

"Show me, by named human, who can deploy to a production-PHI environment, and when each person was last reviewed for that access." The answer should be one query against the IdP plus one against the access-review log. If the answer involves grepping CI runners, the architecture is wrong.
"For this specific production deploy from last Tuesday, show me the approval chain, the artifact signature, and the scanner results." The answer should be one query against the evidence bucket using the deploy ID. Three artifacts come back: the approval event, the signature attestation, and the scanner outputs.
"Can engineers in the production account read or modify the audit log?" The answer should be "no, the logs live in a separate account, retention-locked, write-only from production." If you have to qualify the answer, the architecture is wrong.
"What happens if a scanner finds a CRITICAL CVE during a production deploy?" The answer should be "the deploy blocks. The policy gate fails closed. We have a documented exception process that requires named-human approval and is itself logged as evidence."
"Show me a deploy from six months ago, and prove the running container today matches what was approved then." The answer should be a signature verification against the image currently running, plus the historical signing event from the evidence bucket. Drift detection is the supporting control.

If your team cannot answer all five in under five minutes per question with documentation, the audit will surface that. Better to surface it in your own dry-run two weeks ahead.

13 — Common gaps we see every engagement

Quick gap list · cross-reference

Long-lived service account credentials. Any credential that lives longer than the pipeline run that uses it is a finding. OIDC federation removes the entire category.

Logs in the same account as production. The most common single finding. Move them to a logging account with retention locks the day you start the audit prep.

Scanners as Slack notifications. Advisory scanners are not controls. The gate has to fail closed.

No deploy event outside CI. CI run logs expire. The deploy event has to live in the evidence bucket from the moment of cutover.

Approval workflow that lets the author approve. The approver and the author must be different humans. Required-reviewer configuration handles this in GitHub and GitLab.

Unsigned images in production. Cosign-signed images verified at admission. Anything less invites the question "how do you know what is running."

Most of these are structural choices made early that compound into hard-to-fix gaps. The longer write-up of the patterns most often missed lives in 5 mistakes healthcare teams make on HIPAA CI/CD.

14 — Closing: the architecture has to answer the question

Every control in this checklist reduces to the same property: the pipeline architecture makes the auditor's question answerable in seconds. Identity, integrity, audit trail, evidence retention, scanner gates, approval chains. Each is a touchpoint where the pipeline either has the answer or it does not.

The teams that ship well in regulated environments are not the ones with the most paperwork. They are the ones whose architecture makes compliance violations structurally difficult and whose evidence emits as a property of how the pipeline runs. That is what an auditor recognizes as a mature compliance posture, and it is also what lets engineering keep shipping while compliance reviews happen in parallel instead of in series.

If you are walking into a 3PAO assessment, a customer security review, or a HITRUST readiness pass: Stonebridge runs 2-week HIPAA CI/CD audits built around this exact checklist. Fixed fee, founder-led, the deliverable is a written control map plus a prioritized remediation roadmap your team can act on. We sign BAAs as part of the engagement and the report holds up under first-party review by your auditor.

About the author

This post originally appeared on Stonebridge Tech Solutions.

HIPAA CI/CD vs SOC 2 CI/CD: where the controls differ

Stonebridge Tech Solutions LLC — Mon, 18 May 2026 16:21:56 +0000

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.

Control area	HIPAA	SOC 2	Recommended	Acceptable	Avoid
BAA scope on deploy path	§ 164.308(a)(4)	(none)	OPA gate against a versioned BAA registry	Quarterly BAA review with deploy-path inventory	Trust the cloud provider default without verifying covered services
Audit log retention	§ 164.316(b)(2)(i)	CC7.2	S3/GCS Object Lock at 6-year retention in compliance mode	Append-only SIEM with documented 6-year archive	Default CloudWatch retention; "we never delete logs" as the policy
Encryption verification	§ 164.312(a)(2)(iv), § 164.312(e)(1)	CC6.7	Deploy-time signature and TLS verification; fail the build on miss	Daily synthetic transaction with alerting	Annual TLS posture review; soft warning in Helm charts
Workforce sanction enforcement	§ 164.308(a)(1)(ii)(C)	(none)	IdP-backed deploy entitlement evaluated at runner invocation	Pre-deploy human check against current entitlement list	Documented sanction policy with no system-level enforcement
Breach notification telemetry	§ 164.404	(none)	Signed deploy manifest queryable by digest, actor, and time	Centralized log search with deploy-event tagging	Reconstruct deploy provenance from Slack and CI run history

"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

This post originally appeared on Stonebridge Tech Solutions.

How to build a HIPAA-compliant CI/CD pipeline: a 2026 implementation guide

Stonebridge Tech Solutions LLC — Sun, 17 May 2026 20:39:47 +0000

The architecture, the code, and the parts auditors actually inspect.

Most HIPAA CI/CD content describes the controls. This one describes the architecture.

A healthcare engineering team I worked with had six weeks to make their CI/CD pipeline audit-ready. They had GitLab. They had AWS. They had a smart team that had already read 45 CFR § 164. They knew what HIPAA required.

They were stuck anyway. Every guide they could find described which controls HIPAA mandates and which scanners to run. None of them described how to actually build the pipeline that emits the controls.

Three architectural decisions separate HIPAA-compliant pipelines from generic CI/CD: parent/child pipeline separation, isolated runners per environment, and security scanners as policy gates rather than advisory output. Everything else flows from these three.

If you've already read the five patterns that fail HIPAA audits, this is the implementation side of the same coin. The earlier post was about what goes wrong. This one is about what to build instead. The code examples assume GitLab CI/CD as the primary platform. The patterns port cleanly to GitHub Actions and Argo CD; I'll call out the translations where they matter. The cloud examples cover GCP and AWS specifically.

Section 01 — What HIPAA actually requires from a pipeline

HIPAA's Security Rule doesn't specify pipelines. It specifies safeguards. A correctly-built CI/CD pipeline is one of the most efficient places to satisfy those safeguards continuously, instead of producing them as quarterly evidence runs before audit windows.

Five controls touch the pipeline most directly:

§ 164.308(a)(5)(ii)(C) Log-in monitoring. Every deployment must be attributable to an authenticated identity with audited access. In pipeline terms: who triggered this deploy, with what credentials, and is that identity authorized for this environment?
§ 164.308(a)(8) Periodic evaluation. Security evaluations must happen on every change, not on a schedule. Vulnerability scans, dependency checks, and policy evaluations run on every push.
§ 164.312(b) Audit controls. The pipeline records who deployed what, when, against which approval chain. Every deploy is queryable months later without forensic reconstruction.
§ 164.312(c)(1) Integrity controls. Artifacts are signed, signatures are verified before deployment, and tampering is structurally detectable. The artifact you deploy is provably the one that passed scanning.
§ 164.312(e)(1) Transmission security. Deployments to PHI-bearing environments use mutually-authenticated, encrypted channels. No deploys over unencrypted protocols, no bearer-token-only authentication to production.

None of these are exotic. All of them are routinely missed in pipelines built without the controls in mind from day one. The framing that helps most: HIPAA doesn't tell you how to build a pipeline. It tells you what evidence the pipeline must produce. Once you accept that, the architecture follows.

The pillar page covers the full control mapping in more detail. The five above are enough to anchor every architectural decision that follows.

Section 02 — Three architectural decisions

Most HIPAA pipeline guides are checklists. Run SAST. Run container scanning. Sign your artifacts. Encrypt your transmissions. Store your audit logs. The checklists are correct, and almost completely useless.

They're useless because they describe outputs without describing the architecture that produces them. A team can implement every item on the checklist and still build a pipeline that fails audit. I've seen it happen four times.

Three decisions, made early, determine whether a HIPAA pipeline actually works. The next three sections walk through each one: what goes wrong without it, what the architecture looks like, and what the code looks like.

Decision 01 — Parent/child pipeline separation

Most HIPAA pipelines start as a single .gitlab-ci.yml file. It works fine for the first three months. By month six it's 800 lines. By month twelve it's 1,500 lines and nobody touches it without flinching.

The problem isn't just maintainability. It's auditability. A 1,500-line pipeline file mixes environment-level concerns (production approval gates, evidence aggregation, signing) with service-level concerns (unit tests, container builds, lint checks). The auditor's question, "show me that production deploys are gated", requires reading the entire file to answer. And every YAML change risks dropping a compliance gate that nobody noticed was load-bearing.

The fix is structural separation. A parent pipeline owns environment-level concerns: compliance gates, approvals, evidence aggregation, deployment authorization. It changes rarely and is the system of record for "what happened." Child pipelines own service-level concerns: build, test, scan, container packaging. They evolve independently per service.

The pattern is platform-independent. In GitLab CI/CD it's implemented with trigger: jobs and downstream artifact propagation. In GitHub Actions, with reusable workflows (workflow_call). In Argo CD, with ApplicationSets and progressive delivery patterns. The platform changes; the architecture doesn't.

A simplified parent pipeline looks like this:

# .gitlab-ci.yml (parent)
# Owns: compliance gates, evidence, deploy authorization

stages:
  - authorize
  - build
  - aggregate-evidence
  - policy-gate
  - deploy

variables:
  HIPAA_ENVIRONMENT: ${CI_COMMIT_BRANCH}
  EVIDENCE_BUCKET: "gs://hipaa-evidence-${ENV}"

authorize:
  stage: authorize
  script:
    - ./scripts/verify-identity.sh "$GITLAB_USER_ID" "$HIPAA_ENVIRONMENT"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

trigger-build:
  stage: build
  trigger:
    include: .gitlab/child-build.yml
    strategy: depend
  variables:
    PARENT_PIPELINE_ID: $CI_PIPELINE_ID

aggregate-evidence:
  stage: aggregate-evidence
  script:
    - ./scripts/collect-evidence.sh "$PARENT_PIPELINE_ID"
    - gsutil cp evidence-bundle.json "$EVIDENCE_BUCKET/$CI_PIPELINE_ID/"
  needs: ["trigger-build"]

policy-gate:
  stage: policy-gate
  image: openpolicyagent/opa:latest
  script:
    - opa eval -d policies/ -i evidence-bundle.json "data.deploy.hipaa.allow"
  needs: ["aggregate-evidence"]

deploy-production:
  stage: deploy
  tags: ["hipaa-prod-runner"]
  environment: production
  when: manual
  script:
    - ./scripts/deploy-signed.sh
  needs: ["policy-gate"]

That's the entire parent pipeline: under 40 lines, every stage doing one thing, every job tied to an explicit compliance concern. The child pipeline handles build/test/scan in a separate file that the service team owns. The parent owns the gates; the child owns the code.

More on the three architecture principles I apply on every HIPAA pipeline build →

Decision 02 — Isolated runners per environment

The most underappreciated HIPAA control isn't in the pipeline file. It's in the runner.

Most teams use shared GitLab or GitHub Actions runners with IAM credentials broad enough to reach multiple environments. A misconfigured .gitlab-ci.yml from a dev branch can deploy to production, because the runner has the credentials and nothing stops the YAML from using them. Worse: the runner itself becomes an attack surface. A compromised runner with production IAM access reaches PHI directly, and your audit logs don't show that as a privileged access path because the runner is "just CI."

Auditors want a specific story: this deployment to production went through this specific runner, with this specific identity, at this specific time, signed by this specific key. If you can't tell that story crisply, the runner is your audit finding.

Four patterns isolate runners properly:

Dedicated runners per environment. Production deploys run on production-only runners. Dev branches cannot trigger production runners through any path.
Scoped IAM per runner. Dev runner has dev IAM; prod runner has prod IAM. Neither can deploy to the other. The pipeline file cannot lift its own privileges.
Signed, version-pinned runner images. No gitlab-runner:latest. Image signature verified before runner starts.
HIPAA-aligned runner infrastructure. Encrypted at rest, audit-logged, ephemeral where possible, isolated network egress.

On GCP, the cleanest implementation is a dedicated GKE node pool per environment, with Workload Identity binding runner service accounts to environment-scoped IAM roles:

# Terraform: GCP HIPAA runner infrastructure

resource "google_container_node_pool" "hipaa_prod_runners" {
  name       = "hipaa-prod-runners"
  cluster    = google_container_cluster.hipaa.id
  node_count = 2

  node_config {
    machine_type = "n2-standard-4"
    image_type   = "COS_CONTAINERD"

    # Workload Identity: runner SA cannot escape its scope
    workload_metadata_config {
      mode = "GKE_METADATA"
    }

    service_account = google_service_account.runner_prod.email
    oauth_scopes    = ["https://www.googleapis.com/auth/cloud-platform"]

    # Encrypted boot disk
    disk_size_gb = 100
    disk_type    = "pd-ssd"

    # Network isolation: only egress to allowed targets
    tags = ["hipaa-prod-runner"]
  }

  # Auto-upgrade for CIS-aligned base images
  management {
    auto_upgrade = true
    auto_repair  = true
  }
}

resource "google_service_account" "runner_prod" {
  account_id   = "hipaa-prod-runner"
  display_name = "HIPAA Production CI Runner"
}

# Runner SA can deploy to prod GKE only — not dev, not staging
resource "google_project_iam_member" "runner_prod_deploy" {
  project = var.project_id
  role    = "roles/container.developer"
  member  = "serviceAccount:${google_service_account.runner_prod.email}"

  condition {
    title       = "Production cluster only"
    expression  = "resource.name.startsWith('projects/${var.project_id}/zones/${var.zone}/clusters/hipaa-prod')"
  }
}

The IAM condition is the load-bearing part. Even if a developer writes a pipeline that tries to deploy to staging from a production runner, the IAM denies the action at the GCP API layer. The pipeline file cannot grant itself privileges the runner doesn't have.

The 5 mistakes post covers why pipeline-runner isolation matters in more depth. The TL;DR: shared runners with broad IAM are the most common HIPAA pipeline finding I see, and the cheapest to fix.

Decision 03 — Security scanners as policy gates

Almost every HIPAA pipeline guide includes security scanners. SAST, DAST, container CVE scanning, dependency checking, IaC scanning. The tools are right. The configuration is usually wrong.

Most teams run scanners as advisory: scans execute, results are saved to a dashboard, the deploy proceeds regardless. Auditor asks: "what happens when a critical vulnerability is found?" The honest answer is usually "the developer gets notified and decides what to do." That answer fails audit.

The right answer: the deploy is blocked by policy. The human approver only sees the deploy button if every scanner produced evidence that passed threshold. Scanners produce inputs to a policy engine. The policy engine decides whether the deploy proceeds. Humans provide judgment on top of that decision, not validation that the pipeline ran.

Five scanners earn their place in a HIPAA pipeline:

SAST. Semgrep with custom rules for healthcare-specific patterns. CodeQL is a strong alternative if you're already on GitHub Advanced Security.
Container CVE scanning. Trivy. Grype is acceptable. Don't rely on cloud-provider-only scanners (ECR scan, Artifact Registry scan) as your only line.
IaC scanning. tfsec plus Checkov. They catch different things; run both.
Secret scanning. Gitleaks in pre-commit and in CI. TruffleHog also works.
Dependency scanning. OSV-Scanner for transitive vulnerabilities. Dependabot for routine updates.

The architecture is the same regardless of which tools you pick. Scanner runs, produces structured output (JSON or SARIF), evidence is signed and stored, policy engine evaluates evidence, gate opens or closes:

# policies/hipaa_deploy.rego
# OPA policy gate for HIPAA production deploys

package deploy.hipaa

default allow = false

# Deploy allowed if all four conditions hold
allow {
    scan_evidence_valid
    signature_valid
    approver_authorized
    target_environment_matches
}

# All scanners produced evidence in last 24 hours
scan_evidence_valid {
    input.scans.container.timestamp > time.now_ns() - (24 * 60 * 60 * 1e9)
    input.scans.sast.timestamp     > time.now_ns() - (24 * 60 * 60 * 1e9)
    input.scans.iac.timestamp       > time.now_ns() - (24 * 60 * 60 * 1e9)
}

# Zero critical findings across all scanners
scan_evidence_valid {
    input.scans.container.critical == 0
    input.scans.sast.critical      == 0
    input.scans.iac.critical       == 0
    input.scans.secrets.findings   == 0
}

# Artifact signature verified by Cosign
signature_valid {
    input.artifact.cosign_verified == true
    input.artifact.signed_by       == input.expected_signer
}

# Approver is on the authorized list for this environment
approver_authorized {
    authorized := data.approvers[input.target_environment]
    input.approver_id == authorized[_]
}

# Deploy target matches the artifact's intended environment
target_environment_matches {
    input.artifact.target_env == input.target_environment
}

Every condition in that policy is checkable, auditable, and structurally enforced. When the auditor asks "how do you guarantee scans pass before deploy?", the answer is a 35-line Rego file you can hand them.

Section 03 — Putting it together: the reference architecture

The three decisions compose into a six-stage pipeline. Each stage emits evidence. Each evidence artifact is signed and stored separately from code. The policy gate evaluates the full evidence bundle before any deploy proceeds.

┌───────────────────────── PARENT PIPELINE ─────────────────────────┐
│ Compliance gates · Approvals · Evidence aggregation · Authorization│
└────┬───────────────┬─────────────────┬─────────────────┬──────────┘
     ▼               ▼                 ▼                 ▼
┌─────────┐    ┌─────────┐       ┌─────────┐       ┌─────────┐
│ CHILD 01│    │ CHILD 02│       │ CHILD 03│       │ CHILD 04│
│  Build  │    │  Test   │       │  Scan   │       │  Sign   │
└────┬────┘    └────┬────┘       └────┬────┘       └────┬────┘
     │              │                 │                 │
     └──────────────┴─────────┬───────┴─────────────────┘
                              ▼
       ┌──── IMMUTABLE EVIDENCE BUCKET (retention-locked) ────┐
       │ SBOMs · Scan results · Signatures · Approval records │
       └──────────────────────┬───────────────────────────────┘
                              ▼
                    ┌───── POLICY GATE ─────┐
                    │ OPA evaluates evidence│
                    │   allow or deny       │
                    └──────────┬────────────┘
                               ▼
              ┌──────────────────────────────────┐
              │ Deploy via isolated prod runner  │
              └──────────────────────────────────┘

The diagram makes one thing clear that the prose can hide: evidence flows in one direction only. Child pipelines write evidence to the bucket; nothing reads from it except the policy gate. The bucket is write-once from CI's perspective, and read-only from the gate's perspective. Engineers cannot tamper with evidence after the fact, because the bucket's IAM policy doesn't allow CI to modify or delete existing objects.

This is what auditors mean by "audit controls." Not a logfile somewhere. A separate, immutable, queryable record of everything the pipeline did, signed by the pipeline's identity, retained per your compliance policy.

Adjacent frameworks · CMMC and FedRAMP

The same architecture satisfies most of the technical controls in CMMC 2.0 (Levels 2 and 3) and FedRAMP Moderate. The control mappings differ. CMMC inherits NIST 800-171 control families; FedRAMP uses NIST 800-53. The underlying engineering is identical. Parent/child pipelines satisfy CM-3 (Configuration Change Control) and AU-2 (Audit Events). Isolated runners satisfy AC-3 (Access Enforcement) and SC-7 (Boundary Protection). Policy gates satisfy SI-2 (Flaw Remediation) and CA-7 (Continuous Monitoring).

For defense workloads, the only material differences are runner placement (CI runners must operate inside the GovCloud or Azure Government boundary) and KMS configuration (FIPS 140-2 validated). Build the pipeline correctly for HIPAA and the FedRAMP version is mostly a deployment configuration change.

Section 04 — GCP-specific implementation

On GCP, the HIPAA pipeline architecture maps to a specific set of native services. The translations matter because cloud-specific service quirks determine whether the pattern actually satisfies the underlying control.

Evidence storage. GCS bucket with versioning, retention locks, and Bucket Lock for write-once semantics. Use a separate project for the evidence bucket so its IAM is independently managed.
Signing keys. Cloud KMS with automatic rotation. Cosign integrates natively. Use HSM-backed keys for production signing.
Runner infrastructure. GKE Autopilot or Standard with environment-specific node pools. Workload Identity binds runner pods to GCP service accounts. Per-environment service accounts with IAM conditions enforce boundary.
Artifact storage. Artifact Registry, not the deprecated Container Registry. Turn on vulnerability scanning at the registry layer as a second line.
VPC-SC perimeters. Restrict service-to-service access at the network layer. CI runners outside the perimeter cannot reach PHI-bearing services.
Identity-Aware Proxy. When the pipeline must reach VMs (rare but real, especially for legacy environments), IAP provides the audited, encrypted, identity-aware channel.

A simplified GCP deploy job looks like this:

# .gitlab/child-deploy-gcp.yml
# HIPAA-aligned GKE deploy, GCP-specific

deploy-gcp:
  stage: deploy
  image: google/cloud-sdk:slim
  tags: ["hipaa-prod-runner"]

  before_script:
    # Workload Identity authentication (no static keys)
    - gcloud auth print-access-token > /tmp/token
    - gcloud config set project $GCP_PROJECT_ID

  script:
    # Verify artifact signature before deploy
    - cosign verify
        --key gcpkms://projects/$GCP_PROJECT_ID/locations/$GCP_REGION/keyRings/hipaa/cryptoKeys/signing
        $ARTIFACT_REGISTRY_URL/hipaa-app:$CI_COMMIT_SHA

    # Deploy to GKE with image digest (not tag)
    - kubectl set image deployment/hipaa-app
        hipaa-app=$ARTIFACT_REGISTRY_URL/hipaa-app@sha256:$ARTIFACT_DIGEST

    # Emit deployment evidence
    - ./scripts/emit-evidence.sh deploy-complete $CI_PIPELINE_ID

  environment:
    name: production-gcp
    deployment_tier: production

  rules:
    - if: '$CI_COMMIT_TAG && $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/'

Three things to notice. First, no JSON service account key is ever written to disk; Workload Identity issues short-lived tokens. Second, the deploy uses the image digest, not the tag, so a race condition between tag-and-deploy can't substitute a different image. Third, evidence emission is part of the deploy job itself; if the deploy succeeds, evidence is written, and the parent pipeline can see it.

Section 05 — AWS-specific implementation

On AWS the architecture is the same; the services change names. For teams operating in both clouds (increasingly common in healthcare), the parent pipeline can dispatch to either cloud's child pipeline based on a variable. Both clouds emit evidence to a centralized bucket, both clouds use OPA for policy gating, both clouds use Cosign for signing.

Evidence storage. S3 with Object Lock in Compliance Mode, versioning enabled, cross-region replication for redundancy.
Signing keys. AWS KMS with customer-managed keys (CMKs), automatic rotation, CloudTrail logging on every key use.
Runner infrastructure. EKS managed node groups with IRSA (IAM Roles for Service Accounts). Separate node groups per environment with taints and tolerations.
Artifact storage. ECR with image scanning enabled and immutable tags. Lifecycle policies for evidence retention.
Network isolation. Transit Gateway for environment-level isolation. Security groups operate on principles (referencing tags or names) rather than IP allowlists.
GovCloud variant. Same architecture, runners placed inside the GovCloud boundary for FedRAMP-aligned workloads.

IRSA is the AWS analog to GCP's Workload Identity. The Terraform looks similar but the trust policy is what does the work:

# Terraform: AWS HIPAA runner IAM role (IRSA)

resource "aws_iam_role" "hipaa_prod_runner" {
  name = "hipaa-prod-runner"

  assume_role_policy = jsonencode({
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = aws_iam_openid_connect_provider.eks.arn
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "${replace(aws_iam_openid_connect_provider.eks.url, "https://", "")}:sub" =
            "system:serviceaccount:gitlab-runner:hipaa-prod-runner"
          # Scope to one specific namespace + one service account
        }
      }
    }]
  })
}

# Scoped policy: deploy to prod cluster only
resource "aws_iam_role_policy" "hipaa_prod_deploy" {
  role = aws_iam_role.hipaa_prod_runner.id

  policy = jsonencode({
    Statement = [{
      Effect = "Allow"
      Action = [
        "eks:DescribeCluster",
        "eks:ListClusters"
      ]
      Resource = aws_eks_cluster.hipaa_prod.arn
      Condition = {
        StringEquals = {
          "aws:RequestedRegion" = "us-east-1"
        }
      }
    }]
  })
}

The IRSA trust policy is the boundary enforcement. The runner pod can only assume this role if it runs in the specific namespace with the specific service account. A dev pipeline cannot bypass it; an attacker who compromises a dev runner cannot pivot to it.

Section 06 — What this looks like in production

One of our healthcare engagements involved auditing a GCP-based platform running production workloads with PHI in flight. The internal team had been told to be ready for a third-party HIPAA assessment in six weeks. They had GitLab CI/CD, a working pipeline, and a compliance team that knew what HIPAA wanted. What they didn't have was visibility into VM-level inventory or evidence that their pipeline controls were enforced rather than recommended.

We started with the architectural audit: was the pipeline parent/child or monolithic (monolithic, 1,200 lines), were runners isolated per environment (no, one shared runner with broad IAM), were scanners producing policy gate inputs (no, scanners ran as advisory). Three findings, all structural, all addressable.

The remediation was the architecture above. Parent pipeline owns gates; child pipelines own builds. Dedicated runner per environment with scoped IAM. Scanners producing signed evidence into an immutable bucket; OPA policy evaluating before deploy. Six weeks of work, fixed scope, fixed fee.

The team passed the third-party audit on first-party review. More importantly, the pipeline kept passing through subsequent quarterly audits without remediation work, because the architecture made the controls structural instead of procedural.

That's the test of a HIPAA pipeline: does it pass audit when the auditor changes, the team changes, and the code changes? An architecturally correct pipeline does. A checklist-compliant pipeline doesn't.

Section 07 — Tooling recommendations

Opinionated picks, based on what actually holds up in regulated environments. Substitutions are fine; the architecture matters more than the specific tool.

Stage	Recommended	Acceptable alternative	Avoid
Build	Buildah, Kaniko (rootless)	docker:dind (with caveats)	Privileged Docker on shared runners
SAST	Semgrep with custom rules	CodeQL (if on GitHub)	Cloud-vendor scanners alone
Container scanning	Trivy	Grype	ECR / Artifact Registry scan as only line
IaC scanning	tfsec + Checkov (both)	KICS	Manual review
Secret scanning	Gitleaks (pre-commit + CI)	TruffleHog	Regex-only homebrew checks
Signing	Cosign with KMS-backed keys	Sigstore (notary v2)	Manual signing, local keys
Policy gates	OPA / Rego	Kyverno (k8s-specific)	Manual approval only
Evidence storage	S3 Object Lock / GCS Bucket Lock	Versioned bucket only	Same Git repo as code

Section 08 — The CI/CD platform question

Three platforms cover roughly 90% of HIPAA CI/CD work I see: GitLab CI/CD, GitHub Actions, and Argo CD. None of them are wrong choices for HIPAA work. Each makes the architecture above easier or harder in specific ways.

GitLab CI/CD is the cleanest fit for parent/child pipelines. Native trigger: jobs, downstream artifact propagation, and self-hosted runners with custom tags make the runner isolation pattern straightforward. The compliance gates ride naturally on the parent pipeline structure.

GitHub Actions can do the same with reusable workflows (workflow_call), but the model is more constrained. Runner isolation requires GitHub Enterprise or self-hosted runners with custom labels. Workable, not as clean.

Argo CD is excellent for the deploy stage. It's not a complete CI tool. Pair it with GitLab CI/CD or GitHub Actions for build/test/scan, then use Argo CD for the actual deploy with GitOps semantics. ApplicationSets are an underappreciated mechanism for environment isolation.

For new HIPAA pipelines, my opinionated default is GitLab CI/CD plus Argo CD. Stronger primitives for parent/child separation, cleaner runner isolation, and Argo CD's progressive delivery patterns reduce blast radius. Don't try to use Jenkins for new HIPAA pipelines.

Section 09 — Common mistakes to avoid

Five quick callouts from the field. Each one fails audits more often than it should.

Single thousand-line pipeline file. Refactor to parent/child before the file passes 500 lines. Past 1,000 it's an audit finding waiting to surface.
Shared runners with broad IAM. Isolated runners per environment, scoped IAM, no exceptions for "the deploy job."
Scanners running as advisory. Scanners produce evidence. Evidence feeds policy. Policy decides. The human approves with judgment, not by validating the pipeline ran.
Audit evidence in Git. Evidence lives in a separate immutable bucket. The same Git repo as code is the wrong answer.
Manual approval as the only control. A human clicking a button satisfies nothing on its own. The button only appears when the policy gate passes.

For longer-form examples of these failure modes, the earlier post on five patterns that fail HIPAA audits walks through each with healthcare engagement examples.

Section 10 — Conclusion

The team that ships well in regulated environments isn't the one with the most paperwork. It's the one whose architecture makes compliance violations structurally difficult.

"Audit-ready" isn't a state you achieve. It's a property of how the pipeline operates. Parent/child separation isolates compliance from delivery so both can evolve. Isolated runners per environment stop pipeline files from lifting their own privileges. Security scanners as policy gates turn checklists into enforcement.

Build the architecture correctly and audits become queries. Build it incorrectly and audits become fire drills, no matter how many tools you bolt on.

If you're working through this at your team: Stonebridge runs two-week HIPAA CI/CD audits that map your existing pipeline 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 structural mistakes most often blocking this architecture live in 5 mistakes healthcare teams make on HIPAA CI/CD. Where the same pattern diverges for SOC 2 procurement is mapped in HIPAA CI/CD vs SOC 2 CI/CD. The pre-audit walkthrough of every Security Rule control is in the HIPAA CI/CD audit checklist.

About the author

This post originally appeared on Stonebridge Tech Solutions.

5 things healthcare engineering teams get wrong about HIPAA CI/CD

Stonebridge Tech Solutions LLC — Tue, 05 May 2026 23:26:00 +0000

I've spent the last six years building cloud infrastructure and CI/CD pipelines for healthcare and defense engineering teams. The same five mistakes keep showing up across every HIPAA engagement I take on, and none of them are about not knowing what HIPAA requires.

Engineers in healthcare aren't dumb. They've read 45 CFR § 164. They know what audit logs are. They've sat through compliance training that lasted longer than their last on-call rotation.

The problem is structural. Most CI/CD pipelines were designed for unregulated software, then bolted with compliance controls afterward. The result is pipelines that satisfy neither engineers nor auditors. Slow, brittle, and somehow still failing audits.

Here are the five patterns I see most often, what goes wrong with each, and what actually works.

1. Treating compliance as a final gate

The most common pattern: your pipeline runs build, test, and deploy as normal. Then somewhere near the end, a "compliance check" stage runs that produces a report. Audit time rolls around and someone has to dig through six months of build artifacts to assemble evidence.

This fails for two reasons.

First, you can't debug what failed. When the auditor asks "show me the security review for build #4,827 from last March," nobody knows where that evidence lives. It's somewhere in CI logs that have probably rolled off retention.

Second, the late-stage gate creates a false sense of security. Engineers learn that compliance is "the thing that happens at the end," so they stop thinking about it during development. Vulnerabilities ship to staging, get caught at the gate, and the pipeline gets blocked. Now you have an angry developer, a bottlenecked release, and a control that's optimized for catching mistakes rather than preventing them.

What works instead: emit compliance evidence as a property of every stage. Build stage produces an SBOM. Test stage produces signed test results. Scan stage produces vulnerability data. Sign stage produces a signature chain. All of it gets pushed to immutable storage with retention locks the moment it's generated.

When the auditor asks for evidence, the answer is a query, not a project.

2. A single thousand-line `.gitlab-ci.yml`

I've inherited too many pipelines that look like this:

# .gitlab-ci.yml, 1,847 lines
stages:
  - build
  - test
  - scan
  - deploy
  - notify
  - more-things
  - even-more-things

build:dev:
  # 200 lines

build:staging:
  # 200 lines, mostly copy-pasted from above

build:prod:
  # 200 more lines

test:dev:
  # ...

You cannot review this file. You cannot test it. You cannot meaningfully change it without breaking something else. And every time you push to fix a typo, the entire pipeline runs.

For a HIPAA workload, this is doubly bad. Auditors specifically ask whether you can demonstrate that controls are applied consistently across environments. With a monolithic file, the answer is "trust us." With auditors, "trust us" is the wrong answer.

What works instead: parent/child pipeline architecture.

Your parent pipeline handles environment-level concerns: compliance gates, deployment authorization, evidence aggregation. It's stable, rarely changes, and is the system of record for "what happened."

Your child pipelines handle service-level concerns: build, test, scan, deploy. They're triggered by the parent and can evolve independently per service.

In GitLab, this is implemented with trigger: jobs and include: directives. In GitHub Actions, with workflow_call. In Argo CD, with ApplicationSets.

The pattern matters more than the platform. Once you separate "what runs" from "what's allowed to run," your pipeline becomes auditable instead of incomprehensible.

3. Manual approval as the only meaningful control

You've seen this in every regulated environment: a deployment job that requires a human to click "approve" before production. Sometimes there's even a Slack notification asking three people to thumbs-up before it proceeds.

Auditors love seeing this in pipeline diagrams. Until you ask: what is the human actually approving?

If the answer is "they're confirming the build looks good," that's not a control. That's theater.

A meaningful approval is one backed by something. The signed artifacts checked out clean. The vulnerability scan came back below threshold. The compliance baseline was verified. The deployment target is in the right environment. The approver is providing judgment on top of those things, not validating that the pipeline ran.

If your approver is just looking at a green checkmark and clicking yes, you have a process that looks like a control but doesn't actually gate anything. Auditors who know what they're doing catch this immediately.

What works instead: policy-as-code gates before the human approval. We use Open Policy Agent (OPA) with Rego policies that verify:

Container signature chain validates against trusted keys
SBOM exists and matches the deployed image
Vulnerability scan is < 24 hours old and below threshold
Approver identity matches an authorized list
Target environment matches what was scanned

The human approver only sees the deploy button if all of those pass. Their job is judgment ("should we ship this on a Friday?"), not validation ("is this safe?"). That's automated.

4. No environment isolation in the CI runners themselves

This one slipped past me on a project a few years ago, and I see it almost everywhere. You're running CI on shared runners. The runners have IAM credentials with access to multiple AWS accounts, including production. A misconfigured .gitlab-ci.yml from a developer branch could, in theory, deploy to production.

Worse: the runner itself becomes a giant attack surface. If anyone compromises a CI job (through a malicious dependency, a typosquatted image, anything), they have whatever access the runner has.

For a HIPAA workload, this is catastrophic. Your runner now has access to PHI-bearing environments, and your audit logs don't show that as a privileged access path because the runner is "just CI."

What works instead: runner isolation at the network and IAM level.

Production deployments run on dedicated runners in a network that can only reach production. Dev branches can't trigger them.
Runner IAM roles are scoped per-environment. The dev runner can deploy to dev. The prod runner can deploy to prod. Neither can deploy to the other.
Runner images are signed and version-pinned. We don't pull gitlab-runner:latest.
Runners themselves are HIPAA-aligned: encrypted at rest, audit-logged, ephemeral where possible.

The pattern auditors want to see is: "the deployment to production went through this specific runner, with this specific identity, at this specific time, signed by this specific key." If you can't tell that story, your pipeline is the audit finding.

5. Audit evidence stored alongside the code

Here's the one I see catch teams off guard the most. They've done everything else right. Pipeline emits evidence, signed artifacts, policy gates, the works. Then the auditor asks: where does the evidence live?

"In our Git repo. We commit pipeline logs and scan results."

This fails immediately. The control says "the evidence must be tamper-evident." If engineers have write access to the repository (and they do, that's the whole point of the repo), then engineers have write access to the evidence. The control is broken.

I had this exact conversation with a healthcare team a couple of years back. Smart engineers, modern pipeline, decent security posture. They'd been storing artifacts and audit logs in the same repo as their Terraform code. Worse: the team had GCP service account credentials committed to the Terraform code base. Not by malice. Just because someone had been moving fast on a Friday and pushed credentials to make a CI test work.

The credentials were in the repo. The audit logs were in the repo. The Terraform that provisioned the audit logging bucket was in the repo. None of that survived an honest auditor's first questions.

What works instead: evidence storage is its own thing, separate from CI infrastructure entirely.

Object storage with versioning + retention locks (S3 Object Lock, GCS retention policies, Azure Blob immutable storage). Once written, can't be modified or deleted within the retention window.
Write-only access from CI. The pipeline can push evidence. Nobody (including the people who run the pipeline) can modify or delete it.
Read access is logged separately. Auditors can read; reads are themselves audit-logged.
Encryption keys are managed in a different account / project than where the pipeline runs.

The control to demonstrate is: "even if every engineer on the team colluded, they couldn't tamper with the audit trail." That's what the auditor wants to verify. If you can't structurally guarantee it, you don't have a control. You have a hope.

If you have credentials in your Terraform code base, rotate them today, then move them into a secrets manager (GCP Secret Manager, AWS Secrets Manager, HashiCorp Vault) referenced by Terraform but never stored in plaintext. Treat any committed credential as compromised regardless of whether the repo is private.

The pattern under all five

If you read these carefully, the same principle keeps showing up: the controls have to be properties of the system, not activities humans remember to perform.

Human-dependent controls fail because humans forget, get busy, get tired, or move on to other teams. System-dependent controls fail only when someone changes the system, and changing the system is itself an audit-loggable event.

Healthcare engineering teams that ship well in regulated environments aren't the ones with the most paperwork. They're the ones whose pipeline architecture makes compliance violations structurally difficult.

That's what auditors actually want to see, and it's also what lets your engineering team ship without fighting compliance the whole time.

If this resonates with what your team is dealing with, or if you're staring down an audit and your pipeline looks more like #2 than what I described, this is what we work on at Stonebridge Tech Solutions. Happy to talk shop either way.

What patterns am I missing? Drop them in the comments. I'd genuinely like to know what other people are seeing in the field.