Why cloud?
The ample advantages of entering the cloud have
become common knowledge in all industries,
including life sciences. Like their non-regulated
counterparts, regulated life sciences companies
are under pressure to lower their OPEX/CAPEX
without negatively impacting quality, product
efficacy, supply chain continuity, and ultimately
patient safety. Cloud computing can help to reduce
costs for owning, operating, and maintaining your
IT infrastructure and applications. From a business
process perspective, it is the answer to an increasing
demand for system availability and redundancy,
an explosive growth in data volume, and the
growing use of apps and other mobile interfaces
in the professional workspace. More specifically,
by adopting the cloud in a manufacturing context,
bulky line terminals can be replaced and every
device potentially becomes a process control
interface, allowing real-time access to quality and
production data anywhere at any time.
How much control is your cloud service
provider allowed to take?
Pharmaceutical and medical devices companies
may take more time to adopt cloud-based software
applications than the average non-regulated
company. The technology and related service
models challenge what this type of companies
has grown accustomed to in terms of internal
policies/procedures, and compliance with Good
Manufacturing Practices (GMPs) requirements
enforced by e.g. the U.S. Food and Drug
Administration (FDA) or European Medicines
Agency (EMA).
Cloud computing is offered in many deployment
models such as public cloud, community cloud,
and private cloud. In addition to the deployment
model, a cloud offering is characterized by its
service model which is usually either Infrastructure-
as-a-Service (IaaS), Platform-as-a-Service (PaaS), or
Software-as-a-Service (SaaS).
Compliant in the Cloud
Expert paper
Advantages and challenges for the life sciences industry
The ins and outs of these models have been
described in numerous publicly available blogs
and whitepapers. This article focuses specifically
on SaaS offerings in the public cloud which, from
a regulatory perspective, are most challenging
due to the extent of elements that are outsourced
compared to traditional on-premise solutions.
Full control is transferred from the regulated
company to the Cloud Service Provider (CSP).
In this setup, the supplier is responsible to not
only maintain infrastructure, virtual machines,
and so on, but also manages the application and
the database where your critical data resides. As a
regulated company, you do not have access to the
nuts and bolts or operating system functions, and
once subscribed you will have access to the SaaS
application via web browser or specific interfaces
(API) only.
What are the implications of using a
cloud-based ERP system in a regulated
environment?
We will further examine the specifics of introducing
SaaS in a regulated environment by taking an
Enterprise Resource Planning (ERP) system
as reference case. ERP systems such as SAP
S/4HANA Cloud are used by manufacturers of
pharmaceutical products and medical devices to
electronically manage procurement of regulated
goods, manage inventory, and store and maintain
critical master data including bills of material
and product recipes. In many cases, the system is
also able to manage batch release processes, QA/
QC inspection, distribution of end products, and
it is typically exploited as starting point for recall
execution.
For the sake of this article, let’s assume that your
company has already defined a strategy for cloud
computing, which is a crucial first step, and has
decided to pursue the implementation of a SaaS
ERP system deployed in a public cloud. By using
a cloud-based ERP application in a regulated
environment, production records, batch records,
and other quality records are now external to your
manufacturing site. This potentially impacts your
ability to make copies of records in human and
machine readable format, archive your data records
if required, or restore those records in case of an
error or incident. From a regulatory perspective,
this introduces data integrity risks and would have
a major impact on compliance with e.g. FDA’s 21
CFR Part 211 (cGMP for Finished Pharmaceuticals)
or 21 CFR Part 820 (Quality System Regulation for
Medical Devices).
Traditional IT
Applications
Data
Runtime
Middleware
OS
Server
Storage
Networking
You
man
age
Iaas
Applications
Data
Runtime
Middleware
OS
Server
Storage
Networking
You
man
age
Del
iver
ed a
s a
serv
ice
Saas
Applications
Data
Runtime
Middleware
OS
Server
Storage
Networking
Del
iver
ed a
s a
serv
ice
Paas
Applications
Data
Runtime
Middleware
OS
Server
Storage
Networking
You
man
age
Del
iver
ed a
s a
serv
ice
As an illustration, this would impact the ability of the regulated company to fulfill requirements
described in the following subparts:
In addition to the risk of having less control over
your critical data records, other consequences of
using a cloud-based ERP will typically include
loss of grip on the datacenter, infrastructure, and
applied services. It is highly recommended to
carefully assess the security risks introduced by
using multi-tenanted systems (as in: shared by
multiple user organizations) at both application
and database level. From a compliance perspective,
given the fundamental differences between cloud
and on-premise, you will be required to develop
and follow an alternative qualification and
validation approach in order to be e.g. Annex 11 or
Part 11 compliant.
How are regulators dealing with the cloud?
In many areas, technological advances of cloud
computing have beaten the pace of regulatory
guidance developments. While some draft guidance
mentioning the cloud has recently been created,
agencies such as the FDA still apply their existing
regulatory scheme when facing new technologies
like cloud computing.
It is nevertheless safe to say that inspectors will
focus on the following aspects when faced with
regulated companies using SaaS solutions for
managing their core business processes instead of
traditional on-premise IT systems:
n Integrity of data is assured
n Risks clearly identified & mitigated
n Formal agreements between you and your CSP
n CSP quality systems
n Applicable SOPs, validation process, change
control, training
n Security
n Data backup and recovery
n Supplier audit(s)
This list gives you a very high level idea of what
will potentially be looked at during audits, but
does not provide you with the guidance that
most organizations are currently longing for. The
fact that most cloud offerings are delivered as a
service rather than a product seems to complicate
the analysis of how the FDA wants to regulate
cloud solutions in the near future. This leaves
many regulated companies in the dark in terms
of a detailed approach for the qualification
and validation of cloud solutions, and SaaS
applications especially. The next sections aim to
provide answers to questions typically raised by
our customer base.
n §211.100: Written procedures; deviations
n §211.180: General requirements
n §211.182: Equipment cleaning and use log
n §211.184: Component, drug product container,
closure, and labeling records
n §211.186: Master production and control records
n §211.188: Batch production and control records
n §211.192: Production record review
n §211.194: Laboratory records
n §211.196: Distribution records
n §211.198: Complaint files
n §820.90: Nonconforming product
n §820.140: Handling
n §820.150: Storage
n §820:160: Distribution
n §820:170: Installation
n §820.180: General requirements
n §820:181: Device master record
n §820:184: Device history record
n §820:186: Quality system record
n §820:198: Complaint files
n §820:200: Servicing
Who controls and qualifies infrastructure
and core configuration of application?
Your supplier obviously plays a key role in a
scenario where you shift from on-premise to
cloud. In practice however, this third party that
develops, hosts, and maintains your ERP system
may prefer not to work within the confines of
policies/procedures developed by your company
and regulatory agencies. They are not necessarily
keen on bearing the costs of implementing a
formal Quality Management System (QMS) that
will tick boxes for all of your quality requirements,
especially those who have many other customers
from a range of industries that are less-regulated or
not subject to regulation at all. If that is an audit
conclusion, it does not mean that you cannot do
business with this CSP. Yet it is crucial to identify
and assess the risks inherent to such audit findings,
that the risk acceptance has been justified and
documented, and that any possible mitigations
have been described and put in place.
Important to realize but often overlooked, is that
CSPs are not subject to inspections performed by
regulatory agencies. They do not have to be GxP
compliant, as this will always be the responsibility
of the regulated company. You are expected to
audit your CSP, and qualify them as a suitable
supplier.
What are your supplier’s ways to stand
out from the crowd?
The ability of CSPs to comply with the expectations
and standards from the average life sciences
company greatly varies. It is your decision whether
or not to engage with a certain CSP, and this
decision should be made risk-based as the EMA,
FDA or other agencies do not dictate what is right
or wrong in this sense.
As a guideline you should at least expect
that your supplier:
n Is able to provide documents and schematics
that are comprehendible for non-experts.
n Manages changes in an acceptable manner
n Has clear contracts and allocation of roles and
responsibilities.
n Has been audited by other regulated companies.
n Performs and documents audits on its suppliers.
n Creates and maintains suitable test documenta-
tion for its environments to prove security and
data integrity.
But in an ideal world, your supplier:
n Has extensive experience with compliance needs
of the life sciences industry, and uses tools to
ensure that compliance is achieved efficiently.
n Can provide qualification documentation of
appropriate quality that allows leveraging, using
a risk-based approach to reduce your validation
effort.
n Is able to explain complex technology environ-
ments to your team so they can understand the
operation and design elements.
n Has been audited by companies similar to yours
in terms of intended use and compliance needs.
n Operates a robust and suitable QMS that mat-
ches life sciences industry expectations.
n Employs adequate Subject Matter Experts
(SMEs) that cover IT from a technical and com-
pliance perspective.
Cloud service providers do not have to be GxP compliant, as this will always be the responsibility of the regulated company.
Regardless of your CSP’s position on the scale from
bare minimum to best-in-class, they are in any
case expected to have an established information
security management system. It is recommended
to ensure that your supplier is ISO 27001 / 27002
certified, to verify that the supplier manages
activities in a way commensurate with GAMP® 5
guidelines, and to demonstrate that the supplier
is capable of ensuring the level of confidentiality
and availability that is expected by life sciences
companies. Speaking of GAMP®, this guidance has
the advantage that it is designed to be compatible
with other computer and software models such as
ITIL and COBIT®, which will be familiar to most
CSPs, including those that are not used to cater to
the standards of the average life sciences company.
From a computerized system validation point-of-
view, you should leverage as much of your CSP’s
expertise, testing, and documentation as possible.
Effective documentation management, for instance,
is fundamental to demonstrate compliance, and
finding a CSP that is able to manage this to your
standards can be quite a journey.
If it’s not documented, it doesn’t exist.
What aspects need to be formalized?
There are many elements to take into account
when engaging with a CSP that provides a SaaS
ERP system. However, one that is definitely worth
highlighting is the establishment of a formal
agreement. This will typically include an overall
contract, a Quality Agreement, and a Service Level
Agreement (SLA). Such agreements are of key
importance from a business perspective, and have
the objective to define the services that the CSP
will provide to you, as well as the responsibilities
that you need to fulfill in using those services.
Formal agreements are also a requirement set forth
in Annex 11 3.1, which is the EMA supplementary
guideline on the use of computerized systems as
part of GMP regulated activities.
Topics to formally agree on with your CSP
would concern:
n Backup and restore.
n Patch management.
n System security.
n Availability and capacity management.
n Incident management.
n Configuration and change management.
n Regulatory compliance.
Be very specific and complete in terms of content,
because what is not defined in writing has to be
re-negotiated later (and likely paid extra). For
example, by using a SaaS ERP you will become
highly dependent on the supplier for providing
input during possible audits at your company.
Therefore, ensure that you include agreements
on ongoing audit cooperation to be able to
answer questions on topics such as configuration
management, qualification of infrastructure,
disaster recovery, and training records.
Another example of what’s seen in daily business
is that things tend to get more complex if your
SaaS provider uses separate IaaS providers for
ISPE’s GAMP® 5 provides a pragmatic and practical
approach to achieve compliant computerized
systems, fit for intended use in an efficient manner.
It addresses the entire lifecycle of an automated
system and its applicability to a wide range of
information systems, lab equipment, integrated
manufacturing systems, and IT infrastructures. It’s
regarded as the definitive industry guidance and is
referenced by regulators worldwide, including the
FDA and EMA.
Citation from EudraLex Volume 4 Good
Manufacturing Practice (GMP) Annex 11 subpart
3.1 on Suppliers and Service Providers:
“When third parties (e.g. suppliers, service
providers) are used e.g. to provide, install,
configure, integrate, validate, maintain (e.g. via
remote access), modify or retain a computerized
system or related service or for data processing,
formal agreements must exist between the
manufacturer and any third parties, and these
agreements should include clear statements of the
responsibilities of the third party. IT-departments
should be considered analogous.”
infrastructure and hosting. In that case, focus on
examining if and how your SaaS provider has
audited and qualified this third party. If it’s an
unacceptable risk that your company’s critical data
resides with your supplier’s supplier, be sure to
extend your contract and/or Quality Agreement
with statements that formally disallow your CSP to
deploy such models.
How to validate the ERP system?
So, you have done your part in auditing and
evaluating your CSP, there are formal agreements
in place, and the CSP has provided evidence
that their infrastructure and software has been
properly qualified. Depending on the nature and
configurability of the system, qualification by your
CSP can even include performing a configuration
verification to ensure that the configured ERP
system meets your specific requirements, and
functional verification to challenge the system both
positively and negatively. The latter activity would
be typically executed as a joint effort by you and
your supplier.
Once such qualification phases are done, it’s time
to validate. Whether on-premise or cloud, GAMP®
5 is still the preferred framework to approach
validation of your applications and can be used to
do as much or as little as you deem appropriate.
From a GAMP® 5 perspective, the CSP has covered
the bottom part of the so-called V model.
It is your turn to tackle the top part of the V model
by continuing the process on a user requirements
level. Validation needs on this level are specific
to your intended use of the ERP system and the
uniqueness of your configuration. This activity
cannot be performed by your CSP, because the
system needs to be validated in the context of how
it supports your company’s operations, practices,
and requirements. Obviously, this implies that
at least a user requirements specification or
similar document is in place, and that you have
determined risk-based what your validation focal
points should be. It is important to take a business
process-oriented approach in case of cloud ERP
systems, and not to be tempted to merely view
this validation phase as a technical exercise. The
end-result should not just be an auditable set of
documents, but hopefully an ERP solution that
does what it is meant to do.
Com
pany
Clo
ud S
ervi
ce P
rovi
der
Acceptance Testing
System Testing
Integration Testing
User Requirements
SystemOperation
System Specification
System Installation
TechnicalDesign
SystemIntegration
ProgramsDevelopment
UnitTesting
The system needs to be validated in the context of how it supports your company.
Your cloud ERP system goes live,
now what?
If you adhere to GAMP® 5 for the validation
of your cloud ERP solution, the system will be
released for entering the operational phase based
on successful validation of a specific version of
that system. Once live in an on-premise situation,
at some point in time the decision will have to be
made on whether or not to upgrade your system to
newer versions whenever these become available.
An important feature of SaaS ERP however, is that
the supplier frequently pushes new versions to
improve performance and user experience. Such
upgrades are mandatory and apply for all of their
customers, usually without a possibility to opt-
out. This of course is an advantage from many
perspectives, but introduces significant challenges
for regulated users as each new version requires
validation (or: revalidation).
The rigor of change management, impact
assessment, and verification testing adds to the
work burden and short-term costs for your CSP.
This aspect is one that not all providers will
be used to, and is therefore crucial to carefully
examine in auditing stages of your project.
Imagine that your CSP performs a change to their
infrastructure, platform or the ERP application
that you are using, and does not inform you
accordingly. This would compromise the validated
state of your system directly.
Following the approach propagated by GAMP® 5,
you are encouraged to execute the (re)validation of
hotfixes or version upgrades following a risk-based
process. It should be a relatively short process that
simply focuses on new functionality and checks
any potential impact on functionality from the
previous version. If your ERP system is offered
in a three-system landscape (e.g. development/
test/production), it is common practice that
CSPs introduce the new version or hotfix in the
development and/or testing environment first,
prior to releasing it in the production environment.
This allows you to prepare for the upcoming
change, assess and mitigate the associated risks,
and execute (re)validation activities accordingly.
Be aware of the timeframe maintained by your
CSP between releasing the upgrade in the test
environment and production environment. If
the upgrade is carried out in your production
environment one week after the testing
environment, it is unlikely that your company
will be able to manage this change from a quality
and compliance perspective. Depending on your
internal procedures and the criticality of the
system, even a timeframe of one month would in
most cases be a challenge.
In addition to the timeframe between upgrade of
the different environments, the frequency at which
upgrades are introduced is also an important factor
to take into account. Will your CSP push upgrades
monthly, quarterly, or yearly? Will you be able to
cope with this frequency in combination with the
timeframe mentioned earlier?
Wrap-up
As we have seen, entering the cloud for ERP
purposes brings ample advantages, including
internal IT cost savings, but keep in mind that
time and resources will be required for ongoing
quality and compliance oversight. You will have
to continuously monitor your CSP and the system
they provide, including periodic audits and (re)
validation of your system when upgrades are
pushed. You can outsource IT, but you cannot
outsource your regulatory responsibility. The cost
of this should be based on what is required to
mitigate the risks associated with the cloud service
model, the risk of the clouded GxP-critical data
or ERP application itself, and the risks associated
with the CSP. Obviously, these costs should be
Entering the cloud for ERP purposes brings ample advantages.
estimated before contracts are in place and should
be added to the service cost quoted by the CSP to
provide the true cost of switching from on-premise
ERP to cloud ERP.
The purpose of this article has been to try and
answer some of the frequent questions I’m faced
with from our regulated customers on a day-to-day
basis. Yes, ERP in the cloud has its advantages, but
also brings many challenges. However, based on
the topics discussed above it has hopefully become
clear that the associated risks can be assessed
and in most cases mitigated. For those regulated
companies that have not seriously investigated the
potential of ERP systems offered as a cloud service,
now is the time to dive in, develop a strategy that
fits your compliance needs, and take advantage
of one of the most significant improvements in
the ERP market for decades. Feel free to contact us
for discussing any topics related to the challenges
of adopting and validating cloud applications in
general, or SaaS ERP systems such as SAP S/4HANA
Cloud in particular.
About itelligence
itelligence is a leading service provider and
SAP vertical expertise partner in life sciences.
We operate on the intersection of business, IT
and legislation in SAP centric environments.
We believe that our branch focus helps us to
continuously build up knowledge and combine
skills that are unique and of great value to our
customers.
Do you want to know more
about this service offering?
Please contact us on:
itelligence BV
T +31 40-296 86 00
itelligence BV Croy 1 5653 LC Eindhoven Nederland [email protected] www.itelligencegroup.com 07/2018
Steven de BruijnLife Sciences Consultant, itelligence Benelux Steven de Bruijn is a Life Sciences Consultant for itelligence in The Netherlands. He is able to bridge the gap between quality assurance and information technology, using his regulatory knowledge to support clients reaching their goals in a compliant manner. Steven specializes in validation & IT compliance, and is experienced in applying GAMP 5® practices to environments that are required to comply with e.g. 21 CFR Part 11, Annex 11, or ISO 13485:2016. In addition, his work focuses on software solutions, including SAP S/4HANA, SAP ECC, learning management systems and a range of applications commonly used in the regulated sector. He has worked with domestic and international clients in the areas of blood and plasma, biopharma- ceuticals, animal health, over-the-counter drugs, and medical devices.