Selecting Implementing and Maintaining Cloud Systems for The Life Sciences Industry

Selecting, Implementing and Maintaining Cloud Systems for the Life Sciences Industry
www.usdm.com A White Paper Published by USDM Life Sciences 1
Selecting, Implementing
and Maintaining Cloud
Systems for the Life
Sciences Industry
How to utilize your Cloud Supplier’s expertise, quality
management systems and processes in the real world –
to add value to your implementation project and live
system usage.
A White Paper by: David Blewitt,
Vice President of Cloud Compliance, USDM Life
Sciences
December, 2015

Table of Contents
Selecting the Right Cloud Provider….......................................4
Identifying Your Own Inefficiencies .........................................7
Traditional Problem Areas........................................................................................... 7
Why Do We See These Issues?.................................................................................... 8
What's Worked Elsewhere (And What Hasn't)............................................................ 9
By Way of Risk and Cost Reduction- What's Appropriate, What Isn't, and How Do I
Determine the Difference?......................................................................................... 10
Utilizing This Information......................................................................................... 12
Critical, Key, and Desirable Supplier Elements.....................12
Critical Supplier Elements ......................................................................................... 13
Key Supplier Elements............................................................................................... 13
Desirable Supplier Elements...................................................................................... 13
GxP Functionality With Cloud Solutions? - Why it Makes Sense Now.................... 13
The Benefits of Cloud Computing............................................................................. 14
Overview of Cloud Architecture, Security, and Infrastructure.................................. 15
Public, Private, or Hybrid?......................................................................................... 15
Cloud Architecture: Single vs. Multi-Tenant............................................................. 16
The Power of the Cloud ............................................................................................. 18
Maintaining the System and The Supplier Relationship.......22

Copyright © 2015 USDM Life Sciences
All rights reserved. No part of this publication may be reproduced, stored in a
retrieval system, or transmitted, in any form or by any means, electronic,
mechanical, photocopying, recording, or otherwise, without the prior
permission of the copyright owners.
Simplify, Unify and Optimize™ and USDM™ are trademarks of USDM in
the United States and other countries. All other trademarks are the property of
their respective owners.
All other brand, company, and product names are used for identification
purposes only and may be trademarks that are the sole property of their
respective owners.
Document Title: Validation Considerations for Mobile Devices in Life
Sciences Applications
Published by USDM Life Sciences, November, 2013
Any comments relating to the material contained in this document may be
submitted to:
USDM Life Sciences, LLC
535 Chapala Street
Santa Barbara, CA 93101
or by email to: usdm@usdm.com

The intent herein is to
give an overview of
how to actively utilize
your Cloud Supplier’s
expertise, quality
management systems
and processes in the
real world as a true
value add to your
implementation
project and live
system usage.
Executive Summary
In the past, it has been difficult for some organizations to adopt a real, useable
approach to leveraging supplier documentation and activities to reduce their
communication, qualification and ongoing maintenance burdens. Time and
again suppliers are selected merely on the basis of initial cost and time,
without true considerations given to risk based factors that could truly reduce
short and long term risks and financial burdens, as well as project and live
system efficiency.
The intent herein is to give an overview of how to actively utilize your Cloud
Supplier’s expertise, quality management systems and processes in the real
world as a true value add to your implementation project and live system
usage.
Furthermore – The answer to a very common question that often comes up –
“How can I ensure my cloud system is implemented in a compliant manner,
and is maintained during the constant state of flux seen within the cloud?”.
Leveraging supplier’s activities is not just about reducing testing burden on
you as a customer. There are many other aspects – explained herein, that
should also be considered to gain true value.
Finally, one of the main goals here is to help you identify the types of
questions you should be asking yourselves as an organization when
identifying your suppliers.

As most readers of
this publication will
know, for the past few
years, and certainly
since the latest
version of the
GAMP® guide –
GAMP® 5, it has
been recommended
practice for Life
Sciences companies
to include leveraging
supplier’s activities in
their quality practices
and project
methodologies.
Time and again
suppliers are selected
merely on the basis of
initial cost and time,
without true
consideration given
to risk based factors
that could truly
reduce short and long
term risks, financial
burdens, as well as
project and live
system efficiency.
Selecting the Right Cloud Provider…
As most readers of this publication will know, for the past few years, and
certainly since the latest version of the GAMP® guide – GAMP® 5, it has
been recommended practice for Life Sciences companies to include
leveraging supplier’s activities in their quality practices and project
methodologies. As can be seen below, it is in fact one of the key concepts of
the guidance.
This has never been truer than with the recent uptake in the numbers of
companies choosing to utilize cloud systems and vendors to accomplish their
business processes.
So why has it often been difficult for some organizations to adopt a real,
useable approach to leveraging supplier documentation and activities to
reduce their communication, qualification and ongoing maintenance burdens?
Time and again suppliers are selected merely on the basis of initial cost and
time, without true considerations given to risk based factors that could truly
reduce short and long term risks and financial burdens, as well as project and
live system efficiency.

