Cloud Service Providers

(1)

Contains Nonbinding Recommendations

Cloud Service Providers

Draft Guidance for Industry and

International Health Authority Staff

DRAFT GUIDANCE

This guidance document is being distributed for comments purposes only.

Document issued on: March 17, 2014

This guidance document has been developed by the Pharmaceutical User Software Exchange (PhUSE) Working Group on Lowering Barriers to Cloud Adoption and is subject to consultation and feedback from both industry and agency stakeholders.

Pharmaceutical User Software Exchange

(2)

1 Introduction

In 2013, the Pharmaceutical R&D Information Systems Management Executives Forum (PRISME forum) facilitated a working group within the Pharmaceutical User Software Exchange (PhUSE) to develop a guidance document on the topic of lowering barriers to cloud adoption in regulated life sciences operations.

While cloud adoption has been robust in industries outside the life sciences and in non-regulated areas of life sciences, organizations adhering to good laboratory, clinical, and manufacturing practices (GXP) are just now beginning to scale-up their understanding and interest in cloud-based services.

The PhUSE working group, comprised of volunteers from industry, consultants, and cloud service providers around the globe, began our effort of developing this document by identifying some key blockers to adopting cloud service providers in GXP-regulated life sciences. Through our discussions and brainstorming we quickly recognized that our different experiences and perspective on technology and GXP were barriers within the group, and we surmised that if this was true in relatively small team then industry as a whole must be having similar experiences. With that recognition we began to focus on four fundamental questions that would allow each of us to contribute from our own experiences while learning from the experience of others in the group.  What are the key concepts and different varieties of cloud computing available to GXP

organizations?

 Which current GXP regulations apply to cloud service providers and cloud-based computerized systems?

 What are the benefits and risks of the different types of cloud services in the context of GXP regulated organizations?

 What are the quality responsibilities of GXP organizations and cloud service providers?

This guidance document does not establish legally enforceable responsibilities. Instead, this guidance describes the PhUSE working group’s current thinking on a topic and should be viewed only as recommendations. The use of the word should means that something is suggested or

(4)

Contains Nonbinding Recommendations Background

2 Background

Cloud computing is becoming more available and powerful, and innovators have begun developing computerized systems to leverage the agility, scalability, and reliability that cloud services can offer. Some of these new cloud-based systems are specifically targeted to supporting food and medical product organizations performing GXP activities. Other cloud solutions are positioned as tools to improve and facilitate the diagnosis and treatment of disease in a healthcare delivery setting. In the late 1980s, health authorities began preparing policies and guidance documents on how to use computer hardware and software in support of GXP activities and, for medical devices, how to determine whether a computer-based product and/or software-based product is a device. Since then the use of computer and software products in food and medical product organizations has grown in number and complexity, and medical devices. Because health authorities have not yet developed overarching policies that holistically address the use and classification of computerized systems in food and medicines, however, industry practices around qualification, validation, and system development life cycles (SDLC) have been developed through standards development organizations like International Standards Organization (ISO) and industry associations like the Good Automated Manufacturing Practices (GAMP) forum, Pharmaceutical Inspection Co-operation Scheme (PIC/S) and PhUSE.

Cloud computing is one of the answers to the hosting needs based on the need for instant resources and demand for larger workloads, and the shift from Capex to Opex.

Organizations want instant scalability, pay as you go, throughput, while demanding high availability, SLAs, regulatory compliance, Support and Disaster recovery, but to not want to do it them self.

(5)

Contains Nonbinding Recommendations Background

What’s the strategic GXP value of cloud’s essential characteristics?  On-demand

 Broad network access  Resource pooling  Rapid elasticity  Measured service

(6)

Contains Nonbinding Recommendations Definitions

3 Definitions

3.1 Computerized Systems

In good laboratory, clinical, manufacturing and distribution practices (GXP), a computerized system refers to the combination of computer hardware, infrastructure software, software applications, and associated documents (e.g. user manuals and standard operation procedures) that create, modify, maintain, archive, retrieve, or transmit digital information related to the conduct of GXP operations.i_{With a traditional computerized system (Figure 1), a GXP-regulated organization}

(“GXP Owner”) purchases and installs the physical hardware, infrastructure software (operating system, database environment, application stack, etc) and a GXP Application. When these components are installed in the GXP Owner’s facility they’re said to be “on premises” and when they’re installed in someone else’s facility and remotely accessed they’re said to be “co-located” or “hosted”. GXP Application Infrastructure Software Physical Hardware Facility

Figure 1 – Traditional elements of a GXP Computerized System

Physical computer hardware and infrastructure software (“Infrastructure”) generally consists of commercial-off-the-shelf (COTS) products purchased “as is” and without extensive risk assessments by the GXP Owner. COTS products are generally considered to be higher quality and lower risk due to the higher volumes of commercial users in comparison to custom products. After installation the GXP Owner configures and test the Infrastructure to verify and document that it’s installed properly and operates according to the manufacturer specifications; this is typically referred to as qualification.

