IT Service Providers: Service Level Agreement

Excerpt from the GMP Compliance Adviser, Chapter 9.G.3. – 9.G.3.3.

8 min. reading time | by Markus Roemer, Siegfried Schmitt, PhD
Published in LOGFILE 33/2021

The written contract on the outsourced activities can take the form of an internal service agreement or an external service agreement. In both cases, it is used to describe.

• Clear tasks,
• Clear responsibilities and
• Clear communication flows.

Services must be precisely defined and agreed. The contract between the contract giver and the contract acceptor must clearly define the tasks of both sides and regulate communication between these two parties. The service level agreement thus minimises misunderstandings and increases work efficiency. Particularly in cases where both parties bear responsibility for a certain aspect of the contract, a clear delimitation must be made. This is also referred to as a delimitation of responsibility contract.

Example:

"The contract giver is responsible for defining the backup routine. The contract acceptor is responsible for performing the backup as specified."

Here, responsibilities are clearly defined instead of simply saying that both parties are responsible for the backup. Since the service agreement or contract is required by legislation, it is also inspectable by the authorities. For this very reason, it is recommended to separate the commercial part from the technical part. It makes sense for the client to provide specifications (also called reference points or user requirements specifications). The importance of making these specifications as detailed and verifiable as possible should not be underestimated.

Despite all precautions, something can go wrong. Therefore, a business continuity plan is necessary whether or not outsourcing is involved.

Obligations of the contract giver

The tasks of the contract giver include responsibility for assessing the competence of the contract acceptor, which should be established in an assessment or audit. The contract giver must ensure that all work is performed in a (GMP) compliant manner. This is often easier said than done. Software developers, for example, have their own quality standards, often simply software coding standards, but far removed from GMP. Whether and when this is acceptable depends entirely on the specific circumstances and must be evaluated through a risk assessment. Documentation, change management, training, and all other regulatory aspects must be reviewed. The contract giver must supply all the necessary information to ensure that tasks can be executed properly by the contract acceptor.

Particular attention should be paid to the availability of data that is outsourced or managed by a service provider. The regulations clearly state that the client is responsible for data integrity. This includes availability and access to the data. Since service provider data centers are often spread around the globe, local legal restrictions, such as the EU-US Agreement on Personal Data Protection (www.privacyshield.gov), must be taken into account.

Obligations of the contract acceptor

The contract acceptor should possess suitable premises and the necessary equipment. In addition, he/she must have sufficient technical expertise, experience and competent personnel. He/she may not subcontract any work contractually assigned to them to a third party without the prior review and approval of the contract giver. The contract acceptor must also permit audits or inspections by the contract giver and the authorities.

There are often limits to this aspect as well. For example, companies that only marginally supply the regulated life science sector will resist such regulation. Again, the risk must be assessed through a documented analysis. In other words, it is unlikely that a government agency will subject a company like SAP or Oracle to a GMP inspection, even though their software products are often used for GMP critical applications.

The competencies of the client and contractor are not always balanced. If the Capability Maturity Model Integration is applied to outsourcing, the picture is as in Figure 9.G-1.

It is desirable if the client and contractor have similar competencies and thus an understanding of the tasks. This is represented by the diagonal line. As an extreme example, let us take a young pharmaceutical company that is not familiar with computer validation. They are therefore looking for an outside company that can do it. Since they are inexperienced, they simply choose the cheapest offer. If, by chance, this is a company with inexperienced employees, then the skills of the two parties balance each other out, but there is no guarantee that the product will meet expectations, and the customer cannot judge whether the result is good or bad. If, on the other hand, the company chooses a very competent supplier by chance, then the constellation arises that the client becomes dependent on the supplier, i.e. the supplier now dictates what and how much is to be done. Of course, there is also the other extreme, where the customer has much more competence than the supplier. Then it is often the case that the customer trains the supplier (at his own expense).

Conclusion: high competence on both sides is the best solution!

Figure 9.G-1 Competence correlation

Contents of a service level agreement

The following is a typical example of a table of contents for a service level agreement:

• Service description
• Validity
• Provision of services
• Availability
• Reaction time
• Response time
• Technical details/file formats
• Scope of the service
• Obligations of the contract giver
• Training
• Documentation requirements
• Change management
• Data backup
• Business continuity planning
• Inspection and audit
• Costs and method of payment (preferably as a separate part)
• Service acceptance, measurands and remediation of deficiencies

Specific requirements of the pharmaceutical industry

Since the pharmaceutical industry is subject to regulations and regular inspections by the authorities, the following points in particular should be taken into account:

• Training documentation: Date, duration, contents of training, and evaluation of whether participants have understood the contents (EU-GMP Guidelines Part I Basic Requirements for Medicinal Products, chapter 2.10 ff.)
• Documentation requirements: No pencil used, changes and corrections made in GMP compliant style (cross out the old version legibly and add the new content with initials, date and reason).
• Change management: No unauthorised changes
• Backup and Business Continuity Planning: In the event of a product recall, all relevant information must be accessible within the minimum possible time. Some software applications can be so critical that the company itself would like to have access to the source code in certain cases – for example, if the provider of the software discontinues its services. Source code management is done, for example, through an escrow agreement (the source code is deposited with a trusted party).

Do you have any questions or suggestions? Please contact us at: redaktion@gmp-verlag.de