“How can I ensure
my cloud system is
implemented in a
compliant manner,
and is maintained
during the constant
state of flux seen
within the cloud?”.
The intent herein is to give an overview of how to actively utilize your Cloud
Supplier’s expertise, quality management systems and processes in the real
world as a true value add to your implementation project and live system
usage. For example to help you understand how companies ensure they select
a supplier which will not only provide a quality product and customer
experience initially, but will be in a good place to ensure that that product can
be maintained in a qualified state throughout its lifetime.
Furthermore – I am to answer a question that often comes up – “How can I
ensure my cloud system is implemented in a compliant manner, and is
maintained during the constant state of flux seen within the cloud?”.
It should be noted of course that leveraging suppliers activities is not just
about reducing testing burden on you as a customer. There are many other
aspects that should also be considered to gain true value. These are explained
below, along with real world methods for achieving that value.

In order to derive
these internal
questions, you need to
first ask yourselves
how and why you are
going to use this
information to reduce
risk and costs
internally.
Most issues do not
arise until the
equipment is actually
delivered and
installation begins
(and sometimes even
earlier with delivery
deadline issues) and
the discussions arise
over increasing costs
and slipping
schedules.
Identifying Your Own Inefficiencies
In order to derive these internal questions, you need to first ask yourselves
how and why you are going to use this information to reduce risk and costs
internally.
Some real world answers to these questions have been provided below, but
what should be clear is that once you’ve identified these answers, you can use
the results to derive your internal set of requirements when identifying cloud
potential suppliers, as well as to drive the communications process with those
suppliers.
Traditional Problem Areas
One of the most common problems with trying to leverage your suppliers own
activities, is that you don’t know what you don’t know. This is certainly the
case for companies that are not as mature when it comes to their System
Development Life Cycle (SDLC), but in all companies the precise problems
they are likely to encounter aren’t really available in a manner that’s easy to
grasp. Most issues do not arise until the equipment is actually delivered and
installation begins (and sometimes even earlier with delivery deadline issues)
and the discussions arise over increasing costs and slipping schedules.
The majority of the example issues shown below relate to the implementation
and development of the system rather than logistical problems – such as
delivery issues – although these types of issues will also be reduced by

following the guidance given herein.
Typically seen issues during system implementations/rollouts or upgrades are;
• System delivered cannot be customized readily or is not a simple out
of the box system that meets your needs as is
• The documentation provided around certifications and verification
activities does not fit with your quality plan and testing strategies –
examples include;
o Lack of up to date installation instructions – may relate to older
versions or versions that are not complete or easy to follow
o Lack of (or incomplete) testing scenarios and scripts (and
therefore not useable in your risk based testing strategy to
reduce time and costs).The supplier is either unable to provide
useable verification documentation (for installation and
functional testing phases), or is in fact unwilling to provide it
as it is not contracted for.
o Certification evidence (e.g. 510k) relating to the latest and
greatest version of the system you are purchasing
• Supplier is unable or unwilling under current contracts to provide
assistance with requirements gathering, risk assessments, the creation
of functional and other specifications, system configuration and
installation and testing as needed.
• Support and maintenance processes are not established as part of a
Quality Management System and therefore cannot be assured
• Some documentation, standard technical and configuration
specifications for example, may also be seen by the supplier as
proprietary - and they may be unwilling to provide it. This type of
documentation can be used to help build up the full system picture,
document the system configuration (which you as the system owner
are responsible for), enable test activities and configuration
management as well as enhancing the change control process.
Why Do We See These Issues?
• Supplier audit procedures are either not established (as part of your
own QMS) at all, or are not sufficient to cover the types of issues
described above
• Insufficient consideration given to the suppliers own QMS – how
mature is it, is it available for review, do they have any quality
certifications, are they willing to provide examples upon request, are
the communication, change control, upgrade and issue resolution
processes understandable and in line with your own expectations and
requirements?
• Requirements management processes not effectively designed leading

