Digital Signatures and Signing Intent in Bitbucket: Supporting FDA 21 CFR Part 11 and ISO Controls

Digital Signatures and Signing Intent in Bitbucket: Supporting FDA 21 CFR Part 11 and ISO Controls

Workzone can help organisations implement electronic-signature controls around Bitbucket pull request approvals. In Workzone Cloud, reviewers can sign an approval with a personal signature token, select a role or signing intent, and have the approver, intent and pull-request commit hash recorded in the pull-request history. Workzone can also require a defined number of signed approvals before the pull request is allowed to merge.

These capabilities can support an organisation’s FDA 21 CFR Part 11, ISO/IEC 27001, ISO 9001 or other change-control requirements.

They do not, by themselves, make Bitbucket, Workzone or an organisation compliant. Compliance depends on the complete system, its intended use, applicable regulatory requirements, validation, access controls, record retention, procedures, training and operation of those controls.

Regulatory note: this article explains product capabilities and how they relate to selected regulatory concepts. It is not legal, quality-system or regulatory advice.

Key Takeaways

• 21 CFR Part 11 does not automatically apply to every software pull request.
• Where a pull-request approval forms part of a regulated electronic record, Part 11 includes requirements around signer identity, signature meaning, record linkage, access, audit trails and system controls.
• Workzone Cloud records the approver, selected role/intent and pull-request commit hash in the PR history and can require signed approvals before merge.
• Signing intent is particularly relevant to 21 CFR §11.50, which requires the meaning of an electronic signature to be associated with the signed record.
• ISO/IEC 27002:2013 referenced in the original 2024 article is outdated. The current edition is ISO/IEC 27002:2022, and it is guidance—not a certifiable standard that mandates digital signatures for pull requests.

Does FDA 21 CFR Part 11 Apply to Pull Requests?

Not automatically.

FDA’s current Part 11 guidance explains that Part 11 applies to electronic records and electronic signatures used in circumstances where records are required by FDA predicate rules and are maintained electronically.

That means a software pull request is not subject to Part 11 merely because it contains source code.

In a regulated software-development lifecycle, however, an organisation may define code-review and approval records as part of its controlled change process. In that situation, the electronic approval record may need to satisfy requirements established by the organisation’s predicate rules, quality system and validated process.

The right starting question is therefore:

“Is this pull-request approval part of an electronic record that our regulated process requires us to create, maintain or approve?”

If the answer is yes, the organisation should map the complete system and workflow against the applicable requirements rather than assuming that adding an electronic-signature feature is sufficient.

What 21 CFR Part 11 Requires Around Electronic Signatures

Part 11 uses the term electronic signature. Workzone uses digital signature as the product term for its signed pull-request approval feature.

Several Part 11 sections are particularly relevant when evaluating a signed approval workflow:

Part 11 requirement	What it means in practice	How Workzone can support the workflow
§11.50 — Signature manifestations	The signed record must show the signer’s name, date/time and meaning of the signature, such as review, approval, responsibility or authorship.	Workzone Cloud records the approver and selected role/intent in the pull-request history. The organisation should verify that its complete record captures and retains all required attributes, including timing, in the required human-readable form.
§11.70 — Signature/record linking	The signature must remain linked to the electronic record so it cannot ordinarily be removed or transferred to falsify another record.	Workzone records the pull-request Git commit hash alongside the signed approval, helping associate the approval with the code version being reviewed. The organisation still needs to validate the integrity and retention of the complete record.
§11.100 — General requirements	Electronic signatures must be unique to an individual, and the organisation must verify that person’s identity before establishing the signature.	Workzone provides an individual signing mechanism, but identity verification, issuance, ownership and lifecycle procedures remain organisational responsibilities.
§11.200 — Signature components and controls	Non-biometric signatures are subject to requirements around identification components and control by the genuine owner.	Workzone’s signing flow provides an additional personal signing credential, but the organisation must assess the full authentication and signing flow against its applicable Part 11 interpretation and validation.
§11.10 — Closed-system controls	Requirements extend beyond the signature itself to system validation, access restrictions, audit trails, record protection, authority checks, training and written accountability policies.	Workzone can enforce parts of the approval and merge workflow, but these wider controls cannot be satisfied by the app alone.

This is why saying that a single plugin “makes Bitbucket Part 11 compliant” is too broad.

The signature is only one component of the regulated electronic-record system.

Why Signing Intent Matters

Signing intent is not just additional metadata.

21 CFR §11.50 requires a signed electronic record to include the meaning associated with the signature, with examples including review, approval, responsibility and authorship.

Workzone Cloud introduced a role/intent selector for digitally signed pull-request approvals so the reviewer can record the capacity or intention under which they are signing.

For example, an organisation might distinguish between:

• Technical Review — the reviewer assessed the implementation;
• Test Approval — the reviewer is signing in a testing or verification role;
• Quality Approval — the reviewer is acting as the appropriate quality representative;
• Release Approval — the reviewer authorises the change to proceed into the release process.

The exact roles and meanings should come from the organisation’s documented procedure rather than from a generic list.

How a Signed Workzone Cloud Approval Works

Current Workzone Cloud documentation describes the signed approval process as follows:

1. The organisation configures reviewer rules that require digitally signed approvals.
2. A reviewer who needs to sign creates and uses a personal signature token.
3. When approving the pull request, the reviewer enters the signature token.
4. If signature groups apply, the reviewer selects the group or role they represent.
5. Workzone records the signed approval information in the pull-request history.
6. The configured approval quota or merge condition can prevent the pull request from merging until the required signed approvals are present.

