Cloud Solutions for GxP Laboratories: Considerations for Data Storage

Abstract

Challenges for data storage during drug development have become increasingly complex as the pharmaceutical industry expands in an environment that requires on-demand availability of data and resources for users across the globe. While the efficiency and relative low cost of cloud services have become increasingly attractive, hesitancy toward the use of cloud services has decreased and there has been a significant shift toward real-world implementation. Within GxP laboratories, the considerations for cloud storage of data include data integrity and security, as well as access control and usage for users around the globe. In this review, challenges and considerations when using cloud storage options for the storage of laboratory-based GxP data are discussed and best practices are defined.

Keywords:

• cloud storage
• data integrity
• validation

Challenges for data storage during drug development have become increasingly complex as additional laboratories are introduced across international and multisite companies. As the pharmaceutical industry expands in an environment that requires on-demand availability of data and resources for users across the globe, the efficiency and relative low cost of cloud services has become an increasingly attractive option. As hesitancy toward the usefulness of cloud services has decreased, it has become apparent that there has been a significant shift toward real-world implementation of such services. Within regulated environments such as GxP laboratories, there are many considerations when moving to the cloud in terms of data integrity and security, as well as more practical notions regarding how access is controlled and how data can be accessed by global users. In this white paper, we will discuss the challenges and considerations when using cloud storage options for the storage of data for lab-based GxP organizations, defined here as organizations that follow GLP, GMP and/or GCLP regulations.

Utilizing cloud providers

The information technology needs of the pharmaceutical industry are following trends apparent in other industries, necessitating a move toward cloud providers. However, there are limitations and concerns regarding regulated data being stored and transferred into a cloud-based environment. Pharmaceutical companies and industry partners providing sponsor- and study-related services are bound by health authority regulations regarding data integrity, security, privacy and other considerations that do not have many parallels in other industries. In the guidance document, Data Integrity and Compliance with CGMP, the US FDA acknowledges that sponsors may choose to outsource electronic services, including cloud computing. As such, the FDA notes that sponsors ‘implement appropriate controls to manage risks associated with each element of the system’ [1]. This not only implies the regulatory expectation that sponsors perform and document due diligence on any provider prior to engagement but also implies that an organization can use cloud storage for its data needs if desired. With these implications in mind, what are some considerations for the use of cloud storage?

There are various cloud offerings available that can suit the needs of just about anyone, from a single user at home to the largest worldwide organization. As always, any organization looking for a new provider wants to find the best service and value for the cost invested. However, it often can be confusing when one looks at what a provider offers and making ‘apples-to-apples’ comparisons can be difficult at the least, and positively painful at the worst. For example, if one browses to the ‘Explore Our Products’ page for one of the major cloud services provider, Amazon Web Services™ (AWS) [2], there are over 20 categories of products to choose from and well over a hundred actual services. Similar lists of Microsoft Azure [3] and Google Cloud Services [4] offer up the same bountiful list of cloud-based service options. Factor in hundreds, if not thousands, of other smaller cloud service providers and the sheer number of options can boggle the mind. How does one go about traversing the universe of potential options that are available?

Cloud service provider requirements

The first step in any such endeavor is to determine an organization’s actual cloud service needs. For example, is the need to simply identify options for data storage options or would statistical analysis of the web traffic or other metrics be needed? Is the scope determined to be a virtual data area that would serve 50–100 people or a far larger access pool? Can the organization afford to maintain and expand internal data storage, or can it benefit from the scalable, on-demand nature of the cloud? Does the organization need constant access to work with the data while in the cloud, or just long term, read-only storage of the data is needed? Before contacting any service providers, these definitions of ‘need-to-have’ and ‘nice-to-have’ requirements should be worked out with the data users and owners within each organization. It is very helpful to define what the needs really are and make a list of requirements that describe exactly what is needed from a potential provider, including storage requirements for the data.

The storage requirements for electronic records should meet GxP requirements, where applicable, and the protection of the data should be maintained throughout the lifecycle of the retention period through a chain of custody process [5–8]. Data should be readily available at any time according to the defined needs, with the caveat that large datasets stored offsite or in the cloud may require additional lead time to download and restore. The original file format will need to be retained, which may require companies to maintain older versions of software, computers or databases to ensure the data can be accessed when it is needed [9]. For example, hard-copy printouts or nonhuman readable formats will not be acceptable during most health authority inspections [5].