GXP Applications can be COTS or custom software and the level of purchasing controls usually depends on the intended use of the application and a supplier assessment. GXP applications are installed on the qualified infrastructure, configured for the specific GXP processes and procedures, and then performance tested to ensure the GXP Owner’s requirements are fulfilled; this is typically referred to as validation.

(7)

security groups in each virtual computer. Alternatively, multiple physical computers could be virtualized to act as a single virtual computer, permitting changes or maintenance on one of the physical computers without interruption to the virtual computer or the GXP applications running on it. The type of software that makes virtualization possible is called a virtual machine manager (“hypervisor”) and Figure 2 depicts the basic elements of such a virtualized computer system.

GXP Application Infrastructure Software Virtual Hardware Virtualization Services Physical Hardware Facility

Figure 2 – Elements of a Virtualized Computer System

This trend toward virtualization (with reference to our era diagram) emerged strongly during the internet era driven by the technological demands of industries as well as new capabilities to optimize computer resources and costs of operations.

3.2 Cloud Computing

Cloud computing is an approach to computerized systems that leverages the concepts and practical implementation of virtualization (described above) and takes it “to the next level”. Cloud computing is typically defined as a computing environment which is dynamically scalable and where virtualized resources are provided as services over a Local Area Network (LAN) or Wide Area Network (WAN) including the Internet. Essentially, multiple physical computers are outfitted with a hypervisor and connected to the Internet so that people who need computers can get as many virtual computers as they want, whenever they want, for as long as they want without having to buy, install, configure, test and maintain the physical computers themselves. The typical term for cloud systems connected directly to the internet, is public cloud. For cloud systems offered internally in an enterprise, the common term is private cloud. Terms are described later under deployment models.

Cloud computing services are typically delivered in three service models:

 Infrastructure as a Service (IaaS) offers the basic compute, storage and networking capability

that allows users to create their own virtual computer network including the automation needed to dynamically add and reduce resources based on user requirements. IaaS is typically oriented toward IT administrators and those who maintain computer networks.

 Platform as a Service (PaaS) builds on IaaS by offering additional resources needed to develop

and deploy cloud-based applications. PaaS resources typically include logical resources such as databases, file systems, and application operating environments (runtime systems). PaaS is typically oriented toward software developers and those who build computer applications.

(8)

 Software as a Service (SaaS) builds on IaaS and PaaS by offering complete software

applications directly to individuals and enterprise users. Aside from network file systems in IaaS, SaaS is the cloud service that most non-IT users will see and consume.

Cloud computing has also invoked the following “deployment models”:

 Private cloud services are provisioned and customized for a specific customer. This may be provisioned and maintained by the GXP Owner or by a supplier.

 Community Cloud is where multiple organizations with shared concerns share infrastructure.  Public cloud services are COTS solutions that are purchased “as is”. In a public cloud the

physical environment and hypervisor are owned and maintained by the cloud service provider (“supplier”) and provided as services to multiple tenants, each of whom owns and maintains their virtual environments and the associated data.

 Hybrid cloud is a combination of two or more cloud services.

3.2.1 Infrastructure-as-a-Service (IaaS)

IaaS refers to virtualized infrastructure resources being provided as an on-demand service. This includes virtualized servers and network devices with scalable processing capacity and reserved bandwidth for storage and Internet access. iii_{In IaaS, suppliers manage the facility, hardware, and}

virtualization layer, and users manage their virtualized infrastructure, platform, and applications.

GXP User Supplier

GXP Application Infrastructure Software Virtual Hardware

Hypervisor Infrastructure Services

Hardware Physical Hardware

Facility Facility

Figure 3 – Example of IaaS Responsibilities (not comprehensive) 3.2.2 Platform-as-a-Service (PaaS)

PaaS is similar to IaaS but also includes the required services for a particular application to work. In other words, PaaS is IaaS with a runtime management and software components required for a given application to work on the infrastructure. In PaaS, suppliers manage the IaaS responsibilities and the virtual infrastructure, and the user manages the platform and application responsibilities.

(9)

GXP Owner Supplier

GXP Application

Infrastructure Software Platform

Virtual Hardware Infrastructure Services Physical Hardware Facility

Figure 4 – Example of PaaS Responsibilities (not comprehensive) 3.2.3 Software-as-a-Service (SaaS)

SaaS is complete software applications provided as an on-demand service to food and medical product organizations performing GXP activities. SaaS systems are typically accessed via a web browser or installed application and the associated application data is stored and processed within the SaaS provider’s data centers.

GXP Owner Supplier GXP Application Infrastructure Software Virtual Hardware Infrastructure Services Physical Hardware Facility

Figure 5 - SaaS Responsibilities

3.3 GXP

“GXP” is a term that collectively refers to regulations for Good Laboratory Practices (GLP), Good Clinical Practices (GCP), Current Good Manufacturing Practices (cGMP), and Good Distribution Practices (GDP). For purposes of this guidance, Quality System Regulations (QSR) are also included in the meaning of GXP.

3.4 Solution

What’s the difference between a service, software and a solution?

