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

E info@itelligence.nl

itelligence BV Croy 1 5653 LC Eindhoven Nederland info@itelligence.nl 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.