Workzone’s March 2024 Cloud release notes state that the approver name, selected role/intent and pull-request Git commit hash are recorded in the pull-request history.

Signature Reviewer Groups and Separation of Responsibilities

Some change-control processes require approval from defined functions rather than simply “any two developers”.

For example, a policy might require:

• one technical representative;
• one testing representative;
• one quality representative.

Workzone can configure reviewer groups that require digital signatures and set approval quotas for those groups.

This can help translate a documented responsibility model into the Bitbucket pull-request workflow.

It is still the organisation’s responsibility to determine:

• which roles are required;
• who is authorised to act in each role;
• whether separation of duties is required;
• how role membership is maintained;
• what happens when an employee changes role or leaves the organisation.

Workzone’s newer independent-review option can also exclude approvals from people who contributed commits when calculating the Workzone approval quota, which may be useful where an organisation’s procedure requires review independent from the author or committer.

For more on that control, see Workzone reviewer and approval configuration.

What About ISO/IEC 27001 and ISO/IEC 27002?

The ISO wording in the original 2024 version of this article needs an important correction.

ISO/IEC 27002:2013 is no longer the current edition. The current standard is ISO/IEC 27002:2022.

More importantly, ISO/IEC 27002 is a set of information-security control guidance. It is not the standard an organisation is certified against.

ISO/IEC 27001:2022 contains the requirements for an Information Security Management System (ISMS), while ISO/IEC 27002 provides guidance on information-security controls.

Neither standard says that every software pull request must use a digital signature.

A signed and enforceable pull-request approval workflow can, however, form part of an organisation’s chosen controls around areas such as:

• access and authority;
• software change management;
• traceability and accountability;
• logging and monitoring;
• protection of information integrity.

Whether that control is necessary, and how it should operate, should come from the organisation’s risk assessment, policies and Statement of Applicability.

Cloud and Data Center Use Different Signing Mechanisms

Workzone supports signed pull-request approvals in both Bitbucket Cloud and Bitbucket Data Center, but the implementation is not identical.

• Workzone Cloud: current documentation describes a personal signature token and the role/intent selection workflow discussed above.
• Workzone Data Center: current Izymes documentation describes digitally signed approvals using the reviewer’s username and password, with a required signature count available as a merge condition.

For a regulated workflow, validate the exact behaviour of the hosting model you use rather than assuming the Cloud and Data Center implementations provide identical evidence or controls.

What Workzone Does—and Does Not—Provide

Workzone can help with	Your organisation still needs to own
Requiring signed pull-request approvals	Determining whether Part 11 or another regulatory requirement applies
Capturing a role/signing intent in Workzone Cloud	Defining approved signing meanings and responsibilities
Recording approver and pull-request commit information	System validation, record-retention requirements and evidence strategy
Requiring signatures from configured reviewer groups	Identity verification, user lifecycle and role-authorisation procedures
Blocking merge until configured signature requirements are met	Preventing bypass across the complete system and documenting the validated configuration
Creating approval history within the Bitbucket workflow	Training, written procedures, accountability policies and periodic control review

That is the safer and more useful way to describe Workzone in a regulated environment:

it provides technical controls that can be incorporated into a compliant software change-management process.

A Practical Implementation Checklist

If signed Bitbucket approvals will form part of a regulated process:

1. Determine applicability. Identify the predicate rule, quality-system requirement or internal control that makes the approval record necessary.
2. Define the signature meaning. Document what “Technical Review”, “Quality Approval”, “Release Approval” or other signing intents actually mean.
3. Define authorised roles. Decide who can sign in each capacity and how that authorisation is maintained.
4. Configure enforcement. Require the appropriate signed approvals and prevent the protected branch from being merged through an uncontrolled alternative path.
5. Verify the record. Confirm that the retained record contains the signer, timing, meaning, code/version reference and other evidence your procedure requires.
6. Validate the system and configuration. Test that the workflow behaves consistently and cannot be bypassed in ways your regulated process prohibits.
7. Document and operate the process. Maintain training, access management, retention, change control and periodic review around the technical configuration.

The technology should enforce the procedure the organisation has defined—not substitute for defining that procedure.

When Normal Bitbucket Approvals May Be Enough

Not every development team needs digitally signed pull-request approvals.

If your software changes are not part of a regulated electronic-record process and your internal controls only require ordinary peer review, Bitbucket’s native approval and merge-check features may already be sufficient.

Digital signatures add the most value when there is a specific requirement for stronger signer attribution, documented intent, role-based approval or retained evidence.

Bottom Line

For organisations that need stronger evidence around software change approval, Workzone can bring the signing action directly into the Bitbucket pull-request workflow.

The most important capabilities are not simply “a signature”:

• the signer is associated with the approval;
• the meaning or role of the approval can be recorded;
• the approval can be tied to the pull-request commit;
• required signature quotas can be enforced before merge;
• the approval becomes part of the pull-request history.

Those capabilities can support FDA 21 CFR Part 11 and ISO-aligned change-control processes.

But the compliance outcome still belongs to the organisation and the complete validated process.

Want to Configure Signed Pull Request Approvals?

See the Workzone Cloud Digital Signatures documentation and the Workzone Data Center signed-approval documentation.

For the wider change-control workflow around reviewers, approvals and merge enforcement, see Securing the Software Development Process and Optimizing Bitbucket Workflows.

By Sean Manwarring, Head of Marketing at Izymes
Published 14 March 2024 · Updated 13 October 2026