Considerations for data storage

Once, the requirements for potential cloud providers have been determined, it is time to look at considerations for the targeted data. Information security and privacy is a major consideration when considering a cloud provider. The foundation of this is the ‘CIA’ triad of confidentiality, integrity and availability of data. The confidentiality of sensitive and critical data must be maintained. In order to prevent disclosure of proprietary information, data should be stored in a secure and preidentified/mapped space set aside for the organization and should not mingle with files from other clients of the vendor. Access must be controlled to ensure that no unauthorized user can access any files, the current data owners have stored in the cloud solution. Controls on access to the data also maintain its integrity. The vendor should provide evidence that files are not accessible for corruption over their lifetime on the cloud, which can extend into years or decades, and that data integrity is maintained. Confirmation tests that demonstrate that files do not change over time should be performed, either by the vendor or user’s organization. There should also be audit trails, so that access to a file can be tracked as well as any changes from authorized users. Availability considerations are also important, as some data one may need to access constantly, while other files can stay in stasis in the cloud, untouched for years. Most cloud providers charge differently for file storage depending on the type of specific access controls and auditing services users require. As a result, consideration of the types of availability one needs for the data cloud storage could result in major cost savings in the long term.

In the end who is responsible for security in the cloud? Is it the customer, the service provider or a shared responsibility? The answer to this depends on the cloud-service model; and in this white paper, we focus on an Infrastructure as a Service model (IaaS) or cloud storage. Other available service models include Platform or Software as a Service, respectively. In an IaaS model, which includes Microsoft^® Azure^®, AWS and Google Compute Engine™, the service provider is only responsible for the security of the physical data centers and other hardware that power the infrastructure. This means that customers must secure their own data and operating systems. Some specific elements of cloud security to look at should be identity and access management (how is access controlled, integration with the data generator, owner or the user’s organizational IAM system, multifactor authentication capabilities), physical security, encryption and next-generation firewalls. Regardless, a multilayer approach should be a must.

A study by McAfee^® [10] in 2020 illustrates an increase in cyber attacks against cloud services. Most high-profile breaches were a result of user missteps or misconfigured services versus being the fault of the service provider. Working with cloud providers can be an unchartered territory for biotech companies. Any company considering adoption of cloud storage services needs to start with documenting where the service provider’s security ends and where the data owner’s company’s security begins and is that sufficiently covers the security and integrity needs.

Third-party data standards

Third-party standards may be cited by cloud providers to potential clients as mitigation of compliance concerns. Adherence and certification to these standards are mentioned by providers as part of their effort to market themselves as suitable for regulated records. Examples are ISO standards [11], SOC [12] certification and Fedramp [13]. As different standards cover different types of compliance under different circumstances, it is best to evaluate the specific focus of the organization to determine which standards apply and then search for a provider that adheres to these standards. If a provider claims adherence to a certain standard, it is highly recommended to be sure to request evidence that backs up any claims of compliance. Some standards require recertification after a certain period of time, so it is best to ensure that any potential provider is up to date on any claimed certifications.

IaaS considerations

The previous discussion focuses on the direct use of cloud services by sponsors. Sponsors should also be aware of risks associated with indirect use of cloud services. For example, a contract research organization (CRO) that the sponsor employs may utilize cloud services as a component of its processes/infrastructure. Alternatively, a sponsor may contract with a vendor for use of an online software platform, which is in turn hosted on infrastructure of a third party. It is important to not only assess quality processes at the CRO or the validation of the online platform but also at the very least be aware of the relationships that may exist between these vendors and third-party providers with whom they contract.

In the instance of a vendor providing IaaS on a cloud infrastructure, it is important for the sponsor to ensure the vendor meets or exceeds many, if not all, of the same requirements as the cloud provider. Any employees from the vendor site involved in the IaaS platform should be trained in handling data in a cloud-based environment. Applicable employees could range from software developers to field service members and technical support involved in supporting the IaaS. All documentation and training certifications must be traceable and readily available to the sponsor.