3.5 Suppliers

Supplier refers to the organization providing cloud services to the organization using the services in support of GXP activities (“GXP user”). The supplier could be internal to the GXP user’s organization, such as an IT department, or external as in the case of commercial cloud service providers.

(10)

Supplier ---> GXP Owner ---> Consumer/Patient/Human Subject

3.6 Workload

In the parlance of cloud service providers, a workload represents a unit of work performed that’s represented by customer accounts, CPU cycles, I/Ops and storage. Regulated workloads, and their associated characteristics.

(11)

Contains Nonbinding Recommendations Scope

4 Scope

This guidance explains the PhUSE working group Scope is…

 Highlight principles and concepts,  GXP-oriented

 Geographic Jurisdiction Scope is not…

 not practical recommendations on implementation

 other regs/compliance requirements aren’t included but may still apply (healthcare data privacy, intellectual property, financials, etc)

(12)

Contains Nonbinding Recommendations Regulatory Interpretation of Cloud Suppliers

5 Regulatory Interpretation of Cloud Suppliers

Government agencies such as FDA (US), EMA (EU), MHLW (JP), CDSCO (IN) and SFDA (CN)iv_protect

patients and consumers from harmful foods, medicines, and devices by regulating manufacturers and requiring them to comply with Good Laboratory, Clinical, Manufacturing, Distribution, Marketing, and Servicing Practices (GXP). Under current laws, GXP-regulated companies (“GXP Owners”) using computerized systems must follow certain regulations and, building on the virtualization concepts in section 3.1 Computerized Systems (page 6), Figure 6 maps the elements of a virtualized computer system to some of the applicable GXP regulations.

Computer System Elements (Some) Applicable GXP Regulations

GXP Application COTS/Custom Applications, Validation, Quality Systems

Infrastructure Software Infrastructure Software, Qualification Quality Systems

Virtual Hardware Equipment, Qualification, Quality Systems

Virtualization Services Infrastructure Software, Qualification, Quality Systems

Physical Hardware Equipment, Qualification, Quality Systems

Facility Buildings and Facilities, Quality Systems

Figure 6 – Mapping Computer System Elements to Some GXP Regulations

Agencies like the FDA hold GXP Owners legally accountable for ensuring that computer systems are suitable for their use in GXP operations (“intended use”), and suitability assessments are generally based on the benefits the system provides in relation to the potential risk factors the system poses to patient safety, medical product quality, and GXP data integrity. The availability of a diagnostic application, for example, would be a risk factor to patients who require a time-sensitive treatment, as would the security of an inventory control system be a risk factor to medical product quality. When cloud services providers (“Suppliers”) deliver IaaS, PaaS, and SaaS to GXP Owners, a number of legal responsibilities are being delegated from the GXP Owner to the Supplier, and Purchasing Control regulations require GXP Owners to evaluate, select, monitor and document the performance of the Supplier.v

From a regulatory perspective, Suppliers are considered an extension of the GXP Ownervi_and

agencies have the legal authority to inspect the facilities and records of both GXP Owners and Suppliers.vii_{Suppliers may also be liable for causing the introduction of adulterated or misbranded}

medicines and devices into interstate or international commerce, where the causative factors for the violation are attributable to intrinsic defects in the service provider's hardware and software.viii

(13)

5.1 Quality Systems

Regulatory agencies operate under the premise that to ensure the safety and privacy of human subjects and patients, a quality system with policies and procedures must be established, implemented and maintained. The rationale behind this perspective is that no amount of retrospective testing can make an unsafe product safe, so it’s more effective to prevent unsafe products in the first place by requiring GXP Owners to continuously monitor and improve the quality of their product development and delivery processes.

When GXP Owners use cloud Suppliers, the quality system requirements for each Supplier depend on the intended use in GXP operations, the cloud service model (IaaS, PaaS, and SaaS). For example, a mobile medical application running on IaaS would have a different set of quality system requirements than a laboratory notebook application being provided as SaaS or an IaaS-hosted ERP system. Below are some quality system elements that cloud Suppliers may be expected to have depending on the GXP Owner’s intended use of the services:

 Change control and configuration management  Complaint handling and incident management  Corrective actions and preventive actions  Document controls

 Organization, personnel & management responsibility  Purchasing controls

 Quality unit and internal audits

Quality system responsibilities performed by Suppliers should be documented in a Quality Agreement with the GXP Owner.

5.2 Human Safety and Privacy Protections

When cloud services are used in clinical research, human subject protection regulations require that the safety and privacy risks to the human subjects are reasonable in relation to the anticipated benefits. For example, the safety and privacy risks of a cloud-based application acting as a food diary in a drug study would be different than the safety and privacy risks of a cloud-based imaging system used to diagnose a life-threatening disease.

Ethics committees (EC) and institutional review boards (IRBs) are responsible for reviewing and approving clinical research proposals, including the research computer systems posing potential safety and confidentiality risks to human subjects. Research Sponsors and Investigations must provide ECs/IRBs with evidence to demonstrate the system is well controlled and that potential safety and privacy risks are appropriately managed. An example of a research system security plan (SSP) is included in Appendix C.

