8 Maintaining the SDLC platform in a validated state

Getting off to a good start with validating your SDLC in Atlassian

This article centers on GxP validation for pharmaceutical and medical technology companies, drawing on FDA regulations and other key industry standards.

For many organizations, adopting Atlassian for SDLC processes introduces a heightened regulatory impact and, often for the first time, necessitates platform validation.

Several factors can make an Atlassian validation project particularly daunting. Below, I outline the primary questions I encountered over the years and key strategies to address them effectively:

Concern or question	Resolution
What is the risk level for the system	SDLC processes constitute part of the QMS. This means that they never impose a direct safety risk to patients. Your risk level scale is individual to your organisation, but SDLC in Atlassian always needs to be considered less risky than the system or product that the SDLC supports.
Where is Atlassians’ validation document to laverage as part of our own validation program?	Atlassian does not provide any documents specifically referred to as validation documents. However, there are Atlassian documents that you can leverage in your validation efforts: For access controls and cybersecurity, refer to Atlassian's trust center All issues open on the Atlassian products are publicly available here Check out the Atlassian change procedure to learn how you can know about changes to the platform
How can we control Atlassian Cloud?	The quick fact is that you cannot control Atlassian Cloud. You can enhance your support level by purchasing a Premium subscription and enabling the 'Release tracks' option. Even then, you will only get a preview of the UX changes without the ability to reject them. Non UX changes are not part of the release track and are rolled out as they are. Moreover, Marketplace App changes are also rolled out at the discretion of the App vendor. From a regulatory and Quality point of view, you can justify allowing this limited control on your SDLC process, using a combination of these reasons: The level of risk for the SDLC platform tolerates this. Atlassian is a ubiquitous platform with a good track record of reliability. Marketplace vendors that are part of the SDLC configuration have a good track record.
We'd need to sign a Quality Agreement with Atlassian	Atlassian generally does not sign tailored Quality Agreements with their customers, nor are they open to audits, as far as we are aware. You'll need to rely on the standard Atlassian Customer Agreement and DPA s.
What do we need to validate?	Your validation effort should not seek to validate the platform as such; this will result in prohibitively expensive effort that doesn't add value to the quality of your SDLC. It’s exactly the opposite of a risk-based approach. Your validation project needs to focus entirely on your SDLC process. More specifically, on these areas: Validate the integrity of the information in your SDLC records and the users who have acted on these records. Validate that the process described in your SDLC procedures can be successfully carried out on the platform. Do you have any process controls that are configured into the platform? You'll need to validate they are working as expected. Define and validate your strategy for retaining and managing quality records in Atlassian. For more details, check out one of the next sections.
What is the platform version against which we validate?	There is no platform version you can refer to in your validation documentation. Reasons are: Atlassian does not provide this information. Marketplace apps have version numbers, but these are not really versions of the app, but rather a version of the app manifest. So, you also do not have the version number for the marketplace app. It's another expression of the fact that you do not have the same control over the platform as in a traditional setup.
How do we validate the Marketplace Apps we have installed?	Marketplace Apps should be selected based on the criterias you have defined. For example, this decision is based on their reputation and data security considerations. Once they are selected, validation occurs inherently as part of validating the SDLC in Atlassian. Marketplace apps are not validated separately.
How do we know that the system will remain validated	We put in place several processes: Configuration changes to the platform happen as per our change management procedure Only qualified individuals get administrator access Periodic validation activities For more details, check out one of the next sections.
Can the SDLC in Atlassian co-exist on the site with other processes that do not require validation?	Yes, absolutely. Regulated processes, like SDLC, can co-exist on the same platform as more casual processes. The key is to apply certain controls on the whole platform to ensure that non-regulated changes do not negatively impact regulated processes. For example: Limit the number of product administrators, so that regulated workflows will not be accidentally changed or that required Marketplace Apps remain installed. Any change on the site should be done according to the change management procedure.
Is the effort to validate Atlassian worth it?	Validating Atlassian, as with any validation exercise, requires skill and expertise. In particular, the right expertise can help define the correct scope and render the whole effort short and quick. Despite the absence of a ready validation package from Atlassian, the typical validation effort for SDLC in Atlassian is limited and manageable.

The Jira validation project

After the initial groundwork laid by reviewing and answering the questions in the previous paragraph, you are ready to carry on your validation project.