Since the vendor has most likely already selected its preferred cloud provider for the IaaS, it becomes more important for the sponsor to evaluate the software vendor and its relationship with the cloud provider, rather than just the provider itself. Specific points of interest in evaluating the IaaS vendor include testing of deployments, vendor employee access to data and preservation of data. Sponsors should verify these items both meet regulatory and internal requirements. Vendors also should be able to supply reasoning behind their selection of the cloud provider. A Service Level Agreement (SLA) may be necessary with the third-party vendor.

One of the most important considerations when using IaaS in the cloud is GxP compliance. Typically, laboratory data workflows must handle data inputs from various equipment and software sources (e.g., immunoassay, multiplex or LC–MS/MS instruments and data analysis packages). However, formats that are specific to a single vendor may become an obstacle for optimal compliance with regulations. Potential use of vastly different data processing and vendor-specific software could lead to a disconnect between different laboratories within a company or if assays must be transferred to CROs. If large datasets can be generated that do not feed into a simplified laboratory information management system (LIMS), or if gaps or differences in data processing workflows exist, this creates risk for data management.

Progression of software versions over time may also pose an audit risk, especially if newer versions of software lead to different processed results. The software lifecycle should, therefore, be an important consideration if datasets may be needed for long-term program support. If used to support filings, software version updates need to demonstrate result equivalence with backwards compatibility for compliance during audits. When data are exchanged between companies (e.g., CRO to sponsor, or during a company acquisition), the contract should include language that mandates that raw data, including the versions of the software used to generate the raw data, are provided to the recipient. This could avoid any last-minute and costly software transfers down the road. There also have been cases where the raw data and test results are transferred to the sponsor’s site where the subject matter experts (SMEs) process them using internally developed software to generate the test results. Security of the data during the transfer presents risk, especially if there are manual transfer steps. Sponsors have used data transfer via the cloud at a time when the procedures for validation cloud-based systems are not clear among the users and regulations are still not available.

It is also critical that software retains full backwards compatibility to older versions of file formats and data analysis algorithms. There are two issues to consider:

• The format of the data file changes over time (e.g., analogous to the switch of Microsoft Excel^® from .xls to .xlsx) and newer versions of the software cannot open older versions of data files (i.e., a lack of backwards compatibility).

• The analytical algorithms used may have changed over time in the software due to bug fixes and/or improvements in analysis algorithms. If the latest version of the software only contains the latest (i.e., ‘best’) algorithm, then analysis of old data will yield different results.

These types of problems represent a severe risk to the company because upon an audit, the inspector may, for example, say, ‘please show me the chromatogram and result values for sample X.’ If the old raw data file cannot be opened, or if the algorithm has changed and the new software yields different numerical values, then the individual will be unable to demonstrate how the results reported to the auditor were obtained. This illustrates noncompliance with GLP and other GxP regulations. The solution to these problems is to apply pressure on software vendors to ensure full backwards compatibility to all versions of data files from their software and that all historical data calculation algorithms are available in the latest versions of their software. However, as this may not be realistic, each organization should be responsible for keeping older versions of software in case one needs them to recreate raw data results. Another consideration is to work with instrument and software vendors to adopt a secure, vendor-neutral data transfer process to avoid differences in file type and to allow secure, compliant transfer of data from system to system, or from data owner’s organization to the cloud. It is envisioned that in the future, such a process will become more attractive and will be demanded by various organizations in the pharma space, and as such, initiatives of this type are already in process [14].

Sponsors also should focus on review of the Quality Management System of the provider and its alignment with regulatory expectations and company-specific requirements. Quite often, the sponsor has more expertise with regulatory expectation and should use the due diligence process as an opportunity to educate the supplier. Beyond the Quality Management System, other areas of focus include determining the geographic locations of provider facilities with emphasis on identifying whether it is possible for the end user to restrict data to defined regions. Training practices and awareness of staff regarding regulated data should be examined. The supplier should maintain explicit documentation of who within the providers organization has access to control the infrastructure. Organization charts, role definitions and job descriptions should be available for review. Finally, one should confirm the supplier maintains robust change control procedures for infrastructure and process.

External audits