(14)

Depending on the country and location where the research is being conducted, these human subject protections under GXP may be distinct from healthcare data privacy regulations. See section 5.8 Data Privacy and Protected Health Information.

5.3 Buildings and Facilities

The physical environment of a computer system can have a material impact on the performance and reliability of the system and can also pose risks to patient safety, medical product quality, and GXP data integrity. Data center facilities where GXP software and data reside on physical media should follow the applicable GXP requirements for design, construction, maintenance, security, and emergency preparedness of buildings. Depending on the deployment model of the cloud service, data centers may be managed by the GXP Owner or by a Supplier and whoever manages the data center is responsible for meeting the GXP facility requirements.

GXP facility responsibilities performed by Suppliers should be documented in a Quality Agreement with the GXP Owner.

5.4 Equipment

Computer and network hardware supporting GXP operations are considered by agencies to be “equipment” and subject to regulations for purchasing, installation, qualification, maintenance and emergency preparedness.ix_{In the cloud environment, the}

computer hardware has been virtualized so that there are now two sets of equipment:

1. the virtual devices (virtual servers, virtual network controllers, etc) running the GXP Application and data, and

2. the underlying physical equipment running the virtualization services.

Although the interpretation of whether virtual hardware constitutes equipment has not yet been established in GXP regulations or agency guidance documents, from a technology perspective a virtual device performs the same function as a

physical device but does so using virtual resources. Until a regulation or guidance becomes available, it is not inappropriate from a technology perspective to manage both the physical hardware and virtual hardware as GXP equipment.

GXP equipment responsibilities performed by Suppliers should be documented in a Quality Agreement with the GXP Owner.

What are virtual goods?

Virtual goods are physical goods that have been represented in a computer system. Like

paperbacks becoming ebooks and printed money becoming cryptocurrency, virtual computing devices are a new area for equipment and technology regulations.

(15)

regulations is to ensure that sufficient evidence is maintained for an agency to evaluate the compliance of a GXP Owner or Supplier and, more importantly, to trace any root cause issues that result in harming the safety or privacy of a patient, consumer, or research subject.

Recordkeeping requirements can include the minimum record content, retrievability, backup and protection, review and approval, as well as minimum retention periods. When GXP records are generated and maintained in GXP applications instead of paper, the application may require additional technical and procedural controls for electronic records and electronic signatures regulations. x_{These electronic records and signature requirements are generally more applicable}

to SaaS than IaaS, although not exclusively.

When GXP Owners use cloud Suppliers the scope of recordkeeping requirements depends on the regulations applicable to the intended use. Responsibilities for recordkeeping apply whether they are performed by Suppliers or GXP Owners. Additionally, records required under GXP regulations must be made available to agency inspectors upon request and without unreasonable delay, in some cases within 2 working days.

GXP recordkeeping responsibilities performed by Suppliers should be documented in a Quality Agreement with the GXP Owner.

5.6 Software

Under current GXP regulations and agency inspection reports, software is generally divided in two categories: infrastructure software (operating systems, database management systems, runtime environments, network device firmware, etc) and GXP applications (custom or commercial-off-the-shelf software). Infrastructure software is subject to qualification requirements and GXP applications are subject to validation requirements. See section 5.7 Validation and Qualification. In the virtualized cloud environment, there are two sets of infrastructure software: one running on the physical equipment and another running on the virtual equipment. Until regulations or guidance on virtual equipment become available, infrastructure software on both the physical and virtual equipment should be qualified. GXP infrastructure software responsibilities performed by Suppliers should be documented in a Quality Agreement with the GXP Owner.

GXP Applications either replace manual activities (workflows, messaging, form fields, etc) or make possible processes that could not otherwise be manually performed (big data computations, real-time monitoring, etc). Most GXP activities require documented processes (i.e. records), as a result agencies have generally come to view software as equivalent to “records”.xi_{The kind of record the}

software represents (test protocol, procedure, form, etc) depends on the GXP activity the software performs, and the recordkeeping requirements applicable to the software come from the regulations that correspond to the GXP activity. The process of developing GXP Applications must also be documented and those GXP applications that are considered medical devices and medical applications may also be subject to design, development and testing regulations depending on their medical device classification.

(16)

5.7 Validation and Qualification

Qualification and Validation are forms of testing performed by GXP Owners on their facilities, equipment, and software. The purpose of qualification is to verify and document that the item (physical or virtual) being tested is installed properly and operates according to the manufacturer specifications. The purpose of validation is to verify and document that a GXP application is installed properly, operates according to the manufacturer specifications, and satisfies the user/business requirements defined by the GXP Owner. The extent of qualification and validation testing depends on the type of system (infrastructure, commercial-off-the-shelf, or custom) and the risk the system poses to patient safety, medical product quality, and GXP data integrity.

