Dracula Rises From The Grave: CSA Lives On?

Let us explain the title: Dracula was a vampire (CSA) that rose from his grave to suck blood from his victims (CSV). In the past, CSA proponents have stated that CSV is dead, and long live CSA. The final CSA guidance is for production and quality management software used by medical device manufacturers (1); Following this update QMS all referenced to ISO 13485:2016 (e.g.4.1.6, 7.5.6, and 7.6) to harmonize FDA medical device regulations with the globally accepted standards. One of us has critically reviewed CSA from the perspective of application in Pharma (2-4), and Okutan has published critiques of CSA for medical devices (5-9).

We compare the CSA and CSV for a spectrometer system used in a GxP regulated laboratory, and pose the question, “Can CSA be applied to Pharma, or should Dracula be back in his coffin in the medical device castle?”

Sucking Blood from CSV

The initial flaw with the CSA initiative is that the U.S. Food and Drug Administration (FDA) reacted to manufacturers who moaned about overburdensome CSV and requested more agile, flexible and iterative approaches. However, the manufacturers didn’t read and understand sections 2.3 and 6 of the General Principles of Software Validation (GPSV) guidance (10), which stated a LEAST BURDENSOME APPROACH and described reduced validation approaches for production and quality system software; see (4) for a discussion of the latter.

Many proponents of CSA present myths about CSV to justify why the former is a better approach. These are presented in the left-hand column of Table 1, along with the response in the right-hand column that refutes each one.

This brings us to the one point that most people overlook about CSV; if performed correctly, it provides business benefits.

Table 1. CSV Myths Promulgated by Proponents of CSA and the Responses

CSV Provides Business Benefit

What? Are you mad? You’re saying that CSV provides substantial business benefits? Let’s see:

1. Investment Protection: Selecting the right system for the right job (for example, Level 1 of the Data Integrity Model [15,16]) and making sure it does what it should.
2. Process/System Mapping and Redesign: Elimination of paper printouts and spreadsheets for simpler working and efficient data management. The application should be configured to enforce electronic business processes and meet regulatory requirements (17).
3. Laboratory digitalization: Faster electronic workflows with electronic signatures allows faster product release, positively impacting company cashflow and better insights on information.
4. Increased process understanding: A well-understood process/system is robust and will require fewer changes over time (17).

CSV is simply a flexible approach for implementation of software, with or without an instrument, to automate a process electronically. The process savings should pay for the validation and continue to provide benefits into the future.

There is nothing in the CSA guidance about business benefit.

Dracula Rises: The Final Guidance?

Rising from the grave, the CSA Guidance is focused on medical device software used in production of medical devices or supporting the quality management system. The structure is shown in Figure 1. CSA replaces GPSV Section 6, expanding from 3 pages of succinct advice to 41 pages to wade through. Note that CSV and CSA co-exist. There is a new example in the guidance for Software as a Service (SaaS), shown in blue in Figure 1.

CSA is a six-step risk-based framework aiming to identify foreseeable software failures with focusing on the factors such as proper system configuration and management, security of the system, data integrity, data storage, data transfer, or operation error (18). In line with GPSV section 2.3, the guidance fosters a least-burdensome approach. Section 5A recommends performing only necessary validation activities and encourages using electronic records and tools to document work. The guidance introduces CSA:

…as a risk-based approach to establish confidence in the automation used for production or quality management systems and identifies where additional rigor may be appropriate (1).

This is not earth-shattering, as risk-based validation has been around since GAMP 5 first edition in 2008 (14) and in Annex 11, Clause 1 since 2011 (19), and has been advocated by FDA since 2002 with its Pharmaceutical GMPs for the 21st Century initiative (20). CSA also advocates using automation for software development. Moreover, use of software tools is nothing new as automated testing tools have been in Annex 11 Clause 4.7 since 2011 (19), and validation management tools are widely available.

Figure 1. Structure of the CSA Final Guidance and Integration into the GPSV Guidance

