What Goes in a CDS IT Service Level Agreement?

Protecting your network chromatography data system (CDS) data is critical and a service level agreement (SLA) with your IT provider is vital. What should be included? Are SLAs for in-house IT and SaaS (software as a service) similar?

Imagine you have finished validating your new chromatography data system (CDS) and you are looking around the lab with pride. Suddenly, the lab door busts open and standing in the doorway is your worst nightmare—Quality Assurance! They demand to see the agreement with your IT provider. Agreement? What IT agreement? The one required by EU GMP Annex 11 clause 3.1 (1). Oops! At this point, “Beam me up, Scotty” is not an option.

To avoid this scenario, “Questions of Quality” analyzes regulatory guidance to identify and discuss what should be in an IT agreement for any service provider that is supporting your multi-user CDS. Many regulated laboratories are taking the opportunity to migrate their IT infrastructure and applications, including CDS, laboratory information management system (LIMS) and other informatics applications, from on premises to cloud computing. One reason is financial. Software as a service (SaaS) is a revenue item directly off the bottom line vs. purchase, which is a capital cost amortized over three years.

Due diligence must be carried out when selecting a service provider and the selection must be subject to supplier assessment and report (1). Different regulations consider the knowledge, professional experience, and training of IT cloud suppliers about computerized systems, data protection, privacy, and GxP legislation depending on the service provided (1–5). However, a discussion of this is outside the scope of this column. In addition, the impact of data privacy and artificial intelligence (AI) legislation on healthcare regulations is emerging, but will not be considered here.

While there has been a requirement for an IT agreement in Annex 11 since 2011, it is vague: Include clear statements of the responsibilities of the third party (1), but nothing further. However, EU GMP Chapter 7 on Outsourcing has requirements related to data ownership, review, and availability (6). In addition, several regulatory publications and updates shown in Figure 1 also impact on our discussion. As background reading, a two-part eBook is available from LCGC, entitled Is Chromatography Ready for the Cloud? (7,8).

The principles outlined here are intended for a CDS but can be applied to other internal networked or SaaS computerized systems.

A Regulatory Pick n’ Mix

There are an abundance of regulations and regulatory guidance on IT service level agreements (SLAs) that span GMP (Good Manufacturing Practice), GLP (Good Laboratory Practice), and GCP (Good Clinical Practice). We will collate all into a single comprehensive approach regardless of the GxP discipline that a laboratory could comply with. This selection ignores 21 CFR 211 and 21 CFR 11 regulations as there is little from the IT support perspective. Figure 1 depicts an overview of GxP requirements for IT agreements. GMP regulations and guidance documents to consider are:

• EU GMP Annex 11 clause 3 (1) requires assessment of service providers and agreements with them including IT; inspectors should be able to see these assessments. A draft update is due for publication at the time of writing; however, many anticipated elements are covered in other documents listed here.
• EU GMP Chapter 7 on Outsourcing and specifically clauses 7.1, 7.4, 7.5. 7.12, and 7.16 (6).
• WHO TRS 996 Annex 5 section 7 covers contracted organizations, suppliers and service providers, and mentions cloud computing several times (9).
• Medicines and Healthcare products Regulatory Agency (MHRA) data integrity guidance 2018, section 6.20 specifically covering SaaS applications (10).

FIGURE 1: Overview of GxP regulatory requirements for IT agreements.

GLP has the largest number of publications impacting IT agreements:

• Organisation for Economic Cooperation and Development (OECD) GLP No 1 (11) and 21 CFR 58 (12), specifically discussing location of a GLP archive with direct impact on SaaS providers.
• OECD No 15 discusses electronic archives (13).
• OECD No 17 covers control of computerised systems (3).
• OECD Supplement 1 to No 17 (OECD 17.1) discusses GLP and cloud computing (2).
• OECD No 25 GLP and IT security (14).

GCP has two guidance documents that have input into IT agreements:

• European Medicines Agency (EMA) Guideline on Computerised Systems and Electronic Data in Clinical Trials (4).
• Food and Drug Administration (FDA) Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (5): This final guidance is significant as if one strips out the portions of clinical trials and digital health technologies it represents the first final guidance on 21 CFR 11 since the Scope and Application guidance in 2003 (15).

Most of the above provide a generic approach to the contract requirements; however, OECD 17.1 lists the monitoring requirements of the test facilities which use cloud-based solutions (2) and MHRA ‘GXP’ Data Integrity Guidance and Definitions spotlights technical agreements or contracts with IT Suppliers and Service Providers(10).

What Do We Mean By...?

In this column, the following terms are used:

• Service Level Agreement (SLA): This term is used exclusively in OECD 17.1 (2) to mean the same as contract, agreement, or quality agreement used in regulations in Figure 1; it will cover the roles and responsibilities and specify the service and quality expectations of the regulated company and applicable regulations. There may be a separate financial agreement with a service provider.
• Service Provider: This will be used here for all types of providers of IT services. This can range from foundational IT services (internet service provider ([ISP]) to infrastructure and platform services on the cloud (IaaS or PaaS) (2), up to providing and hosting software systems for regulatory use (SaaS provider). Also called third parties (1) and suppliers of services (2). We will exclude discussion of IaaS and PaaS in this column. When we need to distinguish between the ISP and a SaaS provider, we will use these two terms.

The Cloud: Your Data on Someone Else’s Computer

When using the cloud, you must understand the risks; one is that your data are on someone else’s computer. You don’t control what they do with the platform that contains your data. All you have is an agreement between you and the service provider. Another way to look at this is described and visualized in Figure 1 in reference (7). It depicts a dwarf blue star (your laboratory) next to a black hole (your data). Once your data go past the event horizon of the black hole, you have no clue what is happening to your data. The SLA and the ability of the service provider to conform to it are critical.

SaaS: A House of Cards

Who are involved with a SaaS CDS? Figure 2 shows the entities involved with a SaaS CDS and the responsibilities of each for the correct functioning of the CDS as well as overall compliance and data integrity. Like a house of cards, all must work to ensure that the system functions and is compliant. Starting from the bottom is the ISP, followed by the SaaS provider, the company IT department, and, balanced precariously on top, is your laboratory.

FIGURE 2: Entities involved with a SaaS CDS implementation.

The ISP will not be subject to GxP regulations (2,3,16), but should conform to a quality standard such as ISO 27001 (17) or system organization and controls (SOC) (2). The SaaS supplier will need to have done due diligence to ensure that the ISP they use is fit and competent, followed by an agreement between the ISP and the SaaS provider.

Our focus is on the agreement between the SaaS provider and your organization. A CDS SaaS provider is your IT department managing the CDS application, database, and virtual infrastructure. Therefore, their staff, including sub-contractors, must have awareness of GxP requirements along with education, training, experience, and competence to do their tasks, as outlined in Figure 3.

FIGURE 3: Scope of a CDS service level agreement for internal IT and SaaS providers.

Remember that the accountability for work conducted on your behalf by the SaaS provider and the ISP remains with you.

Scope and Content of an SLA for a CDS

Using the regulations in Figure 1, we have devised Figure 3 to outline what could be included in any SLA for an IT provider. There are six sections depending on the scope of the services offered by the IT or SaaS provider. These are divided as follows:

• Roles and responsibilities;
• IT operations for ensuring quality and data integrity of records including archive. The IT provider may have their own quality management system;
• Service levels;
• Right to audit or inspect.

Two areas that are specific for a SaaS service provider:

• Ownership of SaaS records and data;
• CDS validation documentation when performed by a SaaS supplier.

A section on definition of terms and abbreviations is also required (8). Note an SLA must be reviewed periodically and updated (if necessary) as required by OECD 17.1 and EMA clinical guideline (2,4).

Section 1: Defining Roles and Responsibilities

Regardless of approach, addressing the roles, responsibilities, and accountability are key to understanding regulatory expectations and ensuring data quality and integrity. Within an SLA, the roles and responsibilities must be described between the laboratory and the service provider:

• GxP Regulated User (You): Per EU GMP Annex 11, the functional roles as system owner (Internal IT), quality and process owner (PO), or, in GLP test facility management (TFM) need to be addressed in an SLA as accountability remains in the regulated organization. The names of individuals, deputies, and their titles, roles, and contact details from both organizations must be included in the SLA (2).
• CDS Service Supplier (Them): The main duties of a SaaS supplier are shown in Section 2 of Figure 3. While defining each activity and use of any subcontractors, it is crucial to agree the communication lines and mechanisms in an SLA (2). In addition, the escalation pathway in case of issues, incidents, and problems with timeframes needs to be outlined (4). It is crucial to identify the interfaces between the separate quality management systems (QMS), and to define the order of escalation, communication, and response. Furthermore, the SaaS provider’s staff should not have access to your data (2) when performing system administration tasks.
• SaaS Supplier’s Use of Subcontractors: The SaaS supplier can use subcontractors, subject to Chapter 7.11 and WHO TRS 996 Annex 5 Section 7 (9), but they must have trained in the provider’s procedures including GxP awareness, all of which needs a section in the SLA (2,4).

Section 2: IT Operations Covered by the SLA

Figure 3 shows the scope of IT services that could be included in an SLA depending on where it is hosted.

User Account Management and Application Configuration Settings

Within cloud or on-premise environments, internal IT plays the same role for managing application configuration under change control and user account management: account allocation and privileges to the authorized individuals. In addition, an SLA could cover the number of user licenses and types (8). Therefore, written procedures with workflows, roles, and responsibilities defining who does what are essential for control and compliance.

Help Desk and Response

Any incidents with the CDS may be recorded first by your organization’s IT help desk for resolution or escalation or direct to the SaaS provider. It is a requirement to discuss the detailed workflow of the help desk in an SLA (18). This provision can be discussed within IT at two levels:

• In-house IT: For incidents related to user accounts such as forgotten passwords and account lock, the ticket needs to be raised to the in-house IT administrator (18). Other tickets will be passed to the SaaS provider.
• SaaS CDS Supplier: For the incidents related to CDS application and virtual IT infrastructure, the ticket needs to be raised to the SaaS CDS supplier helpdesk (18).

The staff of both help desks must be trained in GxP regulations including data integrity (18).

The following points should be incorporated into an SLA:

• Severity and prioritization of incidents classified by each help desk, for example, critical (CDS application has crashed), major, or minor (slow response times).
• Response times for each incident type should be defined. This is an area that creates metrics for monitoring service level performance by comparing target and actual resolution times.
• Note, that the EMA clinical guideline requires help desk tickets to be transferred to the regulated organization as part of a cloud exit strategy (4).

IT Infrastructure Qualification

Annex 11 requires that IT infrastructure should be qualified (1). As part of the supplier assessment, how is this achieved by the SaaS provider? A regulated laboratory needs to understand the creation, configuration, integration, and operation of virtual infrastructure components for the CDS as part of the supplier’s QMS (see Figure 2). Evidence of qualification may be required for audit and inspection, again a requirement for the SLA.

Cyber Security

Various GxP sources stress the potential risks associated with electronic data protection including IT cyber security when using cloud computing:

• FDA GCP Question and Answer guidance specifically focuses on the agreements with the service providers and discusses data security safeguards in section III.C and question 17 (5). The guidance reiterates the use of security safeguards such as firewalls, antivirus, anti-malware, and anti-spyware software.
• OECD 17.1 requires preventative procedures to be defined for cyber-attacks and demonstrates how to restore data and ensure the integrity of raw data once it is available again (2).
• OECD 25 expands to include intrusion detection and prevention, penetration testing, and inactivity logout that apply to both on-premise and SaaS (14).
• Critical security patches should be automatically deployed with prior notification (19) and applied promptly (14). However, there should be a degree of testing to ensure that any patch does not impact other applications such as the CrowdStrike update in 2024 (20). For a SaaS provider, it is unlikely that a lab will get notification, but the lab must understand the procedure for patching, risk assessment, and evaluation or testing before rollout. A roll-back mechanism is also essential in case of patching problems.

For external service suppliers, ISO 27001 (17), NIST Cybersecurity Framework (CSF2) (21), and national or supranational laws on cyber security could also impact an SLA.

Physical Security of Data Center and Local Hardware

OECD 17.1 offers particular attention to data protection and the secure physical location of data(2). From a physical standpoint, external security and access, pest control, temperature, fire suppression measurements, and emergency power are the key factors that need to be considered. For more details please see reference (14) and the LCGC eBook 1 (7).

Time Synchronization

An accurate time stamp is a regulatory requirement (1,22) and expectation (4,5,23) and is an imperative function for both on-premise and SaaS CDS systems. Time synchronization is the key to ensuring the authenticity of every CDS activity including the audit trail and an SLA should specify the trusted time source, time and date format, and time zone reference if used (18).

SaaS and the Validation Treadmill

With SaaS CDS application, there is a critical difference between on-premise and cloud: you are contractually obliged to take software updates regularly (for example, quarterly). The CDS SaaS supplier has a vital role to consider the following factors:

• Formal notification from the CDS SaaS provider to a laboratory about the release schedule (16). For critical errors such as bug fixes, a supplier may release a hot fix. In addition, the process of installing security patches must be understood, including the service supplier’s process for evaluating the impact before installation.
• Understandable and detailed release notes covering what has changed in the new version along with the change impacts. Well-written release notes are essential to conduct meaningful risk assessments to determine the extent of revalidation. More details can be found in the LCGC eBook on this topic (8).
• Timely access to a SaaS provider’s test environment to evaluate the new software functions before the new version comes into production (2,4).
• Test the new features in chromatographic laboratories before implementing changes and check the business process has not been impacted (2). At the heart of any CDS business process are the integration algorithms. As a minimum, integrate existing validation data to demonstrate that the peak areas and results are as expected and that no changes have occurred. Risk assessment of the new functions to determine if any will be used and if any in-house testing will be required or if the supplier software development can be leveraged (16). There could also be updates to validation documentation, laboratory SOPs, and training. For more information, please see reference 8.
• Provide user training for major upgrades if required (2,16).

For preference, SaaS suppliers should aggregate software releases into an annual upgrade. This approach is more practical where laboratories have more time to evaluate the changes instead of implementing changes every three or four months—hence the validation treadmill (8).

Resilient Data Storage

There must be enough fault-tolerant and secure disk space for data storage and e-archive. In essence, SaaS will allow expandable data storage; however, as part of the measured service with the SaaS provider, the laboratory will pay for this as part of an SLA or contract.

CDS E-Archive

Where are you going to store your chromatography data for the record retention period? You can store data within the cloud or on-premise, but you need to consider the following:

Which records are to be archived (2), for example, chromatographic data and meta data including sequence file, instrument control method, acquisition and processing methods, integration of the data and calculation of the final results, audit trail entries to comply with 21 CFR 211.194(a) (24) with further information in reference 18.

Archiving retention period, which varies throughout GxP regulations (2).

Indexing and accessibility of archived records: Records should be “locked” such that they can no longer be altered or deleted without detection (2,13). Section 8 of OECD No 15 also provides good advice for an archive within a live system (13). MHRA 6.2 also requires that dynamic data remain dynamic (10).

Checks to ensure data are still readable following system upgrades: For some systems, the software including the application and operating system may need to be preserved if you want to reprocess data.

Dude, Where’s My Data?

One key difference between on-premise IT and SaaS is data location. In SaaS, CDS data resides in the cloud, but the question remains: Do we need to know the exact location of the stored data?

Regulations and guidance documents are inconsistent (Table 1). Location is never defined adequately. This approach is not practical, and regulators must provide a definitive statement. For example, OECD 17.1 should provide explicit advice but fails miserably: Some GLP compliance monitoring authorities require details on location of a cloud archive for physical verification (2). This is as useful as a chocolate teapot.

The physical location of the data center containing the hardware and SaaS application may be determined by country legislation or company policy, otherwise location could be an area or URL (uniform resource locator) rather than a postal address.

Backup, Disaster Recovery (DR), and Business Continuity (BC)

CDS holds critical GxP data, so backup and restoration is a crucial requirement of an SLA. GMP regulations are vague requiring regular backups of all relevant data should be done (1,22,24). Annex 11 goes further: Integrity and accuracy of backup data and the ability to restore the data should be checked during validation and monitored periodically (1). How often are test restores performed by the service supplier, and how successful are they?

It is important for the lab to define:

• RPO: Recovery Point Objective or how much data can you lose? and;
• RTO: Recovery Time Objective or how quickly can you recover the system?

Without back up there is no DR (2,14,16). Business continuity is focused on alternative working arrangements such as implementing data failover to a separate location. EU clinical guideline requires contingency plans in an SLA and address expectations about potential system down-time (4).

OECD documents (2,14) consider the following requirements for an SLA. The list also interprets some of the requirements as per GAMP 5 SE (16).

• Backup intervals and type must be specified along with defined responsibilities, procedures, and documentation of these activities.This requirement needs to stay consistent with DR (16).
• Retention, e.g., a week, a month, a quarter, forever (14). Although forever implies archive, which is not the function of backup.
• Backups should be stored in a distant physical location from the application as part of a DR strategy. See also GAMP 5 SE (16)
• Locations of mirroring and expected documented (for example, backup logs and emails of backup failure) confirmations about back-up and mirroring (2). Applications and system configurations will also need to be backed up (14). This position agrees with GAMP 5 SE (16). Data need to be backed up daily; however, backup of software components and system configuration may not be conducted at the same frequency as data and records backups (16).
• For an on-premise CDS, we suggest at least one full system backup should be performed before implementing software upgrade. In contrast, a SaaS CDS will rely on the provider to ensure that no data are lost during upgrades. Both approaches will be covered in an SLA.

It is imperative that any DR plan is reviewed regularly to ensure all systems are included and updated to accommodate any changes in technology. Regular testing of a DR plan is critical to demonstrate it works.

Metrics need to be established regarding backup operations, such as percentage of successful backups, failures, and successful test restores.

Although FDA translates backup as archive in Q1 of the 2018 Data Integrity guidance (25), backup should not be used as a means of archive (3,16).

Section 3: Service Levels

Examples associated with performance monitoring metrics were provided earlier. A laboratory must define metrics with acceptance limits and review monthly reports to ensure the performance of the IT provider. If the acceptance limits are exceeded, for example, system downtime, it would trigger discussion between the organization and the service provider and could lead to a financial penalty. A SaaS CDS supplier is responsible for delivering automatically generated metric reports (8).

Section 4: Audit and Inspection

Right for the laboratory audit and inspection has to be granted by the SaaS provider or in-house IT. This requirement is included in several GxP guidances:

• The possibility of cloud service provider audits should be defined in the SLA (2).
• The need for an audit of the service provider (IT Suppliers) should be based upon risk (10).
• FDA may inspect IT service providers (5).
• EU GMP Chapter 7: 7.13 and 7.17 provide the right to audit and inspect a service supplier (6).
• The right to audit and inspect is a major factor. The number of auditors allowed and the audit duration must be defined in an SLA. Furthermore, if the service provider is unwilling to support audits or regulatory inspections, systems from such a service provider should not be used (4).

The SLA clause for audit and inspection should reflect the following points:

• Service Supplier: Providing processes and procedures for data migration, data backup, recovery, contingency plans, and retaining records (5), validation and operation of computerized systems (4). The problem is that this does not go far enough, the audit should include the QMS, staff training, and scope of services provided, for example, quality oversight, backup, change management, risk management, continual improvement, and service metrics linked with incidents and problems.

The timely response of any service provider to audit or inspect findings must be specified in the SLA (4). Another area to check is the ability of the SaaS provider to protect your data and prevent other tenants from accessing your data and vice-versa. Competent resources should also be available from the service supplier for audits and inspections.

• Chromatography Laboratories: Providing access to laboratory records and data including meta data and all audit trails. Presenting records and as requestedcopies of recordsof software updates, change control, and configuration management (2,5).

Audit includes periodic review (2); for more details of the scope refer to Annex 11 clause 11 (1).

Will Authorities Review Audit Reports of a Service Provider?

The regulators are inconsistent.

• Yes! …audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request (1). The Contract Acceptor should understand that outsourced activities … may be subject to inspection … (6).
• No! FDA will generally not review audit reports of the IT service provider’s electronic systems, products, and services (5).
• Possibly! … may request documentation from the service provider or inspect the infrastructure of hosted services and evidence of a formal assessment and/or vendor audits should be available at the test facility (3).

ISPs such as Amazon, Microsoft, and Google produce white papers discussing GxP compatibility of their services, but this is outside the scope of this column.

Section 5: Exit Strategy (Declouding)

This is a major problem area for cloud computing. The regulated company always owns the data managed by the cloud services (19), and an SLA should state this (3). If the contract is ended or voided, say by a merger with another service provider, a clear roadmap of data migration from the SaaS CDS to the laboratory must be agreed upon and included in an SLA. In case of bankruptcy of the SaaS provider or contract termination, all data and metadata (including audit trail and electronic signatures) must be returned to the chromatography laboratory. According to OECD 17.1, a SaaS provider should destroy all the data after transfer (2) and this would be part of an SLA.

Chromatographic data are dynamic and so must remain dynamic
(10,25) and PDF copies of data will not suffice.

The biggest problem with chromatographic data, and laboratory data in general, is that the application that generated the data is needed to access, view, and interpret them. This is a major problem with cloud computing: Once in the cloud, can you ever return?

Section 6: SaaS Supplier CDS Validation

A regulated chromatographic laboratory must use validated CDS regardless of whether it is in-house or SaaS. If the SaaS claims the CDS is validated to pharmaceutical industry standards, then the QMS and validation documentation must be audited as part of the supplier assessment. This includes detailed examination of specifications, coding, testing, and release documentation to ensure it is consistent with the laboratory’s own approach. The validation documents should be stored securely by the SaaS provider and must be available for laboratory audit and regulatory inspection. As noted earlier, CDS SaaS providers unwilling to allow audit and inspection of validation documents should not be used.

Summary

Always remember that accountability remains with the regulated company. An SLA is a key component for managing and monitoring interaction with your IT service provider (internal IT or SaaS CDS). In this column, we have critically reviewed GxP regulations and guidance on cloud computing to provide an interpretation for an SLA. The biggest difference with SaaS relates to continuous software upgrades and the impact on CDS validation. The inconsistencies of regulations are also discussed, with the major gap a lack of clarity on data location.

Acknowledgments

We wish to thank, in alphabetical order, Monika Andraos, Akash Arya, Markus Dathe, Jim Henderson, Misty Hill, Eberhard Kwaitkowski, and Yves Samson for their constructive review comments that have improved this column.

References

1. EudraLex, Volume 4 Good Manufacturing Practice (GMP) Guidelines, Annex 11 Computerised Systems (European Commission, 2011).
2. OECD, Advisory Document on GLP and Cloud Computing, Supplement 1 to OECD Document Number 17 on Application of GLP Principles to Computerised Systems (Organization for Economic Co-operation and Development, 2023).
3. OECD, Series on Principles of Good Laboratory Practice and Compliance Monitoring Number 17 on Good Laboratory Practice Application of GLP Principles to Computerised Systems (Organisation for Economics Co-Operation and Development, 2022).
4. EMA, Guideline on Computerised Systems and Electronic Data in Clinical Trials (European Medicines Agency, 2023).
5. US Food and Drug Administration, FDA Guidance for Industry Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (FDA, Silver Spring, MD, 2024).
6. EudraLex, Volume 4 Good Manufacturing Practice (GMP) Guidelines, Chapter 7 Outsourced Activities (European Commission, 2013).
7. McDowall, R. D. Is Chromatography Ready for the Cloud? Part 1: What is Cloud Computing and Applicable Regulations? Evolution of CDS and Impact of Cloud Computing, CDS Cloud Infrastruture, LCGC, 2021.
8. McDowall, R. D. Is Chromatography Ready for the Cloud? Part 2 CDS Data Ownership, Location and Protection, Due Diligence Assessments and Agreements, Qualification and Validation: Now and In the Future, LCGC, 2021.
9. WHO, Technical Report Series No.996 Annex 5 Guidance on Good Data and Records Management Practices (World Health Organisation, 2016).
10. MHRA, GXP Data Integrity Guidance and Definitions (Medicines and Healthcare products Regulatory Agency, 2018).
11. OECD, Series on Principles of Good Laboratory Practice and Compliance Monitoring Number 1, OECD Principles on Good Laboratory Practice (Organisation for Economic Co-operation and Development, 1998).
12. 21 CFR 58, Good Laboratory Practice for Non-Clinical Laboratory Studies (Food and Drug Administration, 1978).
13. OECD, Series on Principles of Good Laboratory Practice and Compliance Monitoring Number 15: Establishment and Control of Archives that Operate in Compliance with the Principles of GLP (Organisation for Economic Co-Operation and Development, 2007).
14. OECD, OECD No 25 Position Paper on Good Laboratory Practice and IT Security (Organisation for Economic Cooperation and Development, 2024).
15. US Food and Drug Administration, FDA Guidance for Industry, Part 11, Electronic Records; Electronic Signatures Scope and Application (FDA, Rockville, MD, 2003).
16. ISPE, Good Automated Manufacturing Practice (GAMP) Guide 5, Second Edition (International Society of Pharmaceutical Engineering, 2022).
17. ISO, ISO 27001 - 2022 Information Security Management (International Standards Organisation, 2022).
18. McDowall, R. D. Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and Regulatory Requirements second ed.; Royal Society of Chemistry, 2017.
19. ISPE, GAMP Good Practice Guide Enabling Innovation (International Society of Pharmaceutical Engineering, 2021).
20. CrowdStrike boss apologises for global IT outage, BBC website. https://www.bbc.co.uk/news/articles/c23k4yyjxp3o (accessed 2025-03-24).
21. NIST, The NIST Cybersecurity Framework (CSF) 2.0; National Institure of Standards and Technology, 2024.
22. 21 CFR Part 11, Electronic Records; Electronic Signatures Final Rule. Federal Register, 1997, 62 (54), 13430–13466.
23. US Food and Drug Administration, FDA Draft Guidance for Industry 21 CFR Part 11; Electronic Records; Electronic Signatures Time Stamps (FDA, Rockville, MD, 2002).
24. 21 CFR 211, Current Good Manufacturing Practice for Finished Pharmaceuticals, in Federal Register,1978, 45014–45089.
25. US Food and Drug Administration, FDA Guidance for Industry Data Integrity and Compliance With Drug CGMP Questions and Answers (FDA, Silver Spring, MD, 2018).

About the Authors

Bob McDowall is director at R.D. McDowall Ltd, Bromley, Kent, UK. A company involved in process redesign, the specification, implementation and validation of computerized systems, laboratory digitalization, data integrity assessment and remediation, training in these areas and auditing regulated organizations in the pharmaceutical and allied industries. He is also a member of the LCGC International Editorial Advisory Board (EAB).

Mahboubeh Lotfinia works as a qualified person and quality partner at F. Hoffmann-La Roche and is trained in GMP/GDP audit execution and CSV (computerized system validation).