Establishing a
supplier assessment
and management
process following
recognized guidance
(e.g. GAMP5 section
7 and Appendix M2)
prior to the
instigation of new
system selection,
implementation or
upgrade projects has
shown repeatedly to
significantly reduce
costs, time and issues.
to incorrectly or incompletely defined system requirements given to
the supplier for items including;
o System Installation instructions (and IOQ Plans/Templates)
o Incorrect system specifications around system size, response
times, processing power
o Interface considerations – how readily will the new system
sync with your current infrastructure, how standard are the
interfaces required, how do I get my legacy data from my old
systems into my new system?
• Minimal/no requirements defined for the precise types of
documentation available relating to verification activities already
undertaken by the supplier, including;
o Full set of test evidence as well as templates for all standard
configuration items
o Example use cases/Business Process Flows for standard
processes, to be utilized when developing user/functional and
technical specifications as well as verification scenarios.
• Contract negotiations did not include the purchasing of configuration
and technical documentation, with appropriate non-disclosure clauses
What’s Worked Elsewhere (and What Hasn’t)?
Establishing a supplier assessment and management process following
recognized guidance (e.g. GAMP5 section 7 and Appendix M2) prior to the
instigation of new system selection, implementation or upgrade projects has
shown repeatedly to significantly reduce costs, time and issues.
Of course this process should be part of your own Quality Management
System. It is no good ensuring your supplier has everything in order if your
own processes are not in place (including your own requirements management
process). You should also know the types of system interfaces you will
require, what data needs will pre-exist and whether you intend to host your
own system or utilize the cloud or a third party host (or at least have these as
considerations).
The process should call for clarification (in the form of documentary
evidence) from the supplier that they can meet your specific needs as a
customer. This evidence should include;
• Mature Quality Management System processes – established
according to a recognized practice – (e.g. ISO9000) – including
support, change control, communication and maintenance procedures
• Other system user references and testimonials (to enable comparisons
of the suppliers, as well as gauging the system’s ease of
customizability).

The provided
documentation should
be assessed for
suitability, accuracy
and completeness.
There should of
course be flexibility
regarding acceptable
format, structure and
documentation
practices.
• Current certifications – including the qualification dates, relating to the
system version you are considering
• Installation instructions and IOQ’s – relating to the correct version of
the system under consideration
• Functional and requirements specification examples
• Training records for appropriate support staff
• Testing Scenarios/Scripts – executed, reviewed and approved by the
suppliers quality organization, showing the testing of standard
configuration has been completed successfully
• Establishment of precedents showing willingness and ability to
participate in risk management activities
• Ability and willingness to provide (standard – i.e. as delivered)
configuration documentation for all areas of the system
The provided documentation should be assessed for suitability, accuracy and
completeness. There should of course be flexibility regarding acceptable
format, structure and documentation practices.
Satisfactory answers and documentary evidence can be used to justify using
the suppler documentation as a means to reduce your qualification efforts on
your side (utilizing a risk based approach to implementation and
qualification), as well as ensuring that you know the system can be
maintained per your needs in the future.
By Way of Risk and Cost Reduction - What's Appropriate, What Isn't,
and How Do I Determine the Difference?
Unnecessary costs can often be avoided if the correct questions are broached
at initial sales and project meetings with the supplier’s representative.
It is accepted that regulated companies seek to maximize supplier
involvement throughout the system life cycle in order to leverage knowledge,
experience and documentation, subject to a satisfactory supplier assessment
As an example of regulatory bodies acceptance of this approach, released in
2011, Annex 11 on Computerized Systems states that ‘the competence and
reliability of a supplier are key factors when selecting a product or service
provider’; and of course ‘Leveraging Supplier Involvement’ is also one of the
5 key concepts of the GAMP®5 guidance. The FDA’s current Good
Manufacturing Practices (cGMP’s) for the 21st
Century Initiative and
associated guidance is also promoting science based risk management.
The precise amount of “leveraging” that’s acceptable depends on risk. Risk
ultimately posed to patient safety as well as to your company (in the form of
time and money as well as reputation).

Non Configurable
systems are “off the
shelf”, out of the box
systems that are
simpler and require
only moderate
installation
qualifications.
.
System categorizations (as shown in GAMP5) range from Non-Configurable
Products (category 3), thru Configurable Products (category 4) to Customized
Applications (category 5), and each poses a different level of risk.
Category 3 – Non Configurable systems are “off the shelf”, out of the box
systems that are simpler and require only moderate installation qualifications.
If pre-existing IOQ’s are available, it is acceptable to simply re-enact these on
your own infrastructure. And of course, if the supplier can provide evidence
of the verification activities performed on these non-configurable systems
(performed under a QMS) then these should simply be referenced by your
final validation report and stored with the system installation files as evidence
of satisfactory compliance with your needs. No further system verification
activities should be necessary where these factors are in place. Your own
change control processes and those of the supplier should be used from that
point, and it is important to ensure that these (and other issue resolution and
communication processes) are compatible when assessing the supplier.
Category 4 – For Configurable systems, while it is not recommended to
remove qualification and verification activities to the extent as shown for
category 3 systems, it is possible to leverage the activities of the supplier to
significantly reduce them. The IOQ’s can be leveraged and amended as
needed and re-executed, the configuration and functional specifications can be
followed verbatim, and the provided test scenarios can be (edited if needed
and) re-executed on your systems once configured. Of course any elements
that come “pre-configured” can be identified via risk assessments involving
the supplier, and the verification of those elements can simply reference the
supplier activities and documentation. The same considerations should be
given to change control, issue resolution and communication processes.
Category 5 – Where significant customizations to the system – be it for
system hardware configurations, or to the system software, a greater level of
risk is prevalent and the qualification and verification activities should be
commensurate to this level. It is more likely that the supplier will have no
useable documentation for elements specific to your use of the system. So it
follows that you will need to produce much of the documentation from scratch
yourselves. Any standard and configured elements can of course be identified
by risk assessments. The time and costs associated with a customized system
therefore rise not only according to the amount of custom development, but
also to the amount of documentation and verification activities you must
perform and produce – because the risk posed is greater and less leveraging of
information is possible. It is also even more critical that mature QMS
processes including change control, communications and issue management

