Understanding Part 11 Compliance in Jira Cloud

Is Jira Cloud compliant with 21 CFR Part 11? Some people say yes, and some say no.

So, what’s the correct answer?

By default, Atlassian Jira Cloud is not fully Part 11 compliant. However, you can configure it to be Part 11 compliant if you know where the gaps are.

In this article, we’ll discuss what Part 11 compliance entails, what Atlassian provides us by default, and what we must do to close the gaps.

Understanding 21 CFR Part 11

What is 21 CFR Part 11?

Key Requirements of 21 CFR Part 11

• Authentication and Authorization: Systems must ensure that only authorized individuals can access electronic records.
• Data Integrity: Electronic records must be protected from improper alteration, loss, or destruction.
• Audit Trails: Any changes or modifications to electronic records must be logged and traceable to the individual who made the change.
• Electronic Signatures: Electronic must be as trustworthy and reliable as their paper counterparts. This includes ensuring that electronic signatures are certified to be legally binding.
• Validation: Software systems used for creating, modifying, maintaining, and transmitting electronic records and signatures must be validated to ensure accuracy, reliability, and the ability to identify altered records.

Compliance Challenges

Most IT applications are not Part 11 compliant by default. Common compliance gaps include:

• Data integrity of approved records: Many modern IT apps do not prevent records from being altered, moved, or deleted after they have been reviewed and approved. They may protect records by enforcing user permissions, but those permissions are often not based on the workflow state of the record.
• Insufficient audit trails: 21 CFR Part 11 requires all alterations of an electronic record to be recorded in the audit history. Auditing the deletion of records is the most common compliance gap.
• Electronic signatures: Part 11 has strict requirements that define a compliant electronic signature. This includes rules about how signees must be authenticated, the signature details that are captured and displayed, and the ability to detect altered signatures or altered records with signatures.
  
  It is unlikely for an electronic signature feature to comply with 21 CFR Part 11 unless it was explicitly designed to do so.

Off-the-shelf, Jira Cloud contains all three of these compliance gaps. (But keep reading…they can be closed through configuration.)

Part 11 Compliance in the Cloud

A Shared Responsibility

Like software security, regulatory compliance is a shared responsibility for cloud-based (software-as-service or SaaS) applications. That means both the software vendor and the customer (you) are responsible for establishing and maintaining Part 11 compliance.

It’s simply impossible to put the full responsibility of compliance on either party.

In practice, this usually means that software vendors must:

• Provide infrastructure security and reliability.
• Provide user authentication and authorization capabilities.
• Provide status-based workflows for electronic records and the capability to control user permissions based on the workflow status.
• Maintain a detailed audit history of electronic records.
• Offer a Part 11-compliant signature feature.
• Use reliable change management practices when upgrading the infrastructure or software (including sufficient testing practices).

And customers (you) must:

• Configure the system for its intended use.
• Validate the system for its intended use.
• Manage user access to the application.
• Use reliable change management and validation practices when changing application configurations.
• Ensure users are properly trained to use the system for their job.
• Ensure users are trained to understand that electronic signatures are legally binding.

Know your Vendor

You can see that Part 11 compliance in the cloud requires trusting your vendor. There’s no way around it.

But that’s not necessarily a bad thing.

The key is to know your vendor and make a calculated, risk-based decision about whether they deserve your trust. This is done through a vendor assessment.

In GAMP 5 (2nd Edition), the ISPE describes three different ways to complete a vendor assessment:

1. A basic assessment – reviewing publicly available information about the vendor, including information provided by the vendor on their website, etc.
2. Postal audit – sending a questionnaire to the vendor for them to complete and send back
3. On-site audit – having a trained audit team meet with the vendor (in-person or virtually) and assess their capabilities

The type of assessment you should use is based on several criteria, such as the system’s criticality and product impact, the vendor’s reputation, the size of the application’s user base, the level of configuration or customization required, etc.

A basic assessment is usually sufficient for evaluating Atlassian and Jira Cloud for most intended uses. (But of course, your company must decide that for itself.)