CSA is intended for the medical device industry, not Pharma. However, this has not stopped proponents from loudly trumpeting its applicability for Pharma. Let us see if this is true.

The CSA framework consists of six components (1), and is shown in Figure 2:

1. Identifying the Intended Use
2. Determining the Risk-Based Approach
3. Production or Quality Management System Software Changes (not discussed here)
4. Determining the Appropriate Assurance Activities
5. Additional Considerations for Assurance Activities
6. Establishing the Appropriate Record

Do you have your garlic handy?

Figure 2. CSA Framework

Comparison of CSV and CSA for a Spectrometer Validation

We will evaluate each step as we compare the CSA and CSV approaches for the validation of a spectrometer system in a regulated Pharma laboratory.

Computerized System, or Just Software?

Our spectrometer consists of the analytical instrument connected to a workstation where the operating system, hardware, utilities, and application software are installed.The application software controls the spectrometer and acquires data to a secure and resilient networked location.The system is operated by trained users following standard operating procedures (SOPs) utilizing a role-based access.The computerized system automates the analytical process, and its data life cycle as shown in Figure 3.

GPSV 6.2 (10) recommends documented requirements for hardware, software, utilities but the CSA guidance only refers to software not a computerized system (1). Although the guidance mentions computerized system in step 1, all examples relate to software alone.

This is a problem as regulations and guidance documents use the term computerized system (11,19,21). This encompasses the following elements in Figure 3:

• Computer System
  • Qualified workstation (PC)
  • Qualified software: operating system, application, (database)
  • Qualified and integrated IT infrastructure, hardware, network, utilities, cybersecurity, network tools, middleware
• Controlled Function
  • Analytical instrument and accessories (e.g. probe) controlled by the application
  • Procedures for all roles
  • Trained users

The whole computerized system is validated for intended use based on a formal user requirements specification (URS).

Figure 3. Scope of a Computerized System and CSA

CSA Problem 1: CSA only focuses on software and does not consider all components of a computerized system, such as instrument control, infrastructure qualification (19).

CSA Problem 2: The background section of the guidance states:

…“software quality assurance” focus on preventing the introduction of defects into the software development process … (1).

Laboratories do not write spectrometer software; this is the role of the instrument supplier. CSA Section 5A advocates assessment of a supplier’s software development practices (1), but this has already been discussed in GAMP 5 (11,14). It is important to separate the software development lifecycle (supplier responsibility) from the validation lifecycle (laboratory responsibility). This is very difficult with the CSA guidance.

Comparison of CSV and CSA Processes

Figure 4 shows the comparison of CSV and CSA processes for the validation of a spectrometer and the application software. At first glance it appears that there is much more to do with CSV; which poses the question: Are the CSA promoters right? Let’s analyze the two approaches in detail.

Given the vague descriptions in the guidance, it is difficult to show equivalence between the two frameworks. For example, is a URS the same as intended use? Who knows?

Figure 4. Generic CSV and CSA Process Flows

System Risk Assessment

How do you know if you must validate the system? Conduct a system risk assessment (SRA)!

A CSV SRA would be conducted at the start of the process to determine the extent of any validation efforts. Under CSV this uses a simple intended use statement that would allow a classification of the item against the USP <1058> groups and GAMP software categories (22-25).

A CSA SRA is conducted after the intended use is documented. CSA has a simple binary risk assessment determining two areas as high process or not high process risks based on software direct or support intended use (1). This is aligned with ICH Q9, 5.1 that notes formality can be considered a continuum (or spectrum), ranging from low to high based on the factors like uncertainty, importance and complexity (26).

Spectrometer System: The intended use is defined as identity testing of raw materials and quantitative analysis of active ingredients, both of which are which GMP relevant and would trigger validation of the system. A detailed risk assessment for analytical systems and instruments is available in the European Compliance Academy (ECA) guide (25).

Define Intended Use but Where is a URS?