The time and costs
associated with a
customized system
therefore rise not
only according to the
amount of custom
development, but also
to the amount of
documentation and
verification activities
you must perform and
produce – because
the risk posed is
greater and less
leveraging of
information is
possible.
are in place. (E.g. any patches should be effectively managed using these
processes as they will have an unknown effect on customized elements).
Utilizing this information
Shown below is a summary of how to utilize the information from the
preceding sections to drive the creation of the requirements you have as a
customer when selecting a supplier;
Firstly – ensure your own house is in order – your QMS should be created or
updated to maximize the benefits from your suppliers.
Utilizing industry guidance and best practices (e.g. GAMP 5), it is critical to
establish your internal supplier management and selection processes.
Identify your system requirements in as much detail as possible – including
the data and interface requirements, and where possible whether the system
you need should be a category 3, 4 or 5 system – as this will drive the decision
making process. (This may not be know at the early stages but should be a
consideration when looking at time, costs and complications).
Determine your hosting needs – in house (Do you have qualified
infrastructure? This is an important consideration and one that is often
overlooked), cloud or external hosted.
The supplier should also have as many of the following as possible;
• A Mature QMS (including established change control, issue
management and communications processes)
• All relevant and required (and current) certifications
• Installation instructions and IOQ’s
• Requirements examples
• Training records
• Example and templates for Testing
• Willingness to participate in risk management activities
• Configuration documentation for all areas of the system
Critical, Key and Desirable Supplier Elements
There are a number of elements that have been discussed herein. Some of
these elements are more critical than others. Some are absolute showstoppers
and should be considered as must haves. Others are key to success and some
are desirables – the so-called “nice to haves”.

A desirable supplier
element is willingness
to participate in risk
management
activities.
Critical Supplier Elements
• Up to date certifications (e.g. 510k) related to the system version
under consideration
• Mature QMS
• SLA - including critical elements such as change control,
configuration and functional specifications, issue management and
communications.
Key Supplier Elements
• Installation instructions and IOQ’s
• Requirements examples
• Training records
• Examples and templates for Testing
• Configuration documentation for all areas of the system
Desirable Supplier Elements
• Willingness to participate in risk management activities
• Hosting considerations (ability to host, cloud availability, ease of
installation and cost of infrastructure and equipment)
Implementing Cloud Systems
• GxP Functionality with Cloud Solutions – why now?
• Cloud System benefits
• Overview of Cloud Systems security and Infrastructure Qualification
• The Power of the Cloud
• Overcoming the challenges of Cloud Compliance – How to implement
in a compliant yet efficient and cost effective manner
• Lower cost to implement and maintain
• Higher rate of innovation
• Security
• Reliability
• Accessibility
GxP Functionality With Cloud Solutions? - Why it Makes Sense Now…
The usage of Cloud Platform technologies within Life Sciences companies is
not a new concept. However, historically – adaptation even within Life
Science companies has typically been limited to using “Non GxP”
functionality – such as Sales Call scheduling and financial services.
Times are changing - with numerous medium to large Life Sciences

With only minor
adaptation, best
practice validation
methodologies that
have been tried and
tested for many years
are now being used at
more and more Life
Sciences companies
to qualify, validate,
and maintain Cloud
Platforms and
accompanying GxP
applications.
companies paving the way to showing that the huge potential and power of
the Cloud can be used to perform a multitude of GxP processes, all
intertwined and all Qualified, Validated and Regulatory Compliant.
With only minor adaptation, best practice validation methodologies (e.g.
GAMP 5 – A Risk Based Approach to Compliant GxP Systems) that have
been tried and tested for many years are now being used at more and more
Life Sciences companies to qualify, validate and maintain Cloud Platforms
and accompanying GxP applications.
The shift of some of the compliance effort to your suppliers is already an
accepted approach where relevant and performed according to regulatory
expectations. Both Legacy cloud platforms and those being considered for
New or Upgraded implementations at Life Sciences companies can now be
taken the extra step to take advantage of their huge power and configurability
and can be shown to be compliant with the FDA regulatory expectations (e.g.
21 CFR Part 11).
The FDA themselves have seen the light – and are now embracing the power
and usefulness of the Cloud, utilizing and leveraging cloud power for their
“Big Data” initiatives to enable eSubmissions, storage, analysis, and sharing
of enormous data sets. They are embarking on a progressive process to
upgrade their technology platforms in line with current and future
requirements. Only with the Cloud are these initiatives possible.
The Benefits of Cloud Computing

