Premier Developer consultant Brian Blackman shares insights around e-signature requirements with Azure DevOps.

The reason for this post is to help customers realize how to satisfy the CFR – Code of Federal Regulations, Title 21, PART 11 ELECTRONIC RECORDS; ELECTRONIC SIGNATURES requirements with Team Foundation Server, Azure DevOps Service and Azure DevOps Server.

The CFR – Code of Federal Regulations, Title 21, PART 11 ELECTRONIC RECORDS; ELECTRONIC SIGNATURES provides regulation through listing requirements needed for compliance. However, there is no specific guidance on the implementation to be complaint.

For example, the text in the link https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 , contains the following:

Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.

This CFR, only gives requirements and no specific guidance. Such as, what is an Electronic Signature. When we released Visual Studio Team System, circa 2005, I helped a customer meet the requirement through the use of a custom control and work item rules. It was up to the customer’s interpretation of the requirement and our implementation to make it complaint. In addition, the customer wanted to ensure that only the proper people could close out a bug for an FDA device.

In this case, the customer came up with using a custom control and work item rules to force an LDAP call requiring authentication (you are who you say you are). The success of the call was documented in the work item, work item state transition rules in Team Foundation Server were used to change the state to closed in this case, and the system provided the rest of the compliance through an immutable history that met the requirement of “signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.”

The system provides for compliance through a combination of the use of security groups in Active Directory and Azure Active Directory and the use of work item state transition rules in Team Foundation Server; this also applies to Azure DevOps.

Through rules in the process templates, security where only members of a proper Azure Active Directory group can change work item state such as approving work, and logging immutably in the work item history, in my example case, the FDA auditors accepted this as satisfactory.

The following link outlines that Microsoft cloud services, including Azure DevOps are audited annually against SOC 1/SSAE 18 and SOC 2/AT Section 101 and ISAE 3402 standards: https://aka.ms/soc_backgrounder. And our services are certified according to ISO/IEC 27001 and ISO/IEC 27018 standards.

In the document from the link you can read that “Azure DevOps Service customers that can’t access the Service Trust Platform can email Azure DevOps at mailto:AzureDevOpsSOCReport@microsoft.com for SOC 1 and SOC 2 reports. Note that this email is to request Azure DevOps SOC reports only.”

Eventually after 2005 we created this page regarding Team Foundation Server 2010 and FDA compliance, which is still relevant today: https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/hh134108(v=vs.100).

If you have any additional questions please reach out to your Application Development Manager.