In the cloud environment, each element of the virtualized system may require some amount of qualification and validation and, from a regulatory agency perspective, GXP Owners are responsible for ensuring the qualification and validation activities are adequate. Suppliers, however, may also incur liability for computer system validation, as well as hardware/software maintenance performed on behalf of users. xii

GXP qualification and validation responsibilities performed by Suppliers should be documented in a Quality Agreement with the GXP Owner.

5.8 Data Privacy and Protected Health Information

Cloud-based systems used in GXP research or commercial operations sometimes store and/or transmit personally identifiable information about patients, consumers and research subjects. Data privacy rules for personally identifiable information and protected health information vary from country to country and, in some cases, state to state. In many cases these data privacy requirements are in addition to the confidentiality requirements of the GXP human subject protections.

When cloud-based systems support GXP-regulated medical products in a healthcare setting, such as a cloud-based medical imaging system in a hospital, privacy and security rules for protected health information (PHI) may apply to the covered entities (i.e. providers) who use the GXP product, as well as their business associates supporting the system operations (i.e. GXP Owners and/or cloud providers).

In the context of GXP research, the scope of applicable data privacy regulations can depend on a wide range of factors such as the location where data is collected, the location where data resides on physical media, the nationality of the person who the data identifies, the data use permissions granted in any research subject consent forms, and whether the research data is also a part of the medical records. The human subject protection regulations generally require that computer systems containing private data are secure and, in the case of some cases like medical applications, certain security controls must be built into the software itself.

(17)

Contains Nonbinding Recommendations Procuring Cloud Services

6 Procuring Cloud Services

One of the main drivers behind the adoption of cloud computing is that cloud represents a simplification and commoditization of IT-related duties. Activities that were once costly and time-consuming for GXP Owners are now delivered as low-cost services that can be self-provisioned with the click of a button. Additionally, the quality and security capabilities of commercial cloud services often IT systems admini exceed the capabilities of GXP Owners who administer IT systems on a part-time basis. In GXP operations, this simplification of work and enhancement of control can reduce costs and increase agility and accountability in responding to new business and regulatory requirements.

It’s also important to recognize that cloud computing represents a fundamental shift in regulatory responsibilities between GXP Owners and their Suppliers. Responsibilities that GXP Owners have traditionally owned themselves are now being delegated to cloud Suppliers, both internal Suppliers within the GXP Owner’s organization (such as an IT department) and Suppliers external to the GXP Owner’s organization (such as a commercial cloud provider). This shift toward Suppliers, therefore, requires that GXP Owners update their purchasing practices to accommodate cloud services.

This section provides an overview of the considerations and processes for effectively sourcing, contracting, and managing cloud Suppliers.

6.1 Sourcing

The procurement process for onboarding new cloud Suppliers should begin with a sourcing phase that focuses on the GXP Owner planning and describing their business, technical and regulatory requirements, as well as educating themselves and their project stakeholders on the cloud market environment. During this education process it may be necessary for GXP Owners and their quality/regulatory teams to review their purchasing procedures, supplier assessment criteria and system development lifecycle (SDLC) processes to ensure they are appropriate for cloud service models and deployment models. GXP Owners who follow traditional waterfall development and ITIL methodologies should pay particular attention to their SDLC practices to ensure they can accommodate the current methodologies (such as Agile and DevOps) used by many commercial cloud service providers.

Throughout the sourcing phase, as the GXP Owner learns about and interacts with potential cloud suppliers, the system requirements, designs and risk assessments should become increasingly defined and the list of potential suppliers increasingly narrowed. Suppliers should support this process by providing information about their services and compliance capabilities, as well as providing input on the GXP Owner’s system-related plans. This should ultimately lead to the GXP Owner having a finalized set of system documentation and a short-list of suppliers to evaluate more thoroughly in the next phase of procurement, Contracting.

Depending on the GXP Owner’s intended use and the cloud services under consideration, a variety of sourcing documentation may be necessary for both the GXP Owner and the cloud Supplier.

(18)

GXP Owner Documentation: Supplier Documentation:

 Business Case Document  User Requirements Document

 Solution Design/Architecture Document  System Risk Assessment for patient safety,

product quality, data integrity, and/or PHI  Cloud market research information

 Proof-of-concept documentation and historical experience with Supplier (if any)  Request for Information (RFI)

 List of Potential Suppliers

 Public records

 Online documentation and whitepapers  Sales literature and presentations  RFI responses

 Compliance reports and certifications

6.2 Contracting

As the GXP Owner finalizes their system planning documentation, updates their quality system procedures, and develops a short list of potential cloud Suppliers, they transition from the Sourcing phase into a Contracting phase that focuses on evaluating the capabilities and risks of each potential Supplier. The extent of evaluation and acceptance activities should be based, in part, on the degree to which the Supplier can demonstrate a capability to provide quality products or services. When GXP Owners finalize their requirements and supplier assessment checklists, the compliance requirements should be applicable to all potential suppliers, including internal and external Suppliers.