An important topic to discuss with a potential vendor is how open the vendor is to external audits of their functions. For example, an organization may want to do a technical review of how it handles security, or even a compliance review to see how it meets any applicable regulations. This should include the rights for vulnerability and penetration testing and patch management compliance. Depending on the vendor, one may find some are very open to any audits requested, while others are not. It will be up to the storage service users (i.e., the potential customer), to determine how comfortable one is with a vendor’s openness to outside audits. Beyond the data owners’ organization’s internal audits, the prospect of a regulatory audit also should always be discussed. The legal right of regulatory authorities to inspect cloud provider facilities is a topic of debate centered around whether the cloud provider facility is viewed as a ‘test facility,’ ‘CRO’ or other entity. Suppliers should know or be informed that they could become an inspection target for regulators, and that they should have procedures for handling this eventuality. All items mentioned previously, including the sponsor’s documentation associated with provider due diligence, SLAs and customer agreements should be readily accessible to sponsor personnel who may be called upon during regulatory inspections at the sponsor site.

Selecting a vendor

Once, the cloud storage users have the requirements prepared, it is time to determine what vendors should be solicited for proposals for service scope and cost determination. It is recommended that new and existing users are using their requirements as a guide. For example: Does the current organization or user need the huge resources of Google Compute Engine™ or AWS, or perhaps something on a smaller scale? Next, the users should work out a short list of potential vendors and contact them. Include both large and small providers in order to get exposure to what services each type can offer. To initiate the dialogue, one must provide the requirements and work with the cloud service providers to determine what sort of options are available for next steps of the service request. It is highly recommended that users remember that this is the time for the vendors to impress and suggest a wide set of options. As a service seeker, the users should ask questions, ensure that the vendor clarifies everything being provided and risks versus benefit of every item on the list of services in question. If a vendor is not responsive to the users’ needs that is the first sign that they are not a promising and dependable long-term service provider for these needs.

After all the above-mentioned steps, a list of acceptable vendors and potential cost information for each should become available. The last thing to consider is if one can obtain feedback from any present customers with each vendor to discuss their service experience. Vendors may often be willing to give out a customer contact, or data owners may already know someone who is using similar cloud storage services. Data owners are strongly cautioned to not ignore this potential source of vendor information, because it may help solidify the final choice of vendor decision. Once the decision makers have everything, one should have enough information to choose the vendor who is best suited to the needs and wants of the project and the progression to final decision on vendor selection may be made with well-informed data and confidence.

Service level agreement

When the step of vendor selection is complete, a SLA should be put in place between the sponsor and service provider. This document clearly defines the services, the provider will deliver along with associated timelines, including responsibilities of all involved parties. Examples of activities that might be included in the SLA are system backup and restore, downtime and restoration of service timelines, geographic restrictions on location of information and options regarding disposition of data on termination of agreement or in the event of lack of payment. Other considerations for the SLA are the description of records, materials to be archived, materials to be transported (i.e., physically or electronically), chain of custody, responsible individuals with access, storage requirements and conditions, the method for retrieval and access, and quality activities performed [6,7]. Another important consideration for a GxP laboratory is how the local regulatory authority views cloud-based services. Although OECD/GLP has not codified this in a written guideline, in recent years some GLP inspectors working under OECD guidelines have found fault in the use of a cloud-based service for providing data storage for GLP labs, for example. The most common finding is that the data are not always under the control of the testing facility. Although the topic is under discussion in many regulatory bodies, the sponsor is ultimately responsible for their own data and should evaluate any cloud-based providers’ experience and ability to address regulatory findings, especially in the GLP space.

Part of a risk-based vendor management plan should include contingency plans if any vendor is no longer able to provide a service. This is also true for cloud-based data storage providers. If the external vendor goes out of business or has no legal successor, it should be specified that the materials and records should be transferred back to the sponsor in a validated and tested manner [6,7]. Sponsors should demand transparency from the ground up and maintain clear data paths that are traceable and compliant with regulator and sponsor requirements and expectations. Large service providers, such as AWS, typically have standard agreements already developed that the vendor may be reluctant to modify. In such cases, an additional document, sometimes called a customer agreement, may serve to supplement the standard SLA. In addition, relevant standard operating procedures (SOPs) should be created, enforced and followed by both parties. The SOPs should define how and when data will be accessed and what approval is required.

