Release Compliance Checklist Workflow
Turn regulatory and contractual release obligations into a machine-checked list that blocks shipping rather than reminding people.
Objective
Ensure every external obligation (data handling, licensing, audit artifacts) is verifiably met before a release ships.
Environment
- A compliance requirement list from legal or the regulator
- CI hooks able to fail builds
- Owners for each obligation area
Steps
1. Inventory the obligations
Collect every external requirement that attaches to a release: license compatibility, data residency, privacy notices, audit logs, accessibility statements.
Expected state: A single list exists with each obligation, its source, and its owner.
2. Classify checkable versus judgment
Split obligations into machine-checkable items (license scan, header presence, SBOM) and human-judgment items (privacy wording), each with its verification mode.
Expected state: Every item is typed as gate (CI fails) or review (sign-off required).
3. Automate the gates
Implement machine checks in CI: license scan against the allow list, SBOM generation, required headers and notices present, audit log enabled.
Expected state: A build fails with a named obligation when a gate is violated.
4. Route judgments to named reviewers
For human-judgment obligations, require sign-off from the owning role (legal, privacy officer) recorded on the release checklist.
Expected state: The release record contains named approvals for every judgment item.
5. Archive the evidence bundle
On release, bundle the checklist state, gate outputs, and sign-offs into an immutable release record for auditors.
Expected state: An auditor request is answered by pointing at the bundle, not by archaeology.
Expected outcome
A release process where compliance is enforced by failing builds and named sign-offs, producing audit evidence as a by-product of shipping.
Verification
A redacted release bundle shows every obligation with either a passing gate output or a named sign-off, and deliberately breaking a gate in a test build fails CI.
Cleanup
Review obligation list quarterly against contract and regulatory changes.
Compliance that cannot block is a suggestion
A compliance checklist in a wiki reminds people who are busy; the same list wired into CI blocks people who are busy. The workflow converts obligations into gates that fail builds and sign-offs that name humans, then archives the evidence automatically.
release checklist v1.8.0 (compliance view)
GATE license-scan PASS 0 unknown, 3 copyleft (allowed)
GATE sbom-generated PASS CycloneDX, 1,204 packages
GATE privacy-notice PASS version 2026-10 present
GATE audit-log-enabled PASS config verified in staging
REVIEW data-residency SIGNED privacy-officer@ 14:02Z
REVIEW accessibility SIGNED a11y-lead@ 15:11Z
------------------------------
all obligations met -> release unlocked
bundle: release-v1.8.0-evidence.tar (immutable)Gates for the mechanical, names for the judgment
License scans and SBOM generation are mechanical and belong in CI where they cannot be forgotten. Data-residency phrasing and accessibility judgments need a human decision, and those decisions must carry a name and timestamp, because that is what an audit actually asks for.
The evidence bundle is the deliverable
Audits conducted after the fact through email archaeology cost days and satisfy nobody. Assembling the evidence during release, as a by-product of gates that already ran, converts the audit answer into a file transfer.