Can Jira Cloud be Part 11 Compliant?

Yes! You can achieve Part 11 compliance in Jira Cloud in three basic steps:

1. Assessment: Determine which Part 11 requirements are Atlassian’s responsibility and which are yours.
   (I can help with this! Download a free responsibilities matrix here.)
2. Configuration: Implement the necessary Jira configurations and company policies/procedures to satisfy your responsibilities in the shared responsibilities model.
3. Validation: Validate your configured Jira Cloud site for your intended use of the system.

Is it worth the effort?

Yes, I think so. There are three reasons I recommend using Jira over other IT management tools:

1. Jira is an industry leader in DevOps and ITSM tools (according to Gartner) and the most widely used management tool by professional developers (according to the StackOverflow annual survey, three years in a row).
2. Jira provides everything we need to implement compliant workflows through best-in-class configurability and extensibility (i.e., the Atlassian Marketplace).
3. It is also significantly less expensive than competing SDLC solutions, allowing you to save up to 90% of the cost vs. a niche platform. (You can easily build a compliant Jira setup for less than $50/user/month. A niche tool stack will cost anywhere from $100 to $600/user/month…or more!)

So yes, in my opinion, it is worth spending a little extra time closing compliance gaps directly in Jira rather than spending a lot of extra money (and time!) integrating an external platform.

Can you trust Atlassian?

As we discussed, compliance in the cloud requires trusting your vendor. So, can we trust Atlassian to manage a compliant platform?

To answer this question, you must complete a basic supplier assessment on Atlassian. When I did this assessment, these were a few important things I learned:

• As of fiscal year 2023, Atlassian has over 260,000 customer organizations and $3.5 billion in annual revenue. At least 250,000 of their customer organizations use the Atlassian Cloud platform with Jira and Confluence. (According to their annual shareholder report.)
• Atlassian adheres to a robust Software Development Life Cycle (SDLC) and change management policies and procedures.
• Atlassian maintains several international data security and privacy certifications, including AICP SOC2, ISO/IEC 27001:2013, PCI DSS, and FedRAMP.

For these reasons and several others *, I believe Atlassian can be trusted to fulfill its responsibilities toward Part 11 compliance. Conduct your own research based on your company’s intended use to decide for yourself.

* If you want to see my full assessment, reach out and ask!

Configuring Jira Cloud for 21 CFR Part 11 Compliance

You’re probably anxious for me to get to the point and tell you exactly which configurations need to be implemented in Jira Cloud for Part 11 compliance. Here’s the basic list:

User Access Controls

21 CFR § 11.10(d) specifies that we must limit access only to authorized individuals. This control is basically implemented off-the-shelf, as Atlassian requires all Jira Cloud users to authenticate and to be authorized access to your company’s Jira site(s).

However, you may want to improve this control by restricting which users can access which Jira projects. (By default, all authenticated users can access all Jira projects.)

Here is a tutorial on restricting project access.

Workflow Controls

This area will require the most configuration, as Jira’s default workflows are simply inadequate for most regulated use cases. These are some of the changes you’ll need to make:

Configure sequential workflows

21 CFR § 11.10(f) recommends that the system enforce the sequencing of steps and events.  

To do this, you’ll need to remove the “any-to-any” status transitions from your workflow by disabling the “Allow all statuses to transition to this one” configuration for each workflow status. Instead, you should configure explicit status transitions that match the permitted sequencing of steps in your company’s process.

Enforce Required Fields for Different Workflow Transitions

You can configure your workflows to check that required fields are completed before allowing the user to do a workflow transition. For example, you can check that a Resolution is populated before routing a defect for approval. This will further enforce the proper sequencing of events described in 21 CFR § 11.10(f).

Here is a tutorial on enforcing required fields in Jira.

Prevent Editing Fields Based on Workflow Status

This is the most important workflow control you’ll need to implement. It’s important that a record cannot be unexpectedly modified after it has reached its final workflow status. This is especially true if it has been approved with an electronic signature.

You can achieve this using Jira workflow properties.