GXP Owner’s should understand that how an external Supplier meets the requirements may not be the same as how the GXP Owner meets the requirements, but the point is that they still need to demonstrate that the requirements are met. This is often achievable through a mapping of the Supplier’s existing compliance controls and certifications with the GXP Owner’s compliance requirements and checklist items. Depending on the type of system and potential risks, the demonstration or evidence may be appropriate to collect during the evaluation process, but there are may be times where that can be collected later or followed-up on during the Managing phase of procurement.

Throughout the contracting phase the GXP Owner assesses each potential supplier and proposal and eventually decides which Supplier(s) they will enter into a contract negotiation with. Depending on the type of service and GXP Owner’s intended use, the contract may consist of multiple parts including a master agreement or enterprise agreement, a GXP Quality Agreement and/or other contractual provisions and responsibility-related documents. An example of a Quality Agreement and Quality Responsibility Matrix are included in the Appendices, and they should be modified to fit the particular requirements of each situation. The successful completion of the

(19)

GXP Owner Documentation: Supplier Documentation:

 Supplier Selection Criteria  Request for Proposal

 Supplier Assessment Checklist  Research System Security Plan  Quality Responsibility Matrix  Supplier Approval

 Architecture and RFP Review  Compliance Control Mapping  Evidence of Financial Solvency  RFP Response

 Terms of Use/Enterprise Agreement  GXP Quality Agreement

6.3 Managing

Once a GXP Owner approves a cloud Supplier and finalizes a written agreement, the procurement process transitions from the contracting phase into a phase of managing the Supplier relationship and monitoring performance.

The specific activities that take place in the managing phase very much depend on the cloud service model, deployment model, and intended use of the system. Generally, the system qualification and validation package should be complete and signed off by the GXP Owner prior to releasing the system for use in GXP operations. It may also be necessary for the GXP Owner and the quality/regulatory stakeholders to evaluate their change control processes to ensure they can accommodate the combination of policy-based controls, configuration management, and audit trails that are used in the highly automated environments of commercial cloud providers.

Metrics for service delivery, measurement and monitoring should be established and monitored by the GXP Owner, and criteria for resolving complaints and communicating CAPA processes should be established in collaboration with the Supplier. The frequency and depth of periodic re-assessments of the Supplier should be based on performance as well as changes to requirements such as adding new use cases or changes in regulations. Success during managing phase is when the GXP Owner’s business, technical and regulatory requirements are continually satisfied by the Supplier’s services and complaints are satisfactorily resolved.

Depending on the GXP Owner’s intended use and the cloud services under consideration, a variety of managing documentation may be necessary for both the GXP Owner and the cloud Supplier.

GXP Owner: Supplier:

 System Qualification/Validation Package  Approved procedures

 System Release  System logging

 Supplier monitoring and re-evaluation materials

 Service Delivery

 Customer complaint management  Change notifications

 Re-certification and compliance reports  Quality system

(20)

Contains Nonbinding Recommendations Appendices

7 Appendices

Appendix A. Quality Responsibility Matrix

Certain GXP Requirements may apply or not apply to some cloud delivery models.

Buildings and Facilities

Responsibilities Records _{(Select all that apply)} N/A GXP _Owner Supplier

Buildings should be designed, constructed, and located to facilitate cleaning, maintenance, and proper operations.

□

Building site risk assessment

□

Facility capacity requirements

□

Redlined or as-built facility drawings

□

Facility maintenance and repair records

□

Facility safety inspection records

□

Utilities, environmental controls, and backup systems should be designed, installed, monitored, and calibrated as appropriate for the data center and services.

□

Utility hookup and verification records

□

Calibration and monitoring records for environmental monitoring instruments

□

Facility backup system verification records

□

Standard operating procedures (SOPs) and responsibilities for facility maintenance activities should be maintained and approved.

□

Approved SOPs (including responsibilities)

□

Training records for responsible personnel

□

Facilities should be secured to protect against

theft and tampering, and access into areas where equipment are held should be limited to authorized personnel.

□

Approved building security plan

□

Current list of personnel with building access

□

Building visitor logs

□

Security system documentation

(21)

Equipment, Physical Infrastructure

Physical equipment should be of appropriate design, capacity, and location for its operation and maintenance.

□

Inventory of physical infrastructure components

□

Verification that physical equipment requirements are met by the utilities and physical environment (power, temp, etc)

□

New hardware models and assemblies should be qualified in a production-like environment before being released to production.

□

Approved test protocols demonstrating that new hardware can meet production environment requirements.

□

Approved test reports showing that requirements are met and test deviations are resolved.

□

Installation, maintenance, repair, and replacement responsibilities should be documented and proceduralized, including schedules and triggers for condition-based activities.

□

Approved SOPs for equipment installation, maintenance, repair, and replacement

□

Records for equipment maintenance, inspection, repair and replacement activities (including the name and date of the person(s) performing the activities)

□

Identifiers for physical hardware (serial numbers, asset tags, or other ID) should be logged and traceable to virtual machine identifiers such that any problems above the hypervisor that result from hardware problems can be traced to the specific piece(s) of equipment that caused the problem.

□

Hardware ID logs

□

