Part 11 electronic signatures on pull requests
21 CFR Part 11 is one of the shorter regulations you will ever read, and one of the most argued about. For electronic signatures it boils down to a handful of demands: each signed record must show the signer's name, the date and time, and the meaning of the signature (11.50); signatures must be bound to their records so they cannot be excised or copied onto something else (11.70); each signature must be unique to one individual (11.100); and a non-biometric signing act must use at least two distinct identification components (11.200).
People building a QMS on GitHub tend to assume a pull request approval covers this. It doesn't, and it is worth being precise about why. The question has also gained urgency: as I argued in my response to OpenRegulatory, most regulatory document preparation now runs through AI agents, and the signing ceremony is exactly the checkpoint where an accountable human takes over from the automation. That checkpoint had better be a real signature.
Where a bare approval falls short
A GitHub approval is authenticated, but the authentication happened when the session started, possibly days ago. The approval itself is one click inside that session. There is no second identification component at the moment of signing, which is the moment 11.200 cares about. The meaning of the click is implicit; "I approve this diff" is not a declared signature meaning. And the approval attaches to a branch head, which can move. GitHub can dismiss stale reviews when new commits arrive, but "the platform usually invalidates outdated approvals" is a weaker statement than "this signature is bound to this exact revision", and an auditor will notice the difference.
So the review click is a fine engineering control and a poor signature. The baseline treats it as exactly that: the entry point of a signing ceremony, not the ceremony itself.
What the signing flow adds
It starts before anyone reviews. A pull request that changes controlled documents must declare, in its body, the meaning of the signature, the signer roles, and how many signatures are required. A CI gate rejects the PR if the declaration is missing or malformed; I know because it has rejected mine. Signatory reviewers are then assigned automatically from the signer registry, a JSON file mapping GitHub accounts to named individuals and quality roles.
When a signatory approves, the signature worker, a Cloudflare Worker sitting outside GitHub's trust boundary, intercepts the event and challenges the signer for a time-limited PIN. That PIN is the second identification component: something beyond the session that produced the click, tied to this signing act and this signing act only. No PIN, no signature; the approval alone counts for nothing.
Only after verification does the worker record the signature. The record binds four things together: the signer's identity (the registry entry with the person's full name, not just a username), the declared meaning, the timestamp, and the exact commit SHA that was signed. The result is a cryptographically bound attestation, published with the release it belongs to, with its own title page for human readers, under an evidence tag that is never moved or reused. Tamper with any element and the binding breaks visibly.
Walk that against the regulation: name, time and meaning shown on the record (11.50); binding that survives copy and excision attempts (11.70); one registry entry per human (11.100); session plus fresh PIN as two distinct components (11.200). Each demand has a mechanism you can point at during an audit, which beats each demand having a paragraph in a procedure.
What remains yours
I want to be direct about the limits, because Part 11 compliance is a property of an operating installation, never of a piece of software, and any vendor telling you otherwise is selling something.
Adopters still have to validate the signature worker and the surrounding workflows for their intended use; the baseline ships the system and the V&V work instruction, not your validation evidence. The one-time certification letter to FDA, stating that electronic signatures in your system are the legally binding equivalent of handwritten ones, is required by 11.100 and only your company can send it. Access control and two-factor policy on your GitHub organization are yours to configure and enforce. And your people need to be trained on what their signature means before the first one is collected, which is a procedure and a training record, not a workflow.
The signature worker, its deployment workflow and the gates around it are all in the open at github.com/AliakseiT/dearauditor-qms-baseline. If your assessment finds a gap in the reasoning above, the repository accepts issues, and I would genuinely rather hear about it there than in an audit.