Compliant delivery pipeline for a healthcare platform

Work carried out at acAIberry on the delivery pipelines for a healthcare platform operating under HITRUST, with ISO-aligned controls over data handling.

The engineering content of the work was ordinary continuous delivery. What made it different was that the pipeline itself was an audited control. A stage that ran successfully but left no record of having run was, from a compliance perspective, a stage that did not happen.

Regulated delivery has a requirement that ordinary delivery does not: every promotion to production must be reconstructible after the fact. An auditor asks which version is running, who approved it, which scans passed, and what the scan results were on the day of the deployment. Answering that from memory or from ephemeral CI logs is not an answer.

The starting position had working pipelines that built and deployed correctly but produced evidence only incidentally, in job logs subject to retention limits. The controls existed in practice and were difficult to demonstrate.

Make evidence a build artefact rather than a side effect of logging.

Each pipeline stage that corresponds to a control emits a structured record: what ran, against which commit, with which tool version, and what the result was. Those records are collected into a per-pipeline evidence bundle attached to the pipeline run and retained on the same schedule as the release itself.

Promotion to production became an explicit gate rather than an implicit consequence of merging. The gate checks that the evidence bundle is complete before it will allow a deployment, which means a missing scan blocks a release instead of silently passing.

Stages

Build, unit test, dependency and container image scanning, infrastructure configuration check, evidence collection, then a gated deployment stage per environment.

Evidence bundle

A structured document per pipeline run: commit SHA, image digest, tool versions, scan findings by severity, test results, and the identity that approved the promotion. Attached to the pipeline run, retained with the release.

Gate

The production deployment stage is manual and refuses to start unless the evidence bundle for that commit is present and complete. A pipeline that skipped a scan cannot reach production, whether the skip was accidental or deliberate.

Secrets and configuration

Secrets injected at deployment time from the platform secret store, scoped per environment. No secret material in the image, the repository or the pipeline definition.

GitLab CI for pipeline orchestration. Ansible for configuration management and deployment of the application tier, which gave idempotent, repeatable server state described in version control. Container image scanning and dependency scanning in the pipeline. Prometheus and Grafana for the runtime monitoring the platform already used.

Ansible playbooks replaced the remaining manual configuration steps on the application tier. The gain that mattered was not saved time but repeatability: the same playbook run against a rebuilt host produces the same state, which is a much easier claim to evidence than a runbook that a person followed.

Image digests, not tags, identify what is deployed. A tag can be moved; a digest cannot. The evidence bundle records the digest, so "which version is running" has a single unambiguous answer.

Scan results are recorded in full, including findings that were accepted rather than fixed, with the acceptance recorded alongside. Suppressing a finding without leaving a trace is the failure mode that makes scanning theatre.

Evidence and speed pull against each other. Every additional gate lengthens the path to production. The resolution was to run all evidence-producing stages in parallel where they had no dependency on each other, so the pipeline got wider rather than longer.

Accepted risk needs a home. Not every scan finding is fixable inside a release window. Without a recorded acceptance path, engineers route around the scan. With one, the acceptance itself becomes reviewable.

Compliance vocabulary versus engineering vocabulary. A meaningful part of the work was translation: what a control document calls change management is what the team calls merge and deploy. Mapping the two explicitly stopped the same argument recurring weekly.

Evidence as an artefact. Logs are for humans debugging now; artefacts are for auditors asking later. Conflating them was the original problem.

Digest-pinned deployments. Slightly more friction in the pipeline definition, and it removes an entire class of "which build is that" ambiguity.

Manual production gate, automated everything else. Full automation to production was technically achievable and was not appropriate for the risk profile. The gate is where a human takes responsibility.

Production promotions produce a complete, retained evidence bundle, and the gate structurally prevents a release that lacks one. Ansible-managed configuration removed the manual steps on the application tier, and the monitoring and logging coverage was extended to the data-handling paths that the ISO-aligned controls cover.

This was a one-month traineeship. The pipeline structure and the evidence model were the durable contributions; the operational ownership stayed with the platform team.