Public clouds are
available to everyone
but provide little
visibility and no
control over the
location of a
customer’s data.
Public cloud
customers share the
same infrastructure
pool, which provides
economies of scale
with costs being
spread across many
users.
Overview of Cloud Architecture, Security and Infrastructure
Public, Private, or Hybrid?
Most cloud applications today are using a “public cloud” infrastructure but
other options are available. Here’s a list of different cloud infrastructure types
and how they’re different:
Public Cloud - Public clouds are available to everyone but provide little
visibility and no control over the location of a customer’s data. Public cloud
customers share the same infrastructure pool, which provides economies of
scale with costs being spread across many users.
Use a public cloud when:
- You want scalability at a relatively low cost
- You want to utilize a pre-built cloud platform for applications such as
CRM, customer service, accounting, HR, etc.
- You desire less infrastructure administrative controls - which can be
seen as a benefit, allowing resources to spend time on other business-
value tasks
Private Cloud – A private cloud is a cloud infrastructure dedicated to a single
organization. Private clouds can be hosted internally or by a third party cloud
provider. Private clouds allows businesses to host applications in the cloud
while addressing data security and control concerns.
A private cloud is for you when:
- You need your data independent from anyone elses but want the
efficiencies that cloud provides
- Security and control are tantamount to the success of the application
regardless of cost
- Willingness to have a higher level of engagement in the administration
and development of a virtualized environment
Hybrid Cloud – Hybrid clouds are a combination of private and public clouds
and offer the benefits of both deployment models.
A hybrid cloud should be considered when:
- A pubic cloud can be used for customers while a private cloud is needed
for internal IT
- Customer interaction is in the public cloud while data is stored in private
- Managing multiple cloud environments is acceptable for your
organization

This architecture can
provide consistency
and control but is
also security
vulnerability.
Infrastructure and
data security should
be near the top of the
list of concerns when
considering a move to
the cloud.
Cloud Architecture: Single vs Multi-Tenant
Another thing to consider, beyond the type of cloud, is the architecture of the
cloud environment. One aspect of this architecture can be described as
tenancy – single vs multi.
Single tenancy is where each customer has their own dedicated hardware to
serve up their application. This architecture can provide consistency and
control but is also security vulnerability. Single tenancy represents a single
point of entry that poses a greater risk to data theft and loss.
Multi-tenancy is where many users share the same hardware yet have
exclusive access to their particular data. This model does not present a less
secure architecture since a customer’s data is spread over many servers so that
a breech of one does not give access to full data set.
Infrastructure and data security should be near the top of the list of concerns
when considering a move to the cloud. Today, cloud vendors realize that in
order to play in the same ballpark as the on premise vendors and establish
trust with customers, they need to maintain world-class data centers and
security as defined below:
Facility Security:
• 24x365 on site security
• Biometric readers, man traps
• Anonymous Exterior
• Silent Alarms
• CCTV
• Motion detection
Network Security:
• Fault tolerance External Firewall
• Intrusion Detection Systems
• Best Practices secure systems mgt
• 3rd party vulnerability assessments
Architecture and Application Security:
• TLS data encryption
• Rigorous password security policies
• SOC1, 2 and 3 and SysTrust Certifications

Vendors have begun
to establish
comprehensive IQ
documentation to
demonstrate that
qualification of their
infrastructure, and
the establishment of
maintenance
processes to ensure it
remains compliant on
an ongoing basis.
• ISO 27001 Certification
• HIPAA compliance
• Secure architecture options such as private or public clouds
• Multi-tenant architecture for data security
Infrastructure Qualification (IQ)
Vendors wanting to provide SaaS to the Life Sciences world have also
realized that it is not simply desirable to have a well-managed, well
documented and well controlled infrastructure, it is in fact a pre-requisite for
almost all end customers who view the compliance world from a risk based
perspective.
For this reason, Vendors have begun to establish comprehensive IQ
documentation to demonstrate the qualification of their infrastructure, and the
establishment of maintenance processes to ensure it remains compliant on an
ongoing basis.
Companies should be looking to Cloud Vendors to be able to provide, at a
minimum, the following elements:
• Quality Manual
• Security Procedures
• Communications and Release Management Procedures
• Change Control Procedure
• Infrastructure and Installation Qualification evidence for all Data
Centers (including ancillary support structures and Disaster Recovery
back-up facilities), all hardware, and all software.
• Training Procedures and evidence of employee training.
• Full access to their facilities to Client Auditors.
Highly desirable elements from a vendor perspective would be:
• Standard – Core Platform System Requirements
• Verification Scripts based on SR
• Additional documentation associated with the Validation Lifecycle
that can be leveraged by Clients to reduce their burden and increase
their ROI
xThe Power of the Cloud
The partners shown below (not exhaustive) have developed solutions to
numerous Life Sciences compliance and regulatory requirements. With the
possibilities that Cloud Computing brings to the table, and with these types of
hugely powerful applications available, the possibilities are endless.