A user requirements specification (URS) is critical in the GPSV:

6.2…A very important key to software validation is a documented user requirements specification (URS) that defines:

• the “intended use” of the software or automated equipment; … (10).

CSA Problem 3: Where is the URS? CSA does not appear to require a URS, despite intended use being repeated 47 times in Section A. The only mention of requirements is in the context of regulatory requirements. What is the content of a document to define intended use of software? The guidance also appears to contradict Section 3.1.1 of GPSV that discusses requirements and specifications.

CSA Problem 4: Instead of requirements, CSA states that intended use should be defined by features, functions and operations (FFO). However, these are poorly defined, and the Appendix A examples provide no practical detail of how to differentiate and document FFO. Examples provided in step 2 appear to use feature, function terms interchangeably (1).

Table 2 shows the CSA definitions of FFO in comparison to the IEEE software engineering standard 610 (glossary). Does an operation automate part or all a business process? The guidance offers no explanation or practical interpretation.

Table 2. Comparison of Feature, Function and Operation from the CSA Guidance and IEEE Standard 610

CSA Problem 5: At stage 1, the FFO appears to be unknown and section A does not define FFO deliverables in a practical manner. Can you imagine specific FFO descriptions for a spectrometer system? The FFO classification is not well-understood or common on a practical level. Apart from the terminology, FFO first needs to be translated into an intended use within an SRA and subsequently, decomposed into detailed requirements in a URS.

Confused? Write user requirements, you know it makes sense. The next Focus on Quality column will discuss writing testable and verifiable requirements. In Figure 4, the CSV process shows a generic URS is written to select a system which is then updated after prototyping.

Spectrometer System:The URS would encompass numbered requirements for traceability throughout the lifecycle:

• Defining work performed by the system from data acquisition, processing, reporting and storage
• Instrument operating parameters such as wavelength range
• Electronic Record and Electronic Signature workflows
• Compliance requirements and application configuration
• Supplier assessment and services
• IT infrastructure and support e.g. platform, account management, backup, etc. (28)

Control: Validation Plan and Summary Report

As shown in Figure 4, there does not appear to be any overarching control of a CSA project with a validation plan and a report of the work.For those planning on implementing a CSA approach in Pharma, there are specific regulatory expectations for both a validation plan and a validation summary report (VSR):

1. EU GMP Annex 15 Clause 1.6: For large and complex projects, planning takes on added importance and separate validation plans may enhance clarity (29).
2. PIC/S PI-011 Section 24 Table 3 Item 1: Is there a written validation plan (21)? Note that there is a footnote under management that also mentions an SOP for control.
3. PIC/S PI-011 Clause 23.10: Inspectors should review the firm's Validation Summary Report for the selected system … (21).
4. EU GMP Annex 15 Clause 2.10: A formal release … as part of the validation report approval or as a separate summary document (29).
5. Draft EU GMP Annex 11 Section 9.8: … in the validation report … (30).

CSA Problem 6: There does not appear to be any control of a CSA project or operational release of a software. The test plan in CSA table 1 is not equivalent to a validation plan.

Spectrometer System: A validation plan defines the intent of the validation activities to be performed and expected documented evidence based on the complexity of the software and process automated. A VSR documents what was actually done, including discussion of any problems and releases the system for operational use.

The Sun’s out, but No Shadow?

CSA states that the binary risk-based approach:

… focuses on those factors that may impact or prevent the software from performing as intended, such as proper system configuration and management, security of the system, data integrity, data storage, data transfer, or operation error (1).

The problem is that of the five examples for high process risk, there are none that are directly relevant to a typical regulated laboratory spectroscopic analysis. The closest is:

• Measure, inspect, analyze, and/or determine acceptability of product or process with limited or no additional human awareness or review (1).

Human awareness or review can be matched to the analyst performing a test or a reviewer in GMP regulations: 21 CFR 211.194(a)(7) and (8) (31) and Chapter 6.17(f and g) (32).