Written (or automated) procedures for correlating physical hardware IDs and virtual hardware IDs

□

Hardware nonconformities resulting from defects in manufacturing or assembly should be reported to the manufacturer/assembler.

□

Records of hardware nonconformity reports

and communication with manufacturers

□

Hardware nonconformities resulting from

(22)

Qualification tests should prove that the system works as designed, including I/O error handling, error verification, correction verification, and allowable error over-rides.

□

Pre-approved I/O test protocols

□

Completed test report showing requirements

are met and test deviations are resolved

□

Software, Physical Infrastructure

Software manuals should be available and current with the software version(s) in production.

□

Software manuals

□

Release notes

□

Approved standard operating procedures (SOPs) should be maintained for software testing,

deployment, operations, and maintenance.

□

Approved SOPs

□

Backup of software in production should exist

and be maintained in a restorable state.

□

Backup and restore verification records.

□

System configuration should be verified

□

Baseline during validation life-cicle

□

Configuration Item Lists Devices (Firewall, IDS, SAN, etc)

_□

Software, Virtualization Services

(23)

Responsibilities Auditable Artifacts _{(Select all that apply)} N/A GXP _Owner Supplier

Device configurations

_□

Operating Systems

_□

Database software

_□

Equipment, Virtual Infrastructure

Computer equipment should be of appropriate design, capacity, and location for its operation

and maintenance.

□

Identifiers for virtualized hardware (serial numbers, asset tags or other ID) should be

logged.

□

Hardware ID logs

□

Virtual machine logs...

_□

□

O/S log files…

_□

Software, Application Platform

Platform software/run time environment

_□

□

(24)

Software, GXP Application

Procedures for development, testing, release to

production

□

Documentation and release notes

_□

Change Control

_□

□

Electronic Record and Signature Controls

_□

Validation and user acceptance testing

_□

□

Nonconformities

_□

□

Backups and version history

_□

Organizations and Personnel

Sufficient resources

□

Org chart indicating responsible area

managers

□

Personnel should have the education, training, and experience to allow them to perform their assigned functions.

□

Job descriptions

□

Resume/CV

□

Training records

□

(25)

…

_□

□

Privacy and Security

 Physical security is in buildings and facilities section

 Logical security is distributed in the appropriate software sections

Quality Systems

Effective arrangements for customer communication should address product/service information, contracts and amendments, customer feedback and complaints, change notifications, and advisory notices.

□

Written product/service literature and user documentation

□

Written procedure(s) for customer complaint/issue handling and investigations

□

Records of customer complaint investigations

□

Written procedure(s) for issuing and implementing customer advisory notices

□

Documented procedures should exist for reviewing nonconformities (including customer complaints), determining root cause, evaluating need for action, recording results of nonconformity investigations, and reviewing corrective actions for effectiveness.

□

Approved SOPs for corrective actions and/or nonconformity investigations

□

Records of nonconformity investigations (including customer complaints) and the corrective actions taken (if any)

□

Written process for reviewing effectiveness of corrective actions.

□

Documented procedures should exist for identifying potential nonconformities and their causes, evaluating need for action to prevent occurrence, and determining and implementing

□

Approved SOPs for preventive actions

□

Records of nonconformity trending,

(26)

□

Written process for reviewing effectiveness of preventive actions.

Document Controls

_□

Management responsibility

_□

□

Purchasing controls

_□

Recordkeeping

Recordkeeping requirements are distributed throughout checklist.

Validation and Qualification

(27)

Appendix B. Quality Amendment Considerations

When GXP Owners and cloud Suppliers form Agreements they need to consider Quality Amendments for GXP compliance. This Appendix outlines the sections and considerations for shared responsibilities between cloud Suppliers and GXP Owners.

Effective Date

Date(s) the agreement and amendment are effective.

Points of Contact

Person

Service related issues and events shall be reported by customer to supplier using the following method(s):

□ Email: <email address>

□ Ticketing System: <list url of ticketing system> □ Phone: <list customer service number>

□ Other: <list method>

The following representatives are the points of contact for notices of amendments, termination, resolution of compliance issues, and notification of regulatory inspections.

Customer Supplier Primary <name> <title> <telephone> <email> <postal address> <name> <title> <telephone> <email> <postal address> Secondary <name> <title> <telephone> <email> <postal address> <name> <title> <telephone> <email> <postal address> Other Agreements

This agreement is in addition to all other agreements between the parties, if any, (the “Master Agreement”). In the case of conflicts between the Quality Agreement and Master Agreement, the following will prevail:

(28)

□ Master Agreement □ Quality Agreement

Amendments to Quality Agreement

Quality agreements should be established prior to service delivery and amended only by the written consent of both supplier and GXP Owner.

If an amendment is proposed, the proposing party should circulate the proposed amendment to the appropriate contact person at Supplier and GXP Owner for review and internal approval. The appropriate contact person at Supplier and GXP Owner is listed on the Point of Contact section.

Applicability and Definitions

GXP Owners may have both GXP and non-GXP accounts with a particular supplier. A “GXP account” means an account identified by the GXP Owner in connection with GXP activities. This agreement should only be applicable to GXP accounts.

