Computer System Validation Policy on Software-as-a-Service (SaaS)

In a recent LinkedIn Group discussion (Computerized Systems Validation Group: Discussion "Validation of Cloud), the topic of Software-as-a-Service (SaaS) was widely discussed and the need to identify appropriate controls in Computer System Validation (CSV) policies was discussed.

The reality is that relatively few compliant, validated SaaS solutions are out there, and relatively few Life Sciences companies have CSV policies that address this. 

However, there are a few CSV policies that I’ve worked on that address this and although client confidentiality means that I can’t share the documents, I did volunteer to publish some content on what could be included in a CSV policy to address SaaS.

Based on the assumption that any CSV policy leveraging a risk-based approach needs to provide a flexible framework which is instantiated on a project specific basis in the Validation (Master) Plan, I've provided some notes below (in italics) which may be useful in providing policy guidance. These would need to be incorporated in a CSV Policy using appropriate language (some Regulated Company's CSV Policy's are more prescriptive that others and the language should reflect this).

"When the use of Software-as-a-Service (SaaS) is considered, additional risks should be identified and accounted for in the risk assessment and in the development of the Validation Plan computer system validation approach. These are in addition to the issues that need to be considered with any third party service provider (e.g. general hosting and managed services). These include:

• How much control the Regulated Company has over the configuration of the application, to meet their specific regulatory or business needs (by definition, SaaS applications provide the Regulated Company (Consumer) with little or no control over the application configuration)

o   How does the Provider communicate application changes to the Regulated Company, where the Regulated Company has no direct control of the application?

o   What if Provider controlled changes mean that the application no longer complies with regulatory requirements?

• The ability/willingness (or otherwise) of the Provider to support compliance audits

• As part of the validation process, whether or not the Regulated Company can effectively test or otherwise verify that their regulatory requirements have been fulfilled

o   Does the Provider provide a separate Test/QA/Validation Instance?

o   Whether it is practical to test in the Production instance prior to Production use (can such test records be clearly differentiated from production records, by time or unique identification)

o   Can the functioning of the SaaS application be verified against User Requirements as part of the vendor/package selection process? (prior to contract - applicable to higher risk applications)

o   Can the functioning of the SaaS application be verified against User Requirements once in production use? (after the control - may be acceptable for lower risk applications)

• Whether or not the Provider applies applications changes directly to the Production instance, or whether they are tested in a separate Test/QA Instance

• Security and data integrity risks associated with the use of a multi-tenanted SaaS application (i.e. one that is also used by other users of the system), including

o   Whether or not different companies data is contained in the same database, or the same database tables

o   The security controls that are implemented within the SaaS application and/or database, to ensure that companies cannot read/write delete other companies data

• Where appropriate, whether or not copies of only the Regulated Companies data can be provided to regulatory authorities, in accordance with regulatory requirements (e.g. 21CFR Part 11)

• Where appropriate, whether or not the Regulated Companies data can be archived

• If it is likely that the SaaS application is de-clouded (brought in-house or moved to another Provider)

o   Can the Regulated Companies data be extracted from the SaaS application?

o   Can the Regulated Companies data be deleted in the original SaaS application?

If these issues cannot be adequately addressed (and risks mitigated), alternative options may be considered. These may include:

• Acquiring similar software from an acceptable SaaS Provider,
• Provisioning the same software as a Private Cloud, single tenancy application (if allowed by the Provider)
• Managing a similar application (under the direct control of the Regulated Company), deployed on a Platform-as-a-Service (PaaS)"

Hopefully these ideas will help people to develop their approach to SaaS, but CSV Policies should also address the use of PaaS and IaaS within the broader context of outsourcing.