Migrating data to the cloud

It is important that all data required for reconstruction of the study be migrated, including metadata, audit trails, e-signatures and associated hardware and software [8]. When migrating electronic records, this process should be fully documented and validated to ensure it is complete and accurate. The conversion of data to a different format (i.e., from a proprietary data format to common format, such as PDF) should be considered as data migration. Where data are transferred to another medium, data must be verified as an exact copy prior to any destruction of the original data. Files considered archived should also be in a read-only status. The value and/or meaning and links between a system audit trail and electronic signatures should be ensured during the migration process. There may be a need to produce duplicates of the electronic records to ensure preservation; however, the duplicates will be individually maintained, verified and tracked [1].

Continuing relations with the service provider

Once everything is in place and users and owners are using a new cloud service vendor, it is recommended that they keep in regular contact with the support team to ensure any questions are answered and issues remediated. This also will allow the vendor to update cloud users on any new services or rate changes. As always, a vendor will want to place the latest and newest service, but it is very important that if the service users consider any new services offered with short- and long-term insights into how the new or upgraded version will enhance existing business needs and balance the benefit with the cost impact. While new services often can be very helpful, newer does not always mean better, especially in the GxP space, so it is expected that the vendor fully justify any new service offered before upgrading or changing anything in the system.

Case study

The following case study demonstrates the potential gaps between a full or hybrid cloud solution for data management and storage.

Data capture

Immunoassay (ELISA) data are captured on a plate reader (e.g., Molecular Devices SpectraMax^® Plus 384), and read using proprietary software (i.e., SoftMax^® Pro). Both metadata and raw data are generated during the read, and all are stored in the proprietary data file. In the case of GxP work, the audit trail for these data is also contained in the file. The audit trail contains multiple elements:

• A log of all actions taken by users, date/time stamped, with user name attributed;

• Plate reader information, software version and the location where the data file has been saved;

• Read specifications – such as type of measurement (e.g., absorbance), wavelength and auto-mix settings.

It should be noted that the number of steps in data processing and their complexity can vary widely from instrument to instrument, and the retention of intermediate data also will vary.

Data format

The raw data file that is produced is in a proprietary data format (.eda or .sdax [versions 6.0 and higher]). Often, the raw data must be exported and converted into a .txt file for import into a LIMS application. This means that both the binary data file (containing further metadata and audit trail) as well as the exported plain-text file must be retained and traceable.

Data transfer

Data transfers are handled in several steps, both automated and manual. First, the proprietary data file is manually saved to a network location using the ‘Save As’ command, such as a folder related to a particular study. The user then exports the data as a .txt file to the same location and prints the data to a PDF file, also saved in this location. After approximately 15min, the data are swept to a read-only location on the network to ensure that the files can no longer be edited. The 15-min timeframe gives the analyst time to generate and save the data files, but not too much time to allow for any further changes. The data files will reside in the read-only project directory until the end of the project. At that time, the data are swept to a cloud location for archive storage. The location on the third-party cloud is specific to the organization performing the assay and is not mixed with other clients of the cloud provider. At this point, the files are read-only and fall under the purview of the archivists of the organization.

Data restore

If data files need to be restored to the network, users must contact the archivist, who then can restore the files to an appropriate network location from the cloud. Alternatively, users can also be given the option to browse the cloud location themselves and restore copies of any files needed but must contact the archivist to have any new copy put into archives with appropriate approval. The audit trail and version history of the file will be kept in the cloud, if needed. For the purposes of most audits/retrieval efforts, the PDF of the raw data serves to make the raw data easily viewable from any computer without the need for the Softmax Pro software. If the audit trail needs to be reviewed, this can be accomplished by either opening the raw data file through the Softmax Pro software or through a text editor. It is important to note, however, that the original (complete) data values and a good portion of the metadata are only viewable through the Softmax Pro software [15].

Commentary

As instruments have grown in their sophistication, so has the nature of the data captured. Often, there is a heavy reliance on file-naming conventions and nomenclature to determine, which file was derived from another. Additionally, to review the data flow process, multiple files (which often are copies in different formats) must be viewed and each tracked. The number of files for data types has increased (e.g., images), as well as their size. The exact nature of what raw data is captured and the size requirements, as well as the complexity of traceability should be considered both when implementing a new instrument as well as when choosing data storage infrastructure.