Salesforce.com
provides a hugely
powerful and
configurable suite of
applications
including but not
limited to Patient
Case Management,
Compliant
Management, and
Sample Management.
Cloud based FDA
regulated IT systems
must be established
and maintained at
compliance levels
equal to internally
hosted systems- and
this has already been
done and proven
successful during
multiple audits of
various cloud
vendors.
• Provides a hugely powerful and configurable suite of
applications including but not limited to Patient Case Management,
Complaint Management, Sample Management
• Provides Regulated presentation management for
mobile clients with Compliance tools for Chatter collaboration
• provides services for Sunshine Act reporting
• provides a great solution for customers to
enhance workflows by adding in Electronic Signature and Digital
Signature capabilities – including Part 11 compliant e-signature
solutions that bolt onto a myriad of other GxP applications
• enables Part 11 compliance solutions on
Force.com – with Cloud-based solutions designed specifically for the
needs of the life science industry
• provides Field Service Management relating to
Work Orders, Warranty Entitlements, Inventory & Parts Logistics,
Advanced Scheduling & Workforce Optimization, and Mobile
• provides Validation accelerators, automation tools,
and full Governance consulting services specific to the Life Sciences
Industry for all of these tools, and have in fact worked directly with a
number of them to enhance or even develop the solutions alongside
the Vendors
Overcoming the Challenges of Cloud Compliance – How to Implement
in a Compliant Yet Efficient and Cost Effective Manner
The establishment of a Robust, meaningful and useable SLA will enable you
to ensure that your cloud supplier has in place all the necessary processes,
people and technology to deliver and maintain a compliant system.

For each well
selected/audited and
“complaint ready”
vendor, the Core
System configuration
and baseline for each
cloud system release
can be qualified and
validated utilizing the
creation of a client
and release specific
Validation Plan.
You should therefore be looking to see fully documented infrastructure
qualification evidence, system administration, backup and recovery processes,
system redundancies, security policies, encryption policies, communications
processes and schedules.
All of this enable you to utilize and “leverage” the vendor’s own established
documentation when implementing for GxP functionality within your own
organization.
Remember that the compliance requirements for IT suppliers (including cloud
systems providers) is derived from several regulations and requirements:
o For Example - 21 CFR Part 820 QSR, Section 820.22
prescribes supplier quality audits be conducted
o 21 CFR Part 820 QSR, Section 820.50 prescribes evaluation,
control and monitoring of all suppliers providing purchased
material or services to a regulated facility, with evaluation of
suppliers against written specifications using defined
procedures with documented results
o GAMP 5 Appendix S5, defines specific steps to be taken to
control and monitor outsourced IT hardware and services
So to sum all that up, Cloud based FDA regulated IT systems must be
established and maintained at compliance levels equal to internally hosted
systems – and this has already been done and proven successful during
multiple audits of various cloud vendors.
Qualifying the Core
Establishing a solid foundation is key for any regulated system. With the
Cloud, that’s no different. In fact, it is actually an unseen benefit of cloud
systems usage. Since every end user sees the same initial core platform –
albeit with some minor configurations specific to their internal policies, then
the validation of that core platform can be “pre-packaged” and delivered very
expediently.
Leveraging the activities already discussed and establishing a robust SLA
backed up by Vendor Audits is the first part of that foundation. The standard
“Platform” qualification is the next step.
For each well selected/audited and “complaint ready” vendor, the Core
System configuration and baseline for each cloud system release can be
qualified and validated utilizing the creation of a client and release specific
Validation Plan.
The plan refers to the use of the Vendor’s Change Control, Administration

and Maintenance SOP’s.
System Requirements for the release are established and added to any
previous requirements version and release notes (Release notes are produced
upon successful completion of vendor’s internal testing) – to inform
customers of the impending release functional additions and modifications.
Baseline configuration is performed.
All existing and new requirements from the release notes are subjected to a
formal risk assessment – both at a high level to establish GxP and Business
Risk criticality, and at a detailed level to determine the level of control and
verification activities required
IQ and OQ protocols are established according to their inherent risk and
executed based on the core requirements.
All requirements verification controls for the release are applied and any
relevant regression tests for previous releases are performed to ensure no
adverse effect is seen from the introduction of the new functionality.
Core Platform
This diagram identifies the relationship between the efforts that a cloud
vendor undertakes to produce the Release Notes, and the activities that you as
customers will be ensuring have been established when performing vendor
audits and creating SLA’s.
The resultant release notes form part of your customer validation package.

