Regulated e-signature approvals for Merge Requests (CFR part 11)
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Proposal
A distinct, e-signature MR approval process that fully supports Part 11 e-signature requirements.
While we currently document support for Part 11 via this Merge Request #5981 (closed), our current implementation does not fully meet the needs of regulated customers when they must submit evidence from GitLab to gain approval from federal agencies.
My desire in this request is not to modify our current Merge Request approvals, and add complexity for customers who don't need it. I am thinking of a separate/additional approval widget with the complexity required for applicable projects.
- This request comes from a customer who has been working with the FDA for decades. Their understanding of their regulatory requirements is fundamental to their business - this is not negotiable for them, because it is not negotiable from the FDA in order to certify their code changes.
- Competitively, Jira and Bitbucket allow plug-ins to support these e-signature requirements.
Implementation Requirements
1. Merge Request Part 11 e-signature approval(s) are associated directly to a SDLC/Device Development role. Example: Design, Dev, QA, Independent Tester
- The SDLC/Device Development roles do not map 1:1 to any GitLab Role.
- The SDLC/Device Development roles will not be able to be mapped 1:1 to any GitLab subgroup
- Example - within a single project, a user may sometimes approve an MR as an "Independent Tester", and another as "Dev Lead", depending on their level of participation directly in the MR itself.
- Creating/modifying this "Role List" should configurable at the Group and Project level, to meet the needs of the broadest regulatory user base (the labels of the Roles can vary per customer)
2. Merge Requests Part 11 e-signature approvals need to be configurable per Merge Request.
- The MR owner/developer needs the ability to assign approvals, directly from the MR, as the amount of approval requests may vary per MR. This will differ greatly from our current MR approvals which are "pre-loaded" with the options that are configured in the Project settings.
- It can be assumed any ApprovalUsers would have at least Developer access to the GitLab Project/repo in question.
3. There will be an individual e-signature record for each required approval user, stored within the MR.
4. Merge Requests Part 11 e-signature approvals must trigger a re-authentication with GitLab for ApprovalUser. This process includes manually entering in their user name, and then re-entering the password.
- Grabbing the user off the currently logged in session does not meet the requirement - much like the flow you may be familiar with using DocuSign for any legal document, the ApprovalUser will need to actually type in their GitLab user/password at the time of approval.
5. Completed Merge Requests Part 11 e-signature approvals must capture the GitLab username, SDLC/Device Development Role, and correlating timestamp, in the approval record itself.
- The time stamp needs to be directly on the MR e-signature approval record.
6. Completed Merge Request Part 11 e-signatures should be enforceable as a required element, in addition to any standard required MR approval rules (such as for scanners, etc)
7. API export support for all data associated with the MR approval records
- Regulators do not log into systems such as GitLab - data must be submitted as printable/readable data pulled from a SIEM, or in a readable PDF format.
- In addition to exporting the e-signature approvals, our regulated customers need to export the full MR, in its entirety either via the API or in a PDF - this includes all comments and timestamps. (Larger than the scope of this issue)
Example Part 11 e-signature support
- Here is a screenshot of an acceptable e-signature record as shown in Jira using a plugin. The 'Role' here is their SDLC/Device Development Role
Example Workflow which would fulfill implementation requirements
- MR owner is ready for final certification approvals.
- Inside the MR, in the e-signature widget, the MR owner creates an approval request for each individual who needs to approve (I will refer to first approver as ApprovalUser1)
- ApprovalUser1 receives notification in their to-dos that an e-signature approval is requested.
- ApprovalUser1 goes into the MR and clicks "approve" in the e-signature approval widget.
- ApprovalUser1 selects from a drop-down the SDLC/Device Development Role they will be approving under.
- ApprovalUser1 is then prompted to enter in their GitLab user and re-validate the password.
- Resulting completed e-signature is captured in the MR for ApprovalUser1 with their GitLab username, their selected SDLC/Device Development role and timestamp.
CFR Part 11 Requirements for E-signature
Edited by 🤖 GitLab Bot 🤖