Start by defining the project team. Here is who needs to be on the team:

Validation project owner
Platform admin
Quality assurance person
SDLC process subject matter experts (SMEs)

Mark Templeton, VP for Information Technology at Saluda Medical, summarizes it like this : “CSV starts with an assessment and then a plan; those are the two most critical parts of it. Assess the environment. Write your scope down. Agree on what's in and out of scope. And assess it for what parts of the regulatory requirements you're meeting – electronic records and/or signatures? What quality records are you storing? Once you do that and you put your plan together, that's the crux of the work.

But for the plan to be effective, you need all the right information at the outset. “It's about getting the right inputs to make sure that the plan is accurate with all the steps and deliverables you're going to write as part of the documented evidence.”

This list covers all the documents organizations need to create as part of a Jira validation project.

What is it?	What's its purpose?	Who should contribute?	Content tips
Risk assessment	Defines the scope of the system or process being validated, including its impact on patients’ lives and the quality system.	Platform admin, regulatory, and business teams	The risk assessment can drive some important questions and decisions: Decide if you want an Atlassian standard, premium, or enterprise subscription. Many regulated companies opt for premium or enterprise. Where will your records be kept? Will Atlassian be your system of record, or will you want to export the records (i.e., as PDF) from Atlassian and keep them somewhere else? What are your backup and disaster recovery needs Do you want to use release tracks
Validation plan	Based on the defined level of risk, the validation plan determines which documents need to be created and by whom.	Platform admin	Specify the steps required to validate your configuration. Explain how you plan to maintain the system in a state of validation over time.
Standard operating procedure (or work instruction)	This describes the business process that is configured in Jira. It needs to be up to date and reflect the Jira configuration.	SDLC process SME	This is the procedure that describes the SDLC process. Also specify the process steps in a way that users of the process can follow. Sometimes the SOP is split into a high-level part and a separate Work Instruction document. The step-by-step process description should cover all the various SDLC roles: Product managers, Developers, Testers, etc. From our experience, even if a procedure existed before the configuration project began, it always needs to be updated to reflect the eventual configuration.
Requirements specifications	This is a list of requirements from the Jira configuration	SDLC process SME	Yes, you can even use the SDLC documentation to capture the requirements. You can generate the documents from the system and sign them externally. You cannot sign them in Atlassian because eSignature in Atlassian has not been validated yet.
Tests	Tests to ensure that the requirements are met. For a Jira CSV, these would be manual tests.	SDLC process SME	Yes, I propose to use your SDLC configuration to capture tests. As long as the signing of the test reports is done outside of Jira (because Jira and Confluence have not been validated at this stage). Identify a subset of the tests that will be used as part of the periodic revalidation. In regard to the test types, you may also consider whether it's appropriate to use unscripted, exploratory, or scripted testing. (reference to FDA CSA Guidance). While it is possible to run the SDLC process through automatic tests, it's typically not a worthy investment to create those automatic tests.
Test report	Proof that the tests have been executed.	SDLC process SME
Jira admin handbook	Document routine maintenance procedures for Jira. For example, access management, update to field options, backup and restore, etc.	SDLC admin	Non-inclusive ideas for content: All the routine maintenance activities (backup, download of system audit logs, etc). Onboarding/offboarding and permission management Launching of new spaces for new SDLC work Routine change processes: for example, how to change the values of a select custom field. Any process that is predefined in advance as a ‘routine process’ could then be subjected to an easier change management process. So it's very well worth the effort of adding as many processes to this list.
Change procedure	This describes how Jira modifications are carried out.	Platform admin, regulatory, and business teams	Specific change process for changes in Atlassian. Consider using JSM to process these changes.

Tips for maintaining Jira in a state of validation

Once your SDLC is validated, it's important to keep it that way.

Here are some ongoing practices to help you stay on track:

Check for updates from Atlassian and Marketplace Apps regularly. If you're on release tracks, it helps to line up your reviews with their schedules.

Run a set of re-validation tests every few months, like every three or six months. The most important thing is to choose the right amount of testing—use your regular tests and add any extras needed for new changes or updates.

Whenever you update your configuration, just follow your usual change procedure.

Keeping your SDLC validated doesn't have to be overwhelming. By following clear, consistent practices and staying up-to-date with changes, you can make CSV or CSA a valuable part of your routine.