Audit-Ready CI/CD for Regulated Software: Policy Gates, Evidence and Provenance
How to build a delivery pipeline that generates its own compliance evidence, so releases get faster as audit rigour increases.
Who this is not for: If your software carries no regulatory obligation and your team ships without external audits, this architecture adds overhead you don't need. Start with a standard delivery pipeline instead.
An audit-ready CI/CD pipeline is one where every build automatically produces the evidence an auditor would ask for: policy-gate pass/fail results, a signed software bill of materials, build provenance linking each artefact to its source commit, and separation-of-duty logs. Instead of pausing releases to gather documents, the pipeline generates compliance records as a by-product of normal delivery.
Executive Brief
- Audit-ready CI/CD embeds policy gates, evidence collection and artefact provenance directly into the pipeline so compliance is a by-product of every build, not a manual post-release activity.
- Manual evidence gathering creates a batching spiral: teams slow down releases to reduce audit burden, which increases batch size and risk per release.
- A reference architecture centred on policy-as-code (OPA, Conftest, Kyverno), signed artefacts (Sigstore/Cosign) and SLSA build provenance addresses control types common across multiple regulated frameworks.
- The same pipeline structure maps to HIPAA, IEC 62304, PCI-DSS v4.0, 21 CFR Part 11, FedRAMP, SOC 2 Type II and other frameworks. What changes per regulation is which control types apply, not the underlying architecture.
- Automation fails at month six if evidence review itself stays manual: unsigned metadata accumulates, policy exceptions become permanent, and the gap between what the pipeline records and what reviewers actually examine widens.
The Batching Spiral: Why Manual Audits Slow Releases and Increase Risk
Most teams that operate under regulatory constraints don't start with a broken pipeline. They start with a reasonable one and then bolt on manual checkpoints as audit requirements accumulate. A compliance officer asks for release sign-off documentation. A quality team adds a review gate that requires a signed PDF before deployment. An internal audit finds that separation of duties isn't logged, so someone writes a spreadsheet to track approvals.
Each addition makes sense in isolation. Collectively, they create a batching spiral.
The more manual steps a release requires, the more expensive each release becomes in calendar time and coordination. Teams respond by batching more changes into fewer releases. Larger batches carry more risk. When something goes wrong, the blast radius is bigger, the root-cause investigation is longer, and the corrective action report takes more time to write. Which leads to calls for stricter manual controls. Which makes releases more expensive. Which leads to even larger batches.
A team that shipped weekly now ships monthly. A team that shipped monthly now ships quarterly. Some teams run a quarterly "release week" that consumes the entire engineering organisation for days. The irony is hard to miss: the controls meant to reduce risk have created the conditions that maximise it.
The way out is to move evidence collection into the pipeline itself. When every build automatically produces signed attestations, SBOMs and policy-gate logs, the per-release cost of compliance drops to near zero. Releases can be small again. And smaller releases are inherently easier to audit.
Four Questions for Regulated Delivery
Stonetusker uses a four-question framework to evaluate any delivery pipeline, regardless of industry. For regulated software, each question takes on a specific meaning.
1. What has to be true before this ships (the gate)
In a regulated context, the gate isn't just "tests pass." It includes policy checks: does this build meet the required controls for its target environment? Are all required approvals recorded? Has the static analysis run completed, and did it find anything that requires remediation before release?
Policy-as-code tools like OPA, Conftest or Kyverno let you express these conditions as machine-readable rules. The pipeline evaluates them automatically. A build that violates a rule does not proceed. There's no human in the loop to wave it through under deadline pressure.
2. How we prove it was true six months later (the evidence)
An auditor arriving six months after a release will ask for the same information your gate checked at build time. If that information lives in a CI log that gets rotated, or in a Slack thread, or in someone's memory, you're rebuilding evidence retroactively.
Audit-ready pipelines write evidence to immutable storage at build time. Every policy decision, every test result, every approval and every artefact signature gets recorded as a structured, timestamped, signed record. Six months later, there's nothing to reconstruct because nothing was lost.
3. What undo costs (the rollback)
Rollback in regulated environments has documentation requirements that don't apply in unregulated ones. You may need to record why the rollback happened, what customers were affected, and whether the issue constitutes a reportable event under your applicable framework. The pipeline should capture rollback events with the same evidence rigour as forward deployments.
4. What a test environment physically has to be (the harness)
For some regulations, the test environment must mirror production to a specific degree. Medical device software under IEC 62304 carries different environment requirements than a payment processor under PCI-DSS. The harness question forces you to define this upfront rather than discovering a gap during an audit.
Reference Architecture: Gates, Evidence and Provenance
The reference architecture below is structured in six stages. It's a conceptual model, not a prescriptive tool list; specific tools appear in the stack table that follows.
- Source control with signed commits. Every code change carries a verified author identity. Branch protection rules enforce review requirements and prevent direct pushes to release branches. The audit trail begins here.
- Policy gate at build entry. Before the build starts, a policy-as-code engine evaluates admission rules: is this change from an authorised contributor? Does the branch policy permit this merge? Are all required approvals present? Failed checks block the build and log the reason.
- Build with provenance generation. The build system produces artefacts alongside SLSA provenance metadata. The provenance record links each artefact to its source commit, build configuration, builder identity and build timestamp. This record is signed by the build system, not by a human.
- SBOM generation and vulnerability scan. A software bill of materials is generated from the build output and scanned against known vulnerability databases. The SBOM, the scan results and the vulnerability disposition (accepted, mitigated, or blocking) become part of the evidence package.
- Artefact signing and registry push. The final artefact is signed using keyless signing (Sigstore/Cosign). The signed artefact, its SBOM and its provenance record are pushed to an immutable artefact registry. Nothing unsigned enters the registry.
- Deployment gate with separation of duties. A second policy gate runs before deployment. This gate enforces separation of duties: the person who approved the code change cannot be the same person who approves the deployment. The deployment decision, the approver identity and the timestamp are recorded as signed evidence.
The architecture diagram (described above as a six-stage pipeline) should be rendered as a horizontal flow for visual materials, with each stage as a labelled box and evidence outputs shown as downward branches into an evidence store.
Tool Stack for Audit-Ready Pipelines
| Pipeline Stage | Tool / Standard | What It Does |
|---|---|---|
| Policy gates | OPA / Conftest / Kyverno | Evaluates declarative policies against pipeline state; blocks non-compliant builds |
| Artefact signing | Sigstore / Cosign | Keyless signing of container images and other artefacts; verifiable without managing key infrastructure |
| Build provenance | SLSA framework | Generates signed provenance metadata linking artefacts to source, builder and build configuration |
| SBOM generation | CycloneDX / SPDX | Produces machine-readable software bills of materials in standardised formats |
| Vulnerability scanning | Trivy / Grype | Scans artefacts and SBOMs against vulnerability databases; produces disposition records |
| Separation of duties | Branch protection + deployment approval gates | Enforces and logs that build approvers and deployment approvers are different identities |
Stonetusker's Secure Delivery service covers the design and implementation of these pipeline components within your existing CI/CD platform.
How the Architecture Maps to Regulatory Frameworks
The table below shows which control types from the reference architecture address requirements in each framework. This is a mapping of control categories, not a compliance checklist. Each regulation has its own primary text, and your compliance and legal teams should validate how these controls satisfy your specific obligations.
| Framework | Control Types Addressed | Primary Source |
|---|---|---|
| 21 CFR Part 11 | Electronic signatures, audit trails, access controls, record integrity | 21 CFR Part 11 (eCFR) |
| IEC 62304 | Software configuration management, traceability, change control | IEC 62304 traceability in CI/CD |
| PCI-DSS v4.0 | Change management, access control, vulnerability management, audit logging | PCI SSC Document Library |
| FedRAMP | Configuration management, continuous monitoring, access control | FedRAMP.gov |
| SOC 2 Type II | Change management, logical access, system operations, risk assessment | AICPA Trust Services Criteria |
| HIPAA | Access controls, audit controls, integrity controls, transmission security | HIPAA safeguards mapped to CI/CD |
| FERPA | Access controls, audit logging, data integrity verification | Student Privacy Policy Office |
| AAMI TIR45 | Software development lifecycle controls, validation, risk management | AAMI TIR45:2012 (purchase required) |
Notice that the control types repeat across frameworks. Access controls, audit trails, change management and integrity verification appear in nearly every row. That's the practical insight: one well-designed pipeline architecture addresses the structural requirements of multiple regulations. The variation is in specifics (which records to retain, for how long, with what granularity), not in the fundamental approach.
For healthcare-specific implementations, see Stonetusker's coverage of platform engineering for healthcare and medical device companies and the detailed article on why medical AI cannot use a SaaS release process.
What Breaks at Month Six
Most audit-ready pipeline projects start well. The first build that generates a signed SBOM feels like a win. The first policy gate that blocks a non-compliant merge request proves the concept. Leadership signs off. The team moves on to other priorities.
Six months in, things start to drift.
Policy exceptions accumulate. Someone needed to bypass a gate for an urgent fix, and the exception was never revoked. Then another. Then a third. The policy engine still runs, but it's approving builds that wouldn't have passed the original rules. Nobody reviews the exception log because nobody owns it.
SBOM generation keeps running, but the vulnerability disposition process stalls. New CVEs flag against known dependencies, and without a clear owner for triage, the alerts become noise. Teams stop reading them. An auditor who checks six months of scan reports finds dozens of unacknowledged findings.
Evidence exists but isn't verified. The pipeline dutifully writes provenance records and signed attestations to storage. But if no one ever reads those records, errors in the evidence chain go unnoticed. A signing key rotation might break the verification chain. A schema change in the provenance format might produce records that look valid but aren't parseable by the auditor's tools.
The fix isn't more automation. It's automation with review. Someone (or some process) needs to regularly verify that the evidence chain is intact, that policy exceptions are time-bounded and re-evaluated, and that vulnerability dispositions are current. The pipeline produces the data. A human reviews whether the data is still trustworthy.
Build It or Have It Built
Whether you build this architecture in-house or bring in outside help depends on a few factors:
Complexity of your regulatory landscape. A team operating under a single framework (HIPAA alone, or PCI-DSS alone) faces a simpler mapping exercise than a team whose products span medical devices, payment processing and federal data. Multi-framework pipelines require careful policy design to avoid contradictory gate rules.
Existing CI/CD maturity. If your current pipeline already has automated testing, artefact registries and infrastructure as code, adding policy gates and provenance is an extension. If you're still running builds manually or deploying from developer laptops, the prerequisite work is substantial.
Internal policy-as-code expertise. Writing OPA policies or Kyverno rules is a specialised skill. Teams with strong infrastructure engineering backgrounds can pick it up. Teams without that bench strength will move slowly and make mistakes that are expensive to discover during an actual audit.
Timeline pressure. Regulatory deadlines don't move. If your next audit is in four months and your pipeline has no evidence collection, the learning curve for building this from scratch may not fit.
Stonetusker's approach is a fixed 90-day engagement where the pipeline is built alongside your team, not handed over as a finished product. The goal is that your engineers can maintain and extend the architecture after the engagement ends.
If you're unsure where your current pipeline stands relative to audit readiness, Stonetusker's TuskerGauge readiness check gives you a structured assessment to start from.
For teams preparing for investor or acquirer scrutiny, the audit-ready pipeline also addresses the technical due diligence requirements covered in engineering readiness for technical due diligence and what investors check during due diligence.
The Compliance Connection: Cross-Regulation Architecture
The deeper pattern across these frameworks is that they're converging. PCI-DSS v4.0 added requirements for software supply chain integrity that overlap with what SLSA already provides. The EU Cyber Resilience Act will require SBOM generation for connected products. FedRAMP continuous monitoring aligns with the same evidence-chain infrastructure that SOC 2 Type II auditors examine.
Building for one regulation and then re-engineering for the next is a recurring cost that compounds. Building a cross-regulation evidence architecture from the start means each new framework becomes a policy configuration exercise rather than a pipeline redesign.
Stonetusker's policy-as-code and DevSecOps coverage goes deeper on how this works for healthcare AI startups specifically.
Frequently Asked Questions
What makes a CI/CD pipeline audit-ready?
An audit-ready pipeline automatically generates the evidence an auditor would request as a by-product of every build. This includes three components: policy gates that enforce compliance rules before code proceeds, artefact provenance that links every build output to its source commit and build configuration, and signed records stored immutably so they can be retrieved months or years later without reconstruction. The key distinction from a standard pipeline is that compliance documentation is a build output, not a post-release activity.
Which regulations require build provenance?
Any regulation that mandates traceability between a deployed artefact and its source code effectively requires some form of build provenance. 21 CFR Part 11 requires audit trails for electronic records. IEC 62304 requires software configuration management and traceability. PCI-DSS v4.0 requires change management controls. SOC 2 Type II examines change management and system operations. The specific provenance depth varies by framework, but the structural requirement is consistent.
How does policy-as-code work in a CI/CD pipeline?
Policy-as-code replaces manual compliance checklists with machine-readable rules that the pipeline evaluates automatically. Tools like Open Policy Agent (OPA), Conftest and Kyverno let you write policies as declarative files (typically Rego for OPA, or YAML for Kyverno). The pipeline sends its current state (build metadata, approval records, scan results) to the policy engine, which returns a pass or fail decision. Failed checks block the pipeline and log the specific rule that was violated, creating an auditable record of every policy evaluation.
Can audit evidence be generated automatically?
Yes. Every stage of the pipeline described in this article produces structured evidence as a standard output: policy-gate decisions, test results, SBOM contents, vulnerability scan outcomes, artefact signatures and deployment approvals. These records are written to immutable storage at build time, signed and timestamped. The result is a complete evidence package per release that requires no manual assembly. What can't be fully automated is the review of that evidence, which is where month-six failures tend to occur.
What is the difference between signed artefacts and build provenance?
Artefact signing (using tools like Sigstore/Cosign) proves that a specific artefact hasn't been tampered with since it was signed. It answers "is this binary the one we built?" Build provenance (as defined by the SLSA framework) goes further: it records how the artefact was built, from which source, using which build system, with which configuration. It answers "where did this binary come from, and can we reproduce it?" Signing verifies integrity. Provenance verifies origin. An audit-ready pipeline needs both.
Is Your Delivery Pipeline Audit-Ready?
If your team is spending more time preparing for audits than shipping software, the pipeline architecture described here can reverse that. Take a structured readiness assessment, or book a conversation to see how the architecture maps to your regulatory landscape.
Talk to Stonetusker