There are three enterprise resource planning (ERP) examples, and one for a graphical user interface, that are of zero use trying to interpret this section for a regulated spectroscopy laboratory. The ERP examples are flawed (33).

A welcome addition to Step 1 of the February 2026 version is adding software revalidation when updating software. The CSA guidance also references subclauses 4.1.6, 7.5.6, and 7.6 of ISO 13485 in that the specific approach and activities associated with software validation and revalidation are required to be proportionate to the risk associated with the use of the software, including the effect on the ability of the product to conform to specifications.

CSA Problem 7: Determining the risk-based approach for a spectrometer system is virtually impossible as there is zero guidance for software controlling an analytical instrument or automated manufacturing software for medical devices.

CSA Problem 8: Another issue is about taking an isolated approach toward defining an intended use (step 1) and risk analysis (step 2). How extensive must the intended use definition be before the risk assessment is conducted? Without knowing the complete intended use, it is impossible to establish confidence in the automation (1).

Spectrometer System: SRA is the first CSV step to determine the extent of validation approach. A detailed description of the risk-based lifecycle approach would be documented in a validation plan (See Figure 4). See the ECA guide for more details about a laboratory SRA (25).

Figure 5. Scope of CSA Assurance Activities

Get Your Teeth into Testing

We come now to Section 4, which is one of the most contentious areas in the CSA guidance. “Assurance activities at user level” is a snazzy name for testing. Shown in Figure 5 are scripted and unscripted testing. Don’t get your hopes up, unscripted testing does not mean undocumented testing.

Scripted Testing: There is a major formatting error in the February guidance as scripted testing is shown as a sub-set of unscripted testing. Oops! This is the usual CSV approach to user acceptance testing (UAT) or performance qualification (PQ) of a spectroscopic system. Traceability is essential to ensure that user requirements are tested extensively or justified for reduced or no testing. Where intended use requirements are tested, such as Example 4 (Table 5) on SaaS Product Life Cycle Management System (PLM), it is identified as UAT (1), but is actually unscripted exploratory testing. Unscripted testing is not an acceptable approach within Pharma, and we will discuss this later.

Many laboratories write excruciatingly detailed instructions for untrained users. To avoid this:

• Trained users are critical for testing, and management must allow sufficient time for this; otherwise, you end up writing detailed test instructions, which take time to write and are error-prone when executed.
• Provide sufficient detail for a trained user to execute (remember that a trained analyst can interpret an instruction to prepare 1L 0.1M sodium acetate solution and generate the appropriate records to show compliance).
• Use the system itself to collect the evidence of testing; generate e-records and entries in the audit trail and avoid screen shots or printouts.
• Don’t print for the sake of printing.
• If comparing before and after actions, use PDF output from the computerized system, and then use the compare function of a PDF application to highlight any text differences.
• Testing must be traceable to specific user requirements.

FDA recommends that you apply a risk-based approach to testing, but this is already found in Annex 11 (19) and GAMP 5 first and second editions (11,14). However, Annex 11 is applicable in European and PIC/S countries and only to US companies exporting to EU.

CSA Problem 9: CSA Table 1 divides scripted testing into limited and robust categories (1); however, there is inadequate definition of these subcategories.

Unscripted testing: Defined as dynamic testing in which the tester’s actions are not prescribed by written instructions in a test case. (1) The major problem is that this is based on ISO 29119 on software engineering (34) (such as writing and testing code) and is being shoehorned into testing regulated applications and systems, despite these practices not being popular or well-defined for developers.

Unscripted testing has variations:

• Scenario or Ad-hoc Testing: A specification-based test case design technique based on exercising sequences of interactions between the test item and other systems. See GPSV Section 5.2.5 for black box and white box testing at the software module level (10).
• Experience-based testing: Class of test case design techniques based on using the experience of testers to generate test cases.
• Error guessing: Test cases are based on the tester’s knowledge of past failures or general knowledge of failure modes.
• Exploratory testing: Spontaneous design and execution of tests based on the tester’s existing relevant knowledge, etc.