Customer Specific
User and Functional
requirements are
established and
added to any previous
requirement versions
and the release notes.
Customer Specific System Elements
The Customer Specific Validation plan refers to the establishment of the SLA
and Vendor audits, and details what is being leveraged from the Cloud
Vendor.
It also details the plan to establish a compliant state for the customers own
specific configuration of the system to meet their needs – including the
addition of GxP applicable applications and functionality.
Customer Specific Configuration Management and Change Control processes
are established to manage changes for each release and any unscheduled
changes.
Customer Specific User and Functional requirements are established and
added to any previous requirement versions and the release notes.
As before, risk assessments are carried out on the requirements and release
notes to drive the level of testing rigor and regression testing needs.
Customer specific configuration is performed.
Verification activities –
IQ is performed to simply verify customer required configurations on top of
the standard cloud configuration (Infrastructure Qualification and
Hardware/Software installation qualifications are leveraged from the vendor).
OQ and PQ are performed utilizing established protocols and executed based
on both the customer specific requirements – and the release notes per

Third party
compliance service
vendors, like USDM,
can be engaged to
provide these
services, including
scripts for all
scheduled releases,
patches and
emergency changes
Risk is therefore
extremely low for the
end user.
inherent risk, along with any regression testing identified as potentially
necessary.
Traceability is maintained throughout and summary reports are used to release
the system.
Maintaining the System and the Supplier Relationship
• Release Management,
• Regression testing your systems – how much is too much/not enough
• The nature of the changes – i.e. no effect seen on client configuration,
mostly new functions of base updates
• Change control process
• Communications
• Enhancing your existing supplier relationships
Release Management
Maintaining Compliance is a key and critical element to using Cloud systems
for GxP functionality. Establishing and Maintaining Compliance are two
sides of the same coin.
Due to its very nature – the cloud is updated on a regularly scheduled basis –
with various upgrade cadences established depending on the vendor. These
can be once a year or 4 times per year, and with monthly service packs on top
of that – establishing a workable and efficient process is key.
For each of the releases and service packs – a set of release notes is produced
as discussed.
These notes are always issued ahead of production release, to allow customers
to analyze them, and produce any change control steps they may feel
necessary – such as PQ scripts for the released functionality itself, or
regression tests for the potentially affected areas of their own configuration.
Vendors also automatically execute risk mitigation regression tests
(numbering in the hundreds of thousands) for all scheduled releases and
patches
For patches/bug fixes – it is important to follow the procedures established
during your initial validation – perform assessments on the changes and
regression test any potentially effected functionality accordingly. Even
patches/bug fixes are released to system QA environments prior to production
release, so establishing a good communications procedure as part of your SLA
is critical to enable enough lead time to assess and test any patches.
Third party compliance service vendors, like USDM, can be engaged to
provide these services, including scripts for all scheduled releases, patches

In the majority of
cases for release
notes analysis it will
be a simple process to
identify whether a
change will affect
your configuration,
or is meant to address
a specific issue with a
function that your
business process does
not use.
and emergency changes.
Risk is therefore extremely low for the end user.
Regression Testing Your Systems – How Much Is Too Much/Not
Enough
When determining an applicable level of Regression testing, it is possible to
utilize a number of different methods, depending on your own internal system
complexity and utilization of automated testing tools.
Where these tools are in effect – running a suite of standard tests is possible
very easily and any issues relating to cloud updates arising from them are very
quickly apparent. Remember of course that your supplier should also be
performing thousands of lines of code testing as a matter of course for all
updates – so these tests – even automated, should be focused upon your own
configuration and usage, not carte blanche across the entire platform.
Where automated testing tools are not utilized, processes and tools like
Configuration Management Matrices can be utilized to identify potentially
affected areas, or in simple core cloud systems, performing a review of risk
assessments relating to the new/updated requirements may be sufficient to
attain the level of testing information required.
The Nature of the Changes – i.e. No Effect Seen On Client
Configuration, Mostly New Functions of Base Updates
Almost all changes from a Cloud vendor will fall into two categories -
1 New Functionality
2 Base Configuration patches/bug fixes
Due to the nature of how cloud systems are designed, it is extremely rare for
the periodic releases/patches pushed out by Cloud vendors to have any effect
whatsoever upon a customer’s own specific configurations. Of course, in
instances where a customer has a specific issue and is in communication with
the Vendor to address it, this is not the case, and should be analyzed
accordingly. In the majority of cases for release notes analysis it will be a
simple process to identify whether a change will affect your configuration, or
is meant to address a specific issue with a function that your business process
does not use.
New functionality changes should be analyzed to determine if they fall into
the GxP arena, or a business critical change, that your business needs to
perform some form of risk mitigation on. If they are GxP or Business critical,
new requirements should be drawn up or existing ones amended. Then they
should be subjected to the same risk analysis and testing processes the initial

