How Digital Signature Approvals Support SOC 2, FDA and ISO Change Controls
How Digital Signature Approvals Support SOC 2, FDA and ISO Change Controls
Digitally signed pull request approvals can strengthen software change control by recording who approved a change, under what authority, and—where supported—what they were approving. They can also help prevent a change from being merged before the required approval steps are complete.
That can provide useful evidence during SOC 2 examinations, FDA-regulated reviews and ISO management-system audits. But signatures alone do not make a pull request process compliant. Each organisation must determine which requirements apply and establish the surrounding policies, technical safeguards and records needed to meet them.
What Does a Signed Pull Request Approval Actually Add?
A normal Bitbucket approval indicates that a reviewer approved a pull request. A signed approval adds an explicit signing action, which may be useful where internal change-control policy requires an identified person to formally attest to a review or approval.
Depending on the Workzone hosting version and configuration, this can support:
- Accountability: identifying the reviewer who approved a proposed change.
- Intent: recording a signing role or meaning where the Cloud signature-group functionality is used.
- Traceability: associating an approval with the pull request and relevant source-code revision.
- Enforcement: requiring a configured number of signed approvals before the approved merge path can proceed.
A signed approval is not proof that the code is correct, that the signer was properly trained or authorised, or that every applicable regulatory recordkeeping requirement has been met. Those remain responsibilities of the organisation.
How to Implement Signed Pull Request Approvals
Before enabling signing, define what the signature means in your process. A sensible setup includes five decisions:
- Determine which changes require formal approval. Not every pull request has the same risk or falls within the same regulatory scope.
- Assign authorised reviewers and responsibilities. Define who may sign, for which branches or code areas, and whether separate teams must approve independently.
- Configure signing and merge conditions. Use the appropriate Workzone reviewer/signature quotas and build or task checks. Make sure Bitbucket branch restrictions prevent users from bypassing the intended Workzone-controlled merge workflow.
- Preserve usable evidence. Decide how approval history, the reviewed revision, linked requirements, test results and associated change records will be retained and retrieved.
- Verify the complete control. Test that insufficient signatures actually block the intended merge path; review access, account ownership, exceptions, training and record retention.
Workzone’s current reviewer configuration describes signature-required reviewer groups and quotas. The Cloud setup documentation also explains why corresponding branch restrictions matter for enforcement.
The Role of Digital Signatures in SOC 2
SOC 2 is an assurance-reporting framework, not a regulation that mandates electronic signatures on every software change. Its Trust Services Criteria cover controls relevant to security and, when in scope, availability, processing integrity, confidentiality or privacy.
For a software organisation, an auditor may examine how code changes are authorised, tested, reviewed, implemented and evidenced. A signed pull request approval may help evidence the approval portion of that change-management process—especially when the organisation’s documented policy requires a named approver or separation of duties.
But a signature doesn’t replace secure access controls, testing, deployment procedures, monitoring or evidence that the control operated consistently during the examination period. The relevant question is whether signed approvals support the specific controls the organisation has designed and the auditor is evaluating.
See the AICPA’s SOC reporting and Trust Services Criteria resources for the reporting framework.
The Role of Digital Signatures in FDA 21 CFR Part 11
FDA 21 CFR Part 11 concerns certain electronic records and electronic signatures used under applicable FDA rules. It does not automatically apply to every Git repository or software pull request, even at a company making FDA-regulated products. The organisation must determine which electronic records and signatures are subject to the relevant predicate rules and whether its PR approval is being used as a regulated record.
Where Part 11 does apply, important electronic-signature provisions include:
- §11.50 — Signature manifestations: relevant records must indicate the signer, date/time and meaning of the signature (such as review or approval).
- §11.70 — Signature/record linking: signatures must be linked to their respective records so they cannot be improperly removed or transferred to falsify another record by ordinary means.
- §§11.100 and 11.200 — Identity and signature controls: unique signatures, identity verification, and applicable requirements for signature components and use.
Organisations also need to assess access controls, record integrity, retention, system validation where applicable, and written procedures. Do not assume a personal signing token or username/password prompt, by itself, satisfies every Part 11 signature requirement.
For more detail, read the FDA’s Part 11 scope and application guidance and our more focused article on digital signatures and signing intent in Bitbucket.
The Role of Digital Signatures in ISO-Based Processes
ISO standards serve different purposes. For example, ISO/IEC 27001:2022 sets requirements for an information security management system, while ISO 9001 addresses quality management systems.
Neither standard creates a universal requirement for every pull request to carry a digital signature. An organisation may nevertheless choose signed PR approvals as part of its own risk-based change-management or quality procedures—for example, to document that an authorised reviewer approved a sensitive code change.
In an ISO-related audit, the important evidence is how the organisation defined, implemented and followed its controls, not the presence of a signing button alone. Signature history can be one component of that evidence.
How Signing Works in Workzone Cloud and Data Center
The product’s two hosting environments should not be presented as using identical signing methods.
Workzone for Bitbucket Cloud: reviewers use a personal signature token to sign an approval. Where signature reviewer groups are configured, the reviewer can choose the group or role/intent represented by the signature. Current release notes describe recording the approver name, selected role or intent, and PR Git commit hash in pull request history.
Cloud also supports configured group approval quotas and, where enabled, excluding approvals from pull request committers when calculating Workzone quotas.
Workzone for Bitbucket Data Center: the Data Center compliance documentation describes signed reviewer approvals using username and password, with the number of required signatures set in merge configuration. Relevant Bitbucket branch permissions and Workzone settings still need to make the policy enforceable.
Terminology matters: “Digital Signatures” is Workzone’s feature name, but do not describe these workflows as necessarily using a public-key cryptographic certificate or guaranteeing that a record cannot be tampered with. The technical and regulatory meaning of a digital signature depends on its actual implementation and surrounding controls.
Two Example Change-Control Scenarios
The following are illustrative scenarios, not verified customer case studies.
Medical-device software: A team may require a technical reviewer and a quality representative to sign a change before merging a safety-relevant code update. The PR approval record could be linked to the relevant requirements, testing and release documentation. Whether Part 11 applies—and whether the full process meets it—depends on the regulated record and the organisation’s validated procedures.
Financial-services software: A team preparing for a SOC 2 examination may require a separate authorised reviewer for changes to a payment-related service. Signed PR approvals can provide evidence of that review alongside CI results, access controls, change tickets and deployment records.
In both cases, the valuable outcome is a review control that is followed consistently and can be evidenced. A signature is one part of the process, not the entire compliance outcome.
Bottom Line
Digitally signed approvals can help teams make software-change reviews more deliberate, traceable and enforceable. They are particularly useful when a defined change-control policy requires a named reviewer, a recorded signing intention or approval from specific groups.
But compliance with SOC 2, FDA requirements or ISO standards comes from the complete set of applicable controls and organisational practices, not from installing a signing feature.
For configuration guidance, see the Workzone Cloud digital signatures guide or the Workzone Data Center compliance documentation.
Make Signed Pull Request Approvals Part of Your Bitbucket Workflow
Want to replace ad hoc sign-offs with defined reviewer rules, required approval signatures and recorded review history? Explore Workzone for Bitbucket Cloud on the Atlassian Marketplace, or view the Data Center version, to see how Workzone can support your organisation’s change-control process.
This article explains product capabilities and common control considerations. It is not legal, regulatory, audit or certification advice; assess requirements with your quality, compliance and assurance specialists.
By Sean Manwarring, Head of Marketing at Izymes
Published 17 January 2023 · Updated 26 October 2026