Unscripted testing does not mean “undocumented,” but rather “very thinly documented,” as listed in Table 1 of the CSA guidance. Test repeatability is crucial here and unscripted testing does not allow this. As described in ISO 13485 subclauses 4.1.6, 7.5.6, and 7.6 of ISO 13485, the specific approach and activities associated with software validation and revalidation are required to be proportionate to the risk associated with the use of the software, including the effect on the ability of the product to conform to specifications.

From our perspective as trained auditors, how can we be assured that software has been adequately tested? Will there be understandable test evidence in any test tools used or software audit trails available and will there be expertise available to present this?

CSA potentially aims to reduce the documentation burden, but in doing so, it creates major problems when applied in Pharma.

CSA Problem 10: To comply with regulations and regulatory expectations, we must use scripted testing for Pharma.

PIC/S PI-011 (21):

• 13.4 Test scripts should be developed, formally documented … These test scripts should be related to the URS…
• Footnote 22 The test scripts related to the URS are the responsibility of the regulated users.

Draft EU GMP Annex 11 also considers test scripts approval and execution: (30)

• 9.4. Evidence. System qualification and validation should provide evidence in the form of executed test scripts, … specifications, are met by the system.
• 9.5 Traceability. Test cases should be traceable to individual requirements or specifications, e.g. by means of a requirements traceability matrix. Test cases not referring (traceable) to requirements or applicable specifications do not meet the requirements to qualification and validation.
• 9.7. Plan and approval…. Test scripts should be described in sufficient detail to ensure a correct and repeatable conduct of test steps and prerequisites.

CSA Problem 11: The key problem with unscripted approaches is lack of test instructions and evidence for traceability. An inspector or auditor cannot determine the extent of testing. A lack of documentation in any form is also a business risk for maintaining or updating software.

CSA Problem 12: In the absence of detailed CSA guidance, traceability (as required by Annex 11 4.4 [19]) can only be achieved using scripted testing against requirements in a URS. Traceability to URS requirements is noted in GPSV (10).

Spectrometer system: This requires a written URS with uniquely numbered requirements allowing traceability to scripted testing instructions that are executed by trained users.

Right Activities but the Wrong Order

There are several additional activities to support CSA:

• SOPs and effective training to ensure use of the software and ensure data integrity.
• Careful selection of software suppliers/vendors who know about GXP requirements and have the correct technical controls for regulatory compliance. This is already covered in PIC/S PI-041 in sections 9.1.4, 9.3.4, and section 10 (35).

CSA Problem 13: CSA considers purchasing process control for software selection however it is too vague to define if purchasing control implies supplier assessment. See EU GMP Chapter 7 (36) and Annex 11 (19) regulations for better supplier control.

CSA Problem 14: Purchasing control should not be placed in step 5 but at the start of the process. In practice, supplier assessment should be performed before system purchase for GAMP category 4 software (11).

Leveraging a supplier’s software development and testing by conducting a thorough assessment by a remote or on-site audit is regarded as an acceptable approach (1,30). However, using only a remote assessment audit questionnaire is NOT sufficient for all these tasks.

CSA Problem 15: A vendor certificate merely reflects supplier conformance to a quality standard, such as ISO certification. Standard certificates are NOT sufficient documents to assess a supplier.

CSA Problem 16: Section A considers artificial intelligence/machine learning (AI/ML);however, CSA does not discuss AI/ML throughout the assurance risk framework.

Spectrometer System: Depending on the system complexity and intended use (for example, basic measurements or build and use of a spectral library), additional documents such as a UAT test plan could be required. (See Figure 4) For a basic use, a single validation document may suffice, and we will describe it later.

Establishing the Appropriate Record

We highlighted the common key points of assurance records in Figure 5 and made a comparison between CSA and CSV documentation in Figure 4. However, the detail required to perform CSA effectively for software in production or quality management system is lacking. Applying CSA in Pharma would be brave, if not foolhardy.