Here is a tutorial on locking issues based on workflow status using Jira workflow properties.

Record Retention Controls

21 CFR § 11.10(c) requires that records be retrievable throughout their retention period. This means you must restrict your users’ abilities to move or delete records in Jira.

This can be done using a Jira permission scheme if you want to completely prevent certain users from deleting and/or moving records.

Better yet, you can use Jira workflow properties to control this on a per-issue type and per-workflow status basis. This is what I usually recommend because it allows you to implement configurations such as:

• An author can delete a requirement in the “Draft” status but not the “Approved” status.
• Or, a user in the tester role can create bugs, but they cannot create stories or epics, etc.

Here is a tutorial on implementing record retention controls using workflow properties.

Enhancing your Configuration with Third-party Apps

The configurations described above can give you a baseline level of compliance (if done properly). But you can really streamline your efficiency and improve audit readiness with a few third-party apps from the Atlassian Marketplace.

Improving Audit History

As mentioned earlier, Jira’s native audit history does not track the deletion of records as required by 21 CFR § 11.10(e). A basic mitigation for this is to prevent users from deleting records (as described above).

However, a much better mitigation is to use Issue History for Jira. This app augments Jira’s native feature for issue history with several improvements, the most important being that it can track deleted issues.

Here’s a demo I recorded of Issue History for Jira.

Compliant Electronic Signatures

Approving records directly in Jira (instead of in an external system) is a great way to streamline your workflows, but unfortunately, Jira provides no native signature feature that is compliant with Subpart C of Part 11.

This means you’ll need to install a third-party signature application that is explicitly Part 11 compliant to add signature steps to your Jira workflows.

I recommend using eSign Electronic Signatures for Jira. eSign is an easy-to-use signature tool that integrates directly into your Jira workflow configurations. And most important, the vendor explicitly maintains Part 11 compliance.

Enhanced Reporting

Finally, you’ll want to install a third-party reporting app to make reporting both easier and more robust than what Atlassian provides off-the-shelf.

The two tools I recommend are Xporter and Better PDF Exporter. Xporter is a bit more powerful and makes it easier to customize reports, while Better PDF Exporter is more cost-effective, especially for small teams.

Either tool will make it easier to produce audit-ready reports, including displaying the signatures from eSign (see above).

Your Other Responsibilities

An important note!

Configuration isn’t your only responsibility to satisfy 21 CFR Part 11 in Jira Cloud. You’ll also need to:

• validate the system using industry best practices (such as GAMP 5)
• implement appropriate administrative procedures (for managing users, etc.)
• provide user job training
• implement a user support system

(Of course, you’ll need to do these things no matter which system you use.)

If you want a full analysis of your Part 11 responsibilities in Jira Cloud, plus a detailed action plan to get started, get it for free here.

Best Practices for Maintaining Compliance

Once your Jira Cloud site is configured and validated, you must maintain compliance throughout the system’s life.

These are a few best practices for maintaining compliance in Jira Cloud:

Manage Changes to your Jira Site

Effective change management is critical for maintaining compliance because you’ll need to ensure that no changes to your Jira site break the functions and configurations you’ve previously tested and validated.

Given that Jira Cloud is a software-as-a-service (SaaS) application, there are two types of changes you’ll need to manage: 1) changes made by Atlassian and 2) changes made by you.

Changes Made by Atlassian

Atlassian is going to maintain its environment and its software, and this is a good thing. The challenge is that we cannot control the changes they make.

There are a few things we can do to manage and mitigate this challenge:

