Standards Have to Be Executable

In a regulated environment (SOC 2, ISO 27001 and similar), every change has to answer three questions: who made it, why, and which approved piece of work it belongs to. Commit messages and pull-request titles are where that answer lives, so they stop being a matter of taste and become part of the audit trail.

Write it down, then make it run

A wiki page and a reminder in stand-up are a good start, and they’re never enough on their own: people are busy, and a standard that depends on memory drifts. The dependable version is executable:

• CI checks that verify commit messages and pull-request titles against the agreed format, including the link to a ticket, and fail the pipeline when they don’t match.
• Cheap compliance. A clear format and an error message that says exactly how to fix it, so a failed check costs seconds, not a context switch.
• Warning mode first. Run the checks as warnings for a week or two before making them blocking. Everyone adjusts, and edge cases in the format show up before they ever stop a release.

Explain the reason, not just the rule

People follow a check they understand and route around one they don’t. The reason that lands is practical: when an audit asks about a change, a good commit line answers it in seconds, while reconstructing the context months later costs far more.

The result

Every change links to its ticket, and anyone can go from a ticket to the exact lines that changed. The same trail helps long after the audit: in incident reviews, in onboarding, and whenever someone asks “why is it like this?”.

The general lesson

If a standard matters, make it executable: a check, a template or a sensible default. Documentation describes the standard; automation is what keeps it.

Related notes

Definition of Done · Slicing Pull Requests · Golden Paths