Spectrometer System: Establishing the appropriate records would be defined in the validation plan for the system. Delivering the appropriate records and any changes would be discussed in the VSR.

Streamlining CSV: Integrated Validation Document

Are you lazy?

In Figure 4, there is a line from the SRA to a task called Integrated Validation Document (IVD), which has links to supplier installation, commissioning, prototype working, and application configuration. If you want to take an agile and flexible validation approach, then for simple GAMP category 3 systems (standard components) this is the way to do it (12,13).

Key components of an IVD are:

• Outline purpose and system description
• URS: Intended use requirements only with traceability
• Configuration settings including user roles and access privileges
• Testing preparation
• Test scripts with instructions written for trained users
• Assumptions, exclusions and limitations of the testing
• Test log and test execution notes for documenting and resolving any issues
• Test summary log
• Proforma summary report and release for operational use

This is a risk-based approach that leverages EU GMP Annex 15 Clauses 2.5 and 3.10.

Qualification documents may be combined together, where appropriate, e.g. installation qualification (IQ) and operational qualification (OQ) (29).

OQ normally follows IQ but depending on the complexity of the equipment, it may be performed as a combined Installation/Operation Qualification (IOQ) (29).

The IVD takes this approach to the logical conclusion by condensing all elements of a validation into a single document, which is pre-approved before completion and reviewed and approved after completion.The IVD was discussed in this column in 2023 (13), and the original article was published in 2009 (12). This is compliant with Pharma regulations and is controlled either by a validation master plan (29,38) or a procedure.

Update of the Final Guidance in February 2026

We have reviewed the final version of the CSA guidance and its potential applicability for use in a regulated laboratory within pharmaceutical industry. CSA focus is on software alone and ignores key elements of a computerized system, such as IT infrastructure, control of analytical instruments, process redesign, digitalization, and effective user training.

Although the Center for Drug Evaluation and Research (CDER) was consulted about this guidance, there are significant regulatory hurdles to apply in Pharma. If a Pharma company is struggling with CSV there is a great temptation to interpret CSA as carte blanche to do as little as possible.

Don’t. There may be an increased likelihood of regulatory observations.

We have found 16 problems with applying CSA into regulated GMP laboratories. CSA is not compliant with Pharma GMP regulations and regulatory expectations as we have discussed in this column. Current CSV already allows risk-based validation of computerized systems, so we don't need CSA to tell us to do this.

CSA is really old w(h)ine in new bottles.

We posed the question at the start of this article: should Dracula be back in his grave? Yes, is the unequivocal answer. We have a hammer available. Does anyone have a large wooden stake?

Acknowledgments

We would like to thank, in alphabetical order, Monika Andraos, Chris Burgess, Markus Dathe, Joanne Donald, Bob Iser, Bunpei Matoba, Ozan Okutan, and Yves Samson for their reviews and comments that have improved this column.

References

(1) FDA Guidance Computer Software Assurance for Production and Quality System Software. Food and Drug Administration, Silver Spring, MD, 2025 and 2026.

(2) McDowall, R. D. Does CSA Mean “Complete Stupidity Assured?” Spectroscopy 2021, 36 (9), 15-22. DOI: 10.56530/spectroscopy.vl2478y4.

(3) McDowall, R. D. CSA: Much Ado About Nothing? Spectroscopy 2023, 38 (4), 7–13,34. DOI: 10.56530/spectroscopy.hm6969t6.

(4) McDowall, R. D. Computer Software Assurance: Perfect Solution or Confidence Trick? Technology Networks, 2024. https://www.technologynetworks.com/tn/articles/computer-software-assurance-perfect-solution-or-confidence-trick-393177 (accessed 2024-10-13).

(5) Okutan. O. Why the CSA Guidance is Not Progress and Undermines FDA's Harmonisation Efforts within Medical Technology. 2022. https://www.linkedin.com/feed/update/urn:li:activity:6984560426529218560/ (accessed 2024-08-10).