1. Conduct a vendor assessment: Remember, the key to cloud compliance is to know your vendor and trust them cautiously. So, the first step to managing Atlassian’s changes is determining that you can trust them to make changes responsibly. This will mitigate a tremendous amount of risk.
2. Monitor Atlassian’s change logs: Atlassian publishes weekly change logs. Subscribe to these change logs and monitor for changes that might impact your users and/or your validated state.
3. Implement redundancy: Guard yourself against bad changes by ensuring your most critical data is available outside of Jira, too. For example, when you generate reports at release time (requirements traceability matrix, test summary report, defect reports, etc.), store those reports in Confluence or a traditional electronic document management system (EDMS). This will ensure your releases are auditable in the unlikely event that a problem occurs in Jira.
4. Use release tracks: If you’re a Jira Cloud Premium or Enterprise customer, you can leverage Jira’s sandbox and release tracks features. This will enable you to test Atlassian’s changes in a sandbox environment before they are deployed to your production environment. (Note: This will only give you the opportunity to test the changes in advance. Atlassian will deploy the changes to production on schedule, regardless of whether you use the opportunity.)

Changes Made by You

Undoubtedly, you will make your own changes to your Jira Cloud site, such as adding custom fields, updating workflows, configuring reports, etc.

To remain compliant, you must follow industry practices for IT change management (such as those described in ITIL 4). Critically, you’ll need to assess each change for its potential impact on your site’s validated status and then manage the impact as appropriate.

Pro tip: A tool like Salto can really help streamline your internal change management of Jira. Unfortunately, it’s a bit pricey for smaller organizations (it’s priced for enterprise customers), but it’s worth the expense if you can afford it.

Implement a Disaster Recovery Plan

When planning for disaster recovery in a cloud-based (SaaS) application, there are two general types of incidents you need to prepare for:

• System-level incidents: These are incidents that typically impact multiple customers (sometimes all customers), and they usually occur within the vendor’s areas of responsibility. (For example, an incident within the application’s infrastructure or caused by a software update.)
  
  Recovering from a system-level incident is usually the responsibility of the vendor.
  
• Customer-level incidents: These only impact a single customer and are usually caused by a person within the customer’s organization. For example, an administrator might accidentally delete a project, an improper configuration setting might expose data to unexpected changes, or a defective automation script might unexpectedly corrupt or destroy data.
  
  Recovering from a customer-level incident is usually the responsibility of the customer.

Handling system-level incidents in Jira Cloud

It is Atlassian’s responsibility to help customers recover from a system-level incident.

Atlassian maintains rigorous monitoring, alerting, and disaster recovery processes, including regular DR tests, to ensure systems are recoverable and reliable. Furthermore, they commit to specific recovery time objectives (RTOs) and recovery point objectives (RPOs) in their service level agreements. (Learn more about Atlassian’s disaster recovery here.)

Handling customer-level incidents in Jira Cloud

Recovering from incidents caused by someone within your organization is your responsibility. (Admin errors, user errors, automation errors, etc.)

To prepare for this, you’ll need to establish a routine backup procedure for the data in your Jira Cloud site and have a procedure to recover that data when needed.  

One more difficult thing about handling user-caused incidents is that they are often not detected immediately. Sometimes, they may not be detected for years. (For example, preparing for an audit and only then discovering something is missing or corrupted.)

So, unlike a system-level incident, you’ll need a strategy to retain periodic backups for much longer, and you’ll also need the ability to restore your data to a temporary environment and manually recover it from there. (You’re not going to overwrite PROD two years later!)

To learn more about creating and restoring Jira Cloud data backups:

• Export data from Jira Cloud
• Automate online site backups for Jira and Confluence without programming
• Importing backup data to Jira Cloud

Regular Audits and Reviews

Ongoing audits and compliance reviews will help you proactively identify potential issues and ensure continuous compliance with 21 CFR Part 11. Potential issues may arise from new configurations, functional changes to the application by the vendor, or based on feedback from regulatory reviewers and stakeholders.  

By routinely scheduling and conducting these audits and reviews, you’ll find it much easier to stay on top of your Jira site’s compliance.

Conclusion

Achieving 21 CFR Part 11 compliance is absolutely possible in Jira Cloud. By understanding the shared responsibility model of regulatory compliance in the cloud and by following the steps outlined in this article, you should have no problems demonstrating compliance in your Jira Cloud site.

Ready to get started? Download a free Part 11 responsibilities matrix and action plan for Jira Cloud.

Have more questions? I’d love to hear them. Ask me anything.