Application validation

[Mikael Sandberg]

So, as a FDA regulated company we have to validate off-the-shelf software that we use, with some exceptions. We recently went through an audit and is was brought up that the validation of Jira (written as a OQ/PQ validation) did not have requirements for backup and data retention. My argument is that this should not be part of the validation, since you are validating it based on you expected behavior and that it performs in accordance to our issue management process. In my previous life, backup and data retention was mentioned in the validation plan that it followed the process used by your IT department and it was tested as part of the initial Installation Qualification. The intention was that you could give the test plan to anyone to run, without giving them access to backup locations, admin rights in the tool etc.

So my question is, in your OQ/PQ validations do you have requirements and test cases for backup and data retention?

[Matteo Gubellini _SoftComply_ · Accepted solution]

Hello @Mikael Sandberg ,

Yes, typically backup and data retention are considered part of the software tool validation. 21 CFR 11 explicitly lists this requirement. Having said that, if you did validate the backup function as part of the IT infrastructure, then it should have been enough.

Personally I often test the backup as part of the tool validation. IT validations are somehow focused on slightly different aspects. In my plans / protocols I want to be sure that no only the data are saved, preserved and can be restored, but also that all the settings and customization will be brought back correctly. And if not, I record this configuration during the IQ/OQ.

Ideally the ultimate test is to backup your data, uninstall the software, reinstall it with the proper settings and restore the backup. The idea is that someone must be able to restore the full system at any time in the future, with all the correct data and settings, using only the information present in the validation pack (and the backup of course). This include retaining a copy of the installation file of the version of Jira you use (or whatever tool you use), add-ons, etc. (of course if you use cloud system this does not apply).

Happy to continue the discussion here or offline if you have other doubts or questions.

Matteo

[Mikael Sandberg]

Hi @Matteo Gubellini _SoftComply_

I completely agree that backup and data retention should be part of the tool validation, the way I have done that in the past is to do it as part of the IQ validation, and then just reference the backup process in the OQ/PQ, so you can have an independent review of it without giving them additional admin rights to the system.

[ritu bhatia]

@Mikael Sandberg  We are using JIRA cloud and when creating URS for JIRA OQ, we did NOT add data back up requirements. 

[Tom Lister · Accepted solution]

Hi @Mikael Sandberg 

I’ve worked a lot in finance and had similar strict audits. For backups, it is down to our ops teams & dbas to provide a backup strategy that matches the retention and sla’s we set. Its not usually part of the product itself as far we were concerned - other than verifying a restore from back up is feasible.

Jira has its own Xml backup cycles but its not recommended to relybon that for large/critical installations. There should also be database and file system backup processes in place. And as you mention, we would normally state ‘uses IT standard backup plans’.

[Jake {Ketryx}]

Hi @Mikael Sandberg

Just wanted to add that I'm in agreement that data retention and backups are a necessary requirement that should be part of your requirements specification. 

An alternative to doing it yourself is to purchase a product that manages the backup process for you.   Products like that should have a set of requirements they've tested as part of DQ that you should be able to trace to.  I know our product - Ketryx - does that and we provide the design control documentation to support it.  

All the best,

Jake