Additionally, since there are multiple software packages used in the process, there are differences with how data are grouped and organized in each. For example, software to sweep from instrument computers to a network location, as well as off-the-shelf archiving solutions, are often scoped per instrument. This means that if multiple instruments are used to generate data for a single study, their data will be in separate folders in both the network drive and archiving tool. This necessitates the manual compilation of data into study or project-specific folders. This can also lead to multiple copies of data in various locations, all of which may need to be explained and traced during an audit.

Conclusion

The data generated in a process or workflow can be the most important aspect of a business. Handing this precious resource over to a third-party cloud service often can add functionality, security and safety to the data but it also can be daunting to evaluate and select from the incredible number of vendors and services available, and then manage the vendor and data for its planned lifecycle. It falls to the data generator or user – the potential cloud service customer – to fully evaluate any potential vendor and to keep tabs on any vendor contracted with the responsibility for the storage and management services. There are a multitude of responsibilities involved with keeping track of the support provided by the cloud service vendors. However, once a system is put in place, most end users will discover that cloud services greatly increase the efficiency and dependability of business development and continuity.

Future perspective

As the biopharmaceutical industry moves forward and cloud data storage becomes ubiquitous, it is expected that international regulatory authorities will reach consensus on how to handle working with cloud storage providers. Regional and local health authorities and laboratory regulators should, in turn, provide clarity on whether cloud service providers are eligible for audit as well as give a better understanding of organization roles and responsibilities. Also, guidance could be released on the appropriate security configurations for cloud providers in order to help organizations achieve better protection against the ever-expanding threat of cyber attacks.

Box 1. Definitions.

Cloud services:	=	Computing services that demonstrate the characteristics of on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service.
Infrastructure as a Service (IaaS):	=	The first of three models of cloud services providing processing, storage, networks and other fundamental computing resources upon which the customer is able to deploy and run arbitrary software, including operating systems and applications.
Platform as a Service (PaaS):	=	The second model of cloud services, providing all the resources of IaaS, plus operating systems. The customer is able to deploy applications on the platform and may have some control over configuration of the application hosting environment.
Software as a Service (SaaS):	=	The third model of cloud services where a software application runs on a platform and infrastructure controlled by the provider. The application is accessible to the customer through a browser or program interface.
Confidentiality:	=	Only authorized users and processes should be able to access or modify data.
Integrity:	=	Data should be maintained in a correct state and nobody should be able to improperly modify it, either accidentally or maliciously.
Availability:	=	Authorized users should be able to access data whenever needed.
Service Level Agreement (SLA):	=	Defines the level of service expected from a vendor, laying out the metrics by which service is measured and the remedies or penalties if not met.

Executive summary

With regulatory compliance and cyber security risk associated to the ‘CIA’ of data, understanding the caveats and ramifications of cloud solutions can help laboratories determine the feasibility of moving resources to that type of services.

Background

• Complex options available related to cloud solutions including various cost structures.

• Hesitancy has decreased over time, and a shift toward cloud services.

• Many considerations are required for GxP organizations in consideration of a move.

Discussion

• Determination of where to use cloud services.

• Data retention periods, short-term, long-term needs.

• GxP requirements of a cloud solution.

• Type of cloud services.

• Securing cloud services – who has the responsibility.

• Third party standards and certifications.

• Service Level Agreement considerations.

• How to select a vendor.

• Auditing considerations.

• Data migration options.

Conclusion

Data are the most important aspect of the GxP organization. Storage complexity and requirements are increasing, and cloud solutions can be an attractive option for maintaining this ever-growing pool of data. Where considerations are addressed, organizations can find ways to safely and effectively embrace these cloud solutions to increase efficiency with which data users and owners do their business.

Financial & competing interests disclosure

The authors have no relevant affiliations or financial involvement with any organization or entity with a financial interest in or financial conflict with the subject matter or materials discussed in the manuscript. This includes employment, consultancies, honoraria, stock ownership or options, expert testimony, grants or patents received or pending, or royalties.

No writing assistance was utilized in the production of this manuscript.