(6) Okutan, O. The Rescue of the Software Category 'Support' in the CSA Guidance. LinkedIn, 2023. https://www.linkedin.com/search/results/content/?fromMember=%5B%22ACoAACS1UU4BMsYmAInQEt-m0zbT4lRdmVNMcVU%22%5D&heroEntityKey=urn%3Ali%3Afsd_profile%3AACoAACS1UU4BMsYmAInQEt-m0zbT4lRdmVNMcVU&keywords=ozan%20okutan&position=0&searchId=a382920c-9b49-4829-b447-cdb62f983e78&sid=D.9&sortBy=%22date_posted%22&update=urn%3Ali%3Afs_updateV2%3A(urn%3Ali%3Aactivity%3A7148284391771836416%2CBLENDED_SEARCH_FEED%2CEMPTY%2CDEFAULT%2Cfalse) (accessed 2024-12-09).

(7) Okutan, O. The Road to Quality is Paved with Bad Guidance: A Critical Appraisal of the FDA's Computer Software Assurance Draft Guidance or the Answer to Why it Belongs on the Compost Heap! 2024. https://www.linkedin.com/posts/activity-7148284391771836416-2jJF?lipi=urn%3Ali%3Apage%3Ad_flagship3_detail_base%3Bk2uGocvJQTeEZrVh03OGYg%3D%3D (accessed 2024-08-18).

(8) Okutan, O. Amazing Metamorphosis of CSA (Computer Software Assurance) - Transition from CSA I to CSA II to CSA III to What? 2025. https://www.linkedin.com/pulse/amazing-metamorphosis-csa-computer-software-assurance-ozan-okutan-eu6he/?trackingId=cR%2FYY2O8SSyb1H0mTK9iJQ%3D%3D (accessed 2025-12-09).

(9) Okutan, O. Regulatory Misstep: Why the FDA’s CSA Guidance Still Conflicts with Law and Standards — The Final Act II or Just the Last Sigh? 2025. https://www.linkedin.com/pulse/regulatory-misstep-why-fdas-csa-guidance-still-conflicts-ozan-okutan-i0sme/?trackingId=tSDiTj9tSby6fHrNbnHf2Q%3D%3D (accessed 2025-12-09).

(10) FDA Guidance for Industry General Principles of Software Validation. Food and Drug Administration, Rockville, MD, 2002.

(11) GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition); International Society of Pharmaceutical Engineering, 2022.

(12) McDowall, R. D. Validation of Computerised Systems using a Single Life Cycle Document (Integrated Validation Document). Qual. Assur. J. 2009, 12, 64-78. DOI: 10.1002/qaj.443.

(13) McDowall, R. D. Simple Spectrometer System, Simple Validation? Spectroscopy 2023, 38 (11), 16-19. DOI: 10.56530/spectroscopy.tc3777t8.

(14) GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems; International Society for Pharmaceutical Engineering, 2008.

(15) McDowall, R. D. Understanding the Layers of a Laboratory Data Integrity Model. Spectroscopy 2016, 31 (4), 15-25.

(16) McDowall, R. D. Data Integrity Focus 1: Understanding the Scope of Data Integrity. LCGC N.America 2019, 37 (1), 44–51.

(17) Donath, J.; McDowall, R. D. Cost Beneficial Validation of a Site-Wide Chromatography Data System. LCGC Europe 2005, 19 (9), 453 - 464.

(18) Smith, P. A.; McDowall, R. D. Analysis of FDA Infra-Red 483 Citations – Have You a Data Integrity Problem? Spectroscopy 2019, 34 (9), 22-28.

(19) EudraLex - Volume 4 Good Manufacturing Practice (GMP) Guidelines, Annex 11 Computerised Systems. European Commission: Brussels, 2011.