Suppliers may provide multiple cloud services and, depending on their certification level, may not meet the requirements to be considered a GXP-eligible service. Unless all services provided by a particular supplier are GXP-eligible, then a list of eligible services should be maintained in the agreement:

 <name of services>

GXP Accounts

 Identification of GXP Accounts

Customer should maintain a list of all billing and access accounts

Customer will maintain and provide current list of GXP accounts to Supplier  Appropriate Use of GXP Accounts

 Appropriate Configurations of Services Encryption: will use encryption

(29)

…

 Consents

Have proper consents for data held in services  Issue Reporting

Report issues in a timely manner

Audits and Inspections

 Continuous Monitoring

 Mutual Audit Rights For-cause criteria

At requester’s expense until proven otherwise  Regulatory Inspection Support

Mutual SLA for regulatory inspections in connection with GXP users accounts If GXP Owner is audited…

If supplier is audited in regards to GXP Owner

Quality Responsibility Matrix

(30)

Appendix C.

System Security Plan (SSP)

This is an example of a research system security plan that Sponsors and Investigators can use to document their systems that could potentially impact the safety and confidentiality of the human research subjects.

Information System Name/Title

[Name of information system(s).]

Information System Owner

[Name and contact information for study sponsor, investigator or other system owner.]

Other Designated Contacts, Including Those with “root” Access

[Names and contact info for other relevant system technicians or administrators. Should include research system administrator, cloud service provider info, etc.]

Assignment of Security Responsibility

[Name person(s) responsible for implementing security policy.]

General System Description/Purpose

[Describe the system, its purpose and it’s high-level components. Indicate if the system is standalone, a compute farm, shared use system, desktop PC, etc. Identify the operation system and version. Indicate technical processing and storage specs.]

Physical System Environment

[Identify the location where the system’s physical media storing data is located. Identify the physical access controls in place to protect the physical infrastructure.]

System/Network Diagram

[Provide a network diagram or system architecture diagram. Include relevant off-site links, data storage locations, user access points, firewalls, etc]

System Interconnections/Information Sharing

(31)

Identify access controls that restrict data access to authorized individuals. Identify controls to protect data from being copied to unapproved locations. Identify controls to identify, authenticate and control external user access.

 Awareness and Training

Identify user training processes and training materials for computer systems security and sensitive data access.

 Configuration Management

Describe procedures and tools to track system changes throughout the conduct of the research.  Auditing and Accountability

Identify audit planning for system and infrastructure security. Describe audit frequency and audit record maintenance.

Appendices

 Appendix A: Hardware Listings List virtual hardware resources  Appendix B: Miscellaneous Documents

 Appendix C: Training and Certification of key IT Personnel

Including research staff training summary. If training records are maintained by cloud service provider, verify that Supplier provides security training to persons with administrator level access.

(32)

Appendix D. Frequently Asked Questions (FAQ)

 Should qualification performed suppliers and cloud service providers require approval by a Quality Unit?

 What is the line of electronic records and signatures with regard to supplier quality systems vs user organization application?

 Is infrastructure software considered a medical device data system (MDDS)?

Infrastructure software (including virtualization systems) that is not customized outside of its manufactured specifications are not generally considered a medical device data system. For example, components with the following functions by themselves are NOT considered MDDS if they are used as part of general IT infrastructure even though they may transfer, store, display or convert medical device data, in addition to other information.xiii

 Can Agile or DevOps models of system development comply with GXP regulations? <answer>

 About the interpretation of GXP equipment regulations apply to both physical and virtual devices, won’t that result in a burdensome approach?

(33)

8 References

i_{Food and Drug Administration. Guidance for Industry: Computerized Systems Used in Clinical Investigations.}

ii_{“Virtualization.” Wikipedia. Wiki Media, n.d. Web. 11 Feb. 2014.}

iii_{Furht, Borko and Armando Escalante. Handbook of Cloud Computing. New York: Springer, 2010. Print.}

iv_{http://www.pharmweb.net/regulatory.html} v http://www.fda.gov/downloads/Drugs/DevelopmentApprovalProcess/SmallBusinessAssistance/UCM37760 1.pdf vi_{http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=210.2} vii_{http://www.fda.gov/downloads/ICECI/Inspections/IOM/UCM127428.pdf} viii_{http://www.fda.gov/ICECI/ComplianceManuals/CompliancePolicyGuidanceManual/ucm074373.htm} ix_{http://www.fda.gov/ICECI/ComplianceManuals/CompliancePolicyGuidanceManual/ucm074372.htm} x_{http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11&showFR=1} xi_{http://www.fda.gov/ICECI/ComplianceManuals/CompliancePolicyGuidanceManual/ucm074372.htm}

xii_{Food and Drug Adminstration. Compliance Policy Guide 425.200 Computerized Drug Processing; Vendor}

Responsibility.

xiii

http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/ MedicalDeviceDataSystems/ucm251906.htm

Cloud Service Providers