Don’t be afraid of the
cloud, utilization,
platform qualification
and functional
validation are not
new concepts to the
industry. It is merely
a slightly modified
approach - necessary
to address different
challenges posed by
cloud usage.
requirement were.
For base configuration changes – i.e. patches and bug fixes relating to a
specific issue, it may be sufficient to run existing related regression tests in
your testing environments to ensure these processes - as they pertain to your
usage, are now or are still operating as you need them to. It may however be
necessary to update existing test documentation to reflect updated elements
(typically new tests are not required, merely updates to existing ones).
Change Control Process
For all changes to the Cloud System that require a response/action by the end
user, there should be a documented change control that explains and
rationalizes the response as appropriate, and is approved at a congruent level.
The release notes and communications from Cloud Vendors, as well as the
assessment and related response activities by the end user form the back bone
of the change control record and should be referenced within it.
Once change control record per release/service pack is sufficient if these
activities are in place, and reduces the need for multiple pre and post
approvals for minor elements.
Enhancing Your Existing Supplier Relationships
Having a good working relationship with your Cloud System supplier is
clearly a critical success factor in dealing with the challenges and advantages
that the cloud uncovers.
Some Cloud Vendors actively seek out key end users to participate in Beta
testing groups, as well as requirements gathering sessions to identify where
the next improvements and new functions should come from. If your
organization can become one of these key users, then you have access not
only to early functionality changes to analyze and mitigate, but also to drive
the direction of the system to enable you to become even more efficient in
your own business area.
Conclusion
As already discussed, the trend for Cloud Systems adoption in Life Sciences
is very strong, and continues to strengthen all the time. Don’t be afraid of the
cloud, utilization, platform qualification and functional validation are not new
concepts to the industry. It is merely a slightly modified approach - necessary
to address different challenges posed by cloud usage.
The bottom line is that if you ensure the Quality Management Systems and
processes of the supplier meet your and regulatory expectations – and you in
turn provide internal due diligence to maintain the compliant state once

established, then you are in a position that enables you to leverage the
activities with a documented rationale for less risk.
References
• ICH - The International Council on Harmonization of Technical
Requirements for Registration of Pharmaceuticals for Human Use
• GAMP 5® - ISPE Glossary of Pharmaceutical and Biotechnology
Terminology - Good Automated Manufacturing Practice (GAMP) A Risk-
Based Approach to Compliant GxP Computerized Systems

About the Author
David Blewitt is the Vice President of Cloud Compliance at USDM Life
Sciences. David is an accomplished Life Sciences Regulatory and IS
Compliance Professional with extensive hands-on and leadership experience
in the Pharmaceutical, Medical Device, Biotech and Blood Management
Industries, specifically in the fields of; Computer Systems Validation, Risk
Management, Issue Investigation – Root Cause Analysis and Remediation,
Quality Assurance, Software Development Lifecycle, Lean IS Compliance
Enhancement Initiatives, Business Analysis, Product Lifecycle Management
and Systems/Process analysis with Compliance Roadmap development.
He is an acknowledged expert on a wide range of regulatory predicate rules
and guidance including:
• 21 CFR Parts: 11, 203, 210, 211, 801, 803, 820 and 821.
• ICH
• GAMP 5
Recently, David’s engagements have been increasingly aligned with the
validation of Cloud Systems and Applications, including both standard and
custom solutions for Patient Case Management, Sample Management and
Tracking, Adverse Event Case Assignment Systems and MHRA
Dispositioning systems coming under 21CFR Parts 203 (PMDA) and Part 11.
About USDM Life Sciences
USDM Life Sciences is a leading global regulatory consulting firm providing
compliance, validation, qualification, quality, auditing, and information
technology services to our clients in the Medical Device, Biotechnology,
Biologics, Diagnostics and Pharmaceutical industries. USDM has more than
10 years of experience supplying our clients in the life science industry with
compliance services during each phase of their drug and product development
cycle. USDM Partners with best of breed organizations to help companies
simplify, unify and optimize their business and compliance objectives.

Selecting Implementing and Maintaining Cloud Systems for The Life Sciences Industry

Recommended

Recommended

More Related Content

What's hot

What's hot (11)

Viewers also liked

Viewers also liked (20)

Similar to Selecting Implementing and Maintaining Cloud Systems for The Life Sciences Industry

Similar to Selecting Implementing and Maintaining Cloud Systems for The Life Sciences Industry (20)

Selecting Implementing and Maintaining Cloud Systems for The Life Sciences Industry