(20) FDA Pharmaceutical cGMPs for the 21st Century: A Risk-Based Approach. Food and Drug Administration, Rockville, MD, 2002.

(21) PIC/S Computerised Systems in GXP Environments (PI-011-3). Pharmaceutical Inspection Convention / Pharmaceutical Inspection Co-operation Scheme (PIC/S): Geneva, 2007.

(22) Burgess, C.; McDowall, R. D. An Integrated Risk Assessment for Analytical Instruments and Computerised Laboratory Systems. Spectroscopy 2013, 28 (11), 21-26.

(23) USP <1058> Analytical Instrument and System Qualification in Process Revision. PF 2025, 51 (2).

(24) McDowall, R. D. An Enhanced Approach to Analytical Instrument and System Qualification. Spectroscopy 2025, 40 (4), 6-11. DOI: DOI: 10.56530/spectroscopy.ne7878t3.

(25) Guide for an Integrated Lifecycle Approach to Analytical Instrument Qualification and System Validation. European Compliance Academy, 2023. https://analytical.gmp-compliance.org/members.html?_hash=RFQTqx%2FMs8rkLfD5FoZvLB6GuxKqWs95mlNh0nCxox4%3D&redirect=https%3A%2F%2Fanalytical.gmp-compliance.org%2Fmembership%2Fmembers-area.html (accessed 2025-12-10 10).

(26) ICH Q9(R1) Quality Risk Management. International Council on Harmonisation of Technical Requirements for Pharmaceuticals for Human Use Geneva, 2023.

(27) IEEE Standard 610.12-1990-Glossary of Software Engineering Terminology (Replaced by ISO 24765: 2010). Institute of Electrical and Electronic Engineers, Piscataway, NJ, 1990.

(28) McDowall, R. D. Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and Regulatory Requirement.s Royal Society of Chemistry, 2017.

(29) EudraLex - Volume 4 Good Manufacturing Practice (GMP) Guidelines, Annex 15 Qualification and Validation. European Commission, Brussels, 2015.

(30) Stakeholders’ Consultation on EudraLex Volume 4 - Good Manufacturing Practice Guidelines: Chapter 4, Annex 11 and New Annex 22. European Medicines Agency, 2025. https://health.ec.europa.eu/consultations/stakeholders-consultation-eudralex-volume-4-good-manufacturing-practice-guidelines-chapter-4-annex_en (accessed 2025-07-07).

(31) 21 CFR 211 Current Good Manufacturing Practice for Finished Pharmaceutical Products. Food and Drug Administration, Silver Spring, MD, 2008.

(32) EudraLex - Volume 4 Good Manufacturing Practice (GMP) Guidelines, Chapter 6 Quality Control. European Commission: Brussels, 2014.

(33) O.Okutan. The Real Dangers of Unquestioned Automation in Regulated Environments - Poorly Designed Guidance Documents Under Scrutiny. 2025. https://www.linkedin.com/pulse/real-dangers-unquestioned-automation-regulated-poorly-ozan-okutan-yju8e/ (accessed 2025-12-13).

(34) ISO 29119-1: Software and Systems Engineering – Software Testing - Part 1: General ConceptsInternational Standard Organisation, Geneva, 2022.

(35) PIC/S PI-041 Good Practices for Data Management and Integrity in Regulated GMP / GDP Environments Geneva, 2021.

(36) EudraLex - Volume 4 Good Manufacturing Practice (GMP) Guidelines, Chapter 7 Outsourced Activities. European Commission, Brussels, 2013.

(37) IEEE Software Engineering Standard 829 - 2008 Software Test Documentation. Institute of Electronic and Electrical Engineers, Piscataway, NJ, 2008.

(38) PIC/S Recommendations on Validation Master Plan, Installation and Operational Qualification, Non-Sterile Process Validation and Cleaning Validation (PI-006-3). Pharmaceutical Inspection Convention / Pharmaceutical Inspection Co-operation Scheme (PIC/S), Geneva, 2007.