Who approved this release? Building a change approval log that holds up

A pipeline log shows that commit a3f12c9 was merged at 14:02 UTC and deployed to production at 14:11 UTC. It does not show that anyone with authority decided this change should reach production, what conditions they accepted, or what scope they signed off. The pipeline runs whether the decision was deliberate or automatic. The two records answer different questions and auditors know it.

When a SOC 2 examiner samples a change and asks for evidence of approval, a green pipeline check is rejected. What they accept is an attributed record showing a named person, with a defined role, approving a defined scope at a defined moment.

1. Change identifier. Release version or change ID, traceable to the deployed artifact and the originating ticket.
2. Scope statement. What is included, what is excluded, what is deferred. A one-line summary is not enough.
3. Conditions and accepted risks. Known limitations, mitigations, and the explicit acknowledgement that they are accepted for this release.
4. Named authority. One person, with role, who held the authority to say yes. Not a team, not a channel, not "the release group".
5. Attributed timestamp. Server-recorded date and time of the approval action, bound to the named authority and immutable after the fact.

Every other field is optional. These five are not.

The three failure modes are predictable. First, the authority is a team alias: "approved by release-team@". When an auditor asks who specifically, the answer is a shrug. Second, the conditions are missing: the record says "approved" but does not capture the known iOS limitation, so when iOS breaks the next week, no one can show the limitation was deliberate. Third, the record is mutable: the ticket was edited, the wiki page was rewritten, the channel was archived. Mutability voids evidentiary value.

A purpose-built decision registry solves all three by design. Authority is bound to a specific user account, conditions are first-class fields, and finalisation locks the record at the database level.

The questions are remarkably consistent across SOC 2, ISO 27001, internal audit, and client contractual reviews:

• Show me the approval for this specific change.
• Who held the authority to approve it, and under what role?
• What was the scope at the moment of approval?
• What conditions, exclusions, or risks were accepted?
• Has the record been altered since approval?

If your current change approval log cannot answer all five in under a minute, it is not a log. It is a hope.