Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics → Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Beginner Data Integrity

The GxP, CSV, and Data Integrity Glossary: Every Acronym Decoded

A working glossary of the GxP, computer system validation, and data integrity terms you need to do the job and pass the interview, with the regulatory basis, region-to-region naming, confusion-resolving tables, and a plain definition for each.

Every quality and validation role runs on a shared vocabulary. When an inspector asks “walk me through your URS-to-RTM traceability” or “how does your audit trail support ALCOA+”, they expect you to answer in the same shorthand they used to ask. Get the terms wrong and you lose credibility in the first five minutes. Get them right and the rest of the conversation flows.

This page defines the terms that actually come up: in protocols, in audit trail reviews, in deviation meetings, in interviews. Each entry tells you what the term means, the regulation or standard behind it where one exists, and the practical reason a quality professional cares. The terms are grouped so you can study one cluster at a time, and the high-frequency ones get a worked example or a table rather than a one-line gloss.

A note on how to use it. Do not memorize definitions as flashcards. Memorize the relationships: a URS feeds a Functional Specification, which feeds Design, which gets traced in an RTM, which is verified by IQ/OQ/PQ, all governed by a Validation Plan, all underpinned by ALCOA+. When you can draw the chain, the acronyms stop being trivia and become a map of how the work fits together.


How to read a regulatory citation

Before the terms, a quick orientation, because half of sounding competent is citing the right document by its real name.

  • CFR is the US Code of Federal Regulations. GMP for drugs lives in 21 CFR Parts 210 and 211. Electronic records and signatures live in 21 CFR Part 11. Good Laboratory Practice lives in 21 CFR Part 58. Medical device quality lives in 21 CFR Part 820, amended by the QMSR final rule (issued February 2024, effective 2 February 2026) to incorporate ISO 13485:2016 by reference.
  • EU GMP is published as EudraLex Volume 4, with topic-specific Annexes. Annex 11 covers computerised systems. Annex 1 covers sterile manufacturing. Annex 15 covers qualification and validation. Annex 16 covers the Qualified Person.
  • ICH guidelines carry a letter and number: Q for quality (Q7, Q9, Q10), E for efficacy and clinical (E6 for GCP), M for multidisciplinary.
  • ISO and IEC are international consensus standards (for example ISO 13485, ISO 14971, IEC 62304).
  • USP chapters are cited with a number in angle brackets, for example <71> for sterility testing.
  • GAMP 5 and the PIC/S and MHRA data integrity guidances are industry or regulator guidance, not law, but inspectors treat alignment with them as the expected standard.

When you cite, name the document and the part. “Part 11” beats “the FDA electronic records rule.” “Annex 11” beats “the EU computer thing.”


The GxP family

GxP

The umbrella for Good “x” Practice, where x stands for the discipline. It is shorthand, not a regulation in itself. A system is “GxP” if it touches data or processes that support a regulated decision about product quality, safety, or efficacy. That GxP determination is the gate that decides whether validation, Part 11 controls, and data integrity requirements apply at all.

GMP / cGMP

Good Manufacturing Practice. The “c” means “current,” signaling that expectations evolve with technology and that meeting a decade-old interpretation is not a defense. US drug GMP is 21 CFR 210/211; API GMP is ICH Q7; EU GMP is EudraLex Volume 4. Covers everything from facility design to batch release.

GLP

Good Laboratory Practice, governing nonclinical safety studies that support regulatory submissions. US GLP is 21 CFR Part 58. Note the trap: routine QC release testing in a manufacturing lab is GMP, not GLP. GLP applies to the toxicology and safety studies done before and during clinical development.

GCP

Good Clinical Practice, governing the conduct of clinical trials to protect subjects and ensure credible data. The current global standard is ICH E6(R3), which reached Step 4 in January 2025 and was adopted by FDA in 2025, superseding E6(R2). Its restructured format of overarching general principles plus annexes emphasizes risk-proportionate, technology-enabled trials.

GDP

Good Distribution Practice, governing storage and transport of medicines through the supply chain so product reaches the patient with quality intact. The EU guideline is 2013/C 343/01. Cold chain control sits here.

GVP / GPvP

Good Pharmacovigilance Practice, governing collection and assessment of safety information after a product is on the market. The EU set is the GVP Modules.

GDocP

Good Documentation Practice. The records and entries discipline (legible, contemporaneous, attributable, corrected properly) that turns abstract data integrity principles into how you actually fill in a logbook or sign a record. See Good Documentation Practices.


Data integrity core

Data Integrity (DI)

The degree to which data is complete, consistent, and accurate throughout its lifecycle. The working bar regulators apply is that records are trustworthy and reliable enough to base a quality decision on. It is not a single control; it is the sum of system design, procedures, and culture. Start at Data Integrity Foundations.

ALCOA

The original five attributes that define a good record: Attributable, Legible, Contemporaneous, Original, Accurate. Originated in FDA thinking and now universal across guidances.

ALCOA+

ALCOA extended with Complete, Consistent, Enduring, Available. The ”+” four close common gaps (missing reanalyzed results, inconsistent timestamps, records that do not survive their retention period, archives no one can retrieve). The full nine-attribute breakdown with examples is in ALCOA+ in detail.

AttributeOne-line meaningTypical failure
AttributableYou can tell who did it and whenShared login, no audit trail
LegibleReadable and permanentPencil entry, overwritten field
ContemporaneousRecorded at the time of the activityBackdated logbook
OriginalThe first capture, or a true copy of itWorking off a transcribed value
AccurateCorrect, no errors, properly reviewedUnreviewed manual integration
CompleteAll data including repeats and rerunsFailing injection deleted
ConsistentSequence and timestamps make senseClock not controlled
EnduringSurvives its retention periodThermal paper that fades
AvailableRetrievable when neededArchive no one can read

Static vs Dynamic records

A static record is fixed once created (a paper printout, a PDF of a result). A dynamic record lets you interact with the data after capture (rechromatograph, reprocess, change integration parameters). The distinction matters because a static printout of a dynamic record is not the complete record. Inspectors specifically probe whether you retained the dynamic original. See Static, Dynamic Records, and True Copies.

True copy

A copy of original data that preserves the meaning and all metadata, verified accurate. Scanning a chromatogram to PDF without the underlying data file is generally not a true copy because you lost the dynamic content.

Certified copy

The UK and EU data integrity vocabulary (MHRA GxP Data Integrity Guidance and Definitions; EU GMP Chapter 4) for a copy that a person with the knowledge, training, and authority to do so has confirmed, by dated signature or its electronic equivalent, to be an accurate and complete copy that preserves the full meaning of the original record. FDA’s Part 11 vocabulary uses “true copy” for essentially the same underlying control. The two labels come from different rulebooks but ask the same question: has someone accountable confirmed the copy did not lose content or meaning before you rely on the copy in place of the original, or before you destroy the original.

Common mistake: photocopying or scanning a record and treating the copy as good enough to destroy the original, without anyone confirming or documenting that the copy is complete, accurate, and unaltered. An uncertified, unconfirmed copy is not a defensible substitute for the original if the original’s disposition is ever questioned in an investigation or an inspection.

True copy, certified copy, and static/dynamic, at a glance

TermQuestion it answersGoverning vocabularyTypical failure
True copyDid this copy keep the meaning and metadata of the original?US, Part 11 and FDA guidanceA PDF made without the underlying dynamic data file
Certified copyHas someone accountable confirmed and signed that the copy is accurate and complete?UK/EU, MHRA and EU GMP Chapter 4Copy made and original destroyed with no confirmation step recorded
Static recordIs the record fixed once it was captured?BothTreating a static printout as if it can still be reprocessed
Dynamic recordCan the record still be interacted with, such as reprocessed, recalculated, or filtered, after capture?BothRetaining only a static printout of a record that was dynamic at capture

Metadata

Data about data: the who, what, when, and how that gives a result context. A peak area is data; the integration parameters, instrument ID, analyst, and timestamp are metadata. Without metadata, a number is not a record. See Data Lifecycle and Metadata.

Data lifecycle

The full span from creation through processing, review, reporting, retention, and destruction. DI controls must hold at every stage, not just at capture. Defined and walked through in Data Lifecycle and Metadata.

Data governance

The organizational structure, accountability, policies, and procedures that make data integrity actually happen in practice: who owns which data and which system, who decides how a system is configured, who is accountable when a gap is found, and how the organization keeps its DI controls current as systems, processes, and staff change. Data integrity describes the property you want a record to have; data governance is the management system that produces and sustains it. Without a named accountable owner, a DI control tends to decay quietly after the original project team moves on. See Data Governance Framework and the role map in Data Governance Roles and Careers.

Data quality

Whether data is correct, precise, and fit for its intended analytical or business use, a different question from whether the record-keeping controls around it meet ALCOA+. A number can be fully data-integrity compliant (attributable, contemporaneous, unaltered) and still be low quality if the underlying measurement was imprecise or the sampling plan was weak. The reverse also happens: a highly accurate measurement recorded outside any controlled, attributable process has a data integrity problem even though the number itself is correct. Quality professionals sometimes use “data integrity” and “data quality” interchangeably in conversation; do not do that in a written investigation, because the corrective action for each is different. A data integrity gap needs a system, control, or behavior fix; a data quality gap needs a method, instrument, or process fix.

Data integrity vs data quality vs data governance, at a glance

TermWhat it asksWho typically owns itExample gap
Data integrityIs the record complete, attributable, and unaltered across its lifecycle (ALCOA+)?QA / data integrity programA shared login means a change cannot be attributed to one person
Data qualityIs the underlying value correct, precise, and fit for its use?Process, method, or system ownerAn imprecise assay produces noisy but correctly-recorded numbers
Data governanceWho decides, who is accountable, and how are DI and data quality controls kept current?Data governance board / named data ownersNo one owns a system after the original project team moved on

Data criticality and data risk

A risk-based way to scale controls: the more a record drives a GMP decision and the easier it is to alter undetected, the more control it needs. Lets you spend effort where it matters instead of validating everything to the same depth. See Data Criticality and Data Risk.

Audit trail

The secure, computer-generated, time-stamped electronic record of who did what to a record and when, including the original value when something is changed. Required by Part 11 (11.10(e)) and Annex 11 (clause 9). Two parts: it must exist (system capability) and it must be reviewed (a procedural step before you trust the data). The design considerations are in Audit Trail Design and Review; the review routine is in Operationalizing Audit Trail Review.

Audit trail review

The act of examining audit trails for unexplained changes, deletions, aborted runs, or timestamp anomalies, performed as part of data review (often at batch or result review). A finding pattern inspectors love: a system has audit trails, but no one ever looks at them.


Part 11 and Annex 11

Part 11

21 CFR Part 11, the US rule on electronic records and electronic signatures, in force since 1997. It tells you when an electronic record can stand in for paper and what controls (audit trails, access security, validation, signature linkage) make that record trustworthy. The companion is 21 CFR Part 11 and EU Annex 11, with practical implementation in Part 11 and Annex 11 Practical Guide.

Annex 11

EU GMP Annex 11, Computerised Systems. The EU counterpart to Part 11, broader in scope because it covers the whole system lifecycle (risk management, suppliers, validation, data, audit trails, periodic review) rather than focusing on records and signatures.

Electronic record

Any combination of text, graphics, data, or other information in digital form that is created, modified, maintained, archived, or retrieved by a computer system, as defined in Part 11.

Electronic signature (e-signature)

A computer compilation that an individual executes as the legally binding equivalent of a handwritten signature. Part 11 requires each signature to capture the printed name of the signer, the date and time, and the meaning (review, approval, authorship), and to be permanently linked to its record so it cannot be cut and pasted. See Electronic Signatures Implementation.

Open vs closed system

A closed system is one where access is controlled by the people responsible for the records (most validated GMP systems). An open system is one where access is not so controlled (data crossing the public internet to an outside party). Open systems carry extra Part 11 requirements such as encryption. The distinction drives which controls you owe.

Hybrid system

A system where electronic records are kept but signatures or some steps stay on paper, or where paper and electronic coexist for the same process. Hybrids are high risk because the link between the paper signature and the electronic data is procedural, not technical. See Hybrid Paper and Electronic Records.


CSV, CSA, and QMSR

CSV

Computer System Validation (also Computerized System Validation). Documented evidence that a computerized system does what it is intended to do, consistently and reliably, and that it will keep doing so. Required wherever a computerized system supports a GxP activity. The lifecycle approach is in GAMP 5 CSV Framework.

CSA

Computer Software Assurance, an FDA guidance for the software controls required by 21 CFR 820.70(i), automated processes used directly in or to support medical device production or the quality system. It reframes assurance effort toward critical thinking and testing that matches risk, including unscripted or ad hoc testing for low-risk, well-understood functions, rather than producing scripted documentation for its own sake regardless of risk.

The history is worth knowing precisely because it comes up in interviews. FDA issued the guidance as a draft on 13 September 2022. It was finalized on 24 September 2025 as “Computer Software Assurance for Production and Quality System Software” (Federal Register notice 2025-18468). A further revision issued 3 February 2026, titled “Computer Software Assurance for Production and Quality Management System Software,” superseded the September 2025 version; that revision aligned CSA’s terminology with the QMSR’s adoption of ISO 13485 language (see QMSR below) but did not change the CSA approach itself, and it carried no separate Federal Register notice. In both forms, the guidance supersedes Section 6, “Validation of Automated Process Equipment and Quality System Software,” of FDA’s 2002 “General Principles of Software Validation” guidance, not the whole document.

Common mistake: treating CSA as if it were issued under 21 CFR Part 211 and governs drug GMP computerized systems the same way it governs device systems. Read literally, CSA’s scope is 820.70(i): device production and quality system software, which also reaches combination products with a device constituent through 21 CFR Part 4. It is not an FDA guidance for drug or biologic manufacturing systems validated under Part 211. Many drug and biologics CSV programs adopt CSA’s risk-based, critical-thinking method anyway, often folded into a GAMP 5 approach, which is a legitimate and common quality-policy choice, but say so as your own program’s chosen method rather than as compliance with an FDA guidance that does not formally cover your regulation. Telling an inspector “we follow CSA under Part 211” invites a scope question that has no clean answer.

CSA does not replace validation; it changes where you spend the effort, pushing testing depth toward high-risk functions (those that could cause patient harm or a quality escape if they failed silently) and allowing lighter-touch assurance for low-risk functions with an established, credible basis. See Computer Software Assurance (FDA) and the contrast in CSV vs CSA Audit Checklist.

QMSR

Quality Management System Regulation, FDA’s amendment of 21 CFR Part 820 that incorporates ISO 13485:2016 by reference as the core quality system requirement for medical devices, layering FDA-specific provisions on top where the Food, Drug, and Cosmetic Act requires more than ISO 13485 alone provides. The final rule was issued February 2024; the regulation became effective 2 February 2026. Most of the old Part 820 subparts covering areas like design controls, production and process controls, and records were removed or reserved because ISO 13485’s clauses now cover that ground; the old records-control requirements now live at the new 820.35. Manufacturers are not required to hold separate ISO 13485 certification, and FDA does not rely on such certification for its own oversight; inspectors still audit against the regulation, using the ISO 13485 clause structure as the backbone. QMSR reaches combination products with a device constituent part through 21 CFR Part 4. See Combination Products and cGMP (21 CFR Part 4).

Common mistake: citing an old Part 820 subpart or section number (for example the pre-2026 design-controls or records-control section) in a current procedure or investigation as if it still exists as written. Under QMSR, the underlying requirement is carried by a referenced ISO 13485 clause plus any surviving or renumbered CFR section (records control now sits at 820.35); citing the retired number is a currency error an auditor will catch quickly.

GAMP 5

Good Automated Manufacturing Practice, Second Edition, the ISPE guide that is the de facto industry method for CSV. It introduces the software category model and a risk-based, scalable V-model lifecycle. Not a regulation, but cited and expected. See GAMP 5 CSV Framework.

GAMP software categories

GAMP 5 sorts software into numbered categories so the validation effort scales to the type of software, from underlying infrastructure (operating systems, database engines, which you qualify as a platform), through off-the-shelf products used as supplied, to configured products such as a LIMS or MES, to fully custom code. The higher categories carry more verification because more of the system was built or shaped for you, with custom builds reaching the full lifecycle including design and code review. Category 2 was dropped in the GAMP 5 model. For the full classification and worked examples, read GAMP 5 CSV Framework. The point: an off-the-shelf tool used as supplied does not need the same rigor as a custom build. Misclassifying upward wastes effort; misclassifying downward leaves risk uncovered.

V-model

The validation lifecycle drawn as a V: requirements and specifications descend the left side (URS, FS, DS), and verification activities ascend the right side, each test level tied back to the spec it verifies (IQ to design, OQ to functional spec, PQ to user requirements). It makes traceability visual.

Validation Plan (VP)

The document that defines scope, approach, deliverables, roles, and acceptance for a specific validation effort. It is the contract for the project. Larger than a single system, the Validation Master Plan (VMP) sets the site-wide strategy and inventory. See Validation Master Plan and Periodic Review.

GxP assessment / system classification

The upfront determination of whether a system is GxP and, if so, its risk and GAMP category. This single decision drives the entire validation depth. Documented, signed by QA, and revisited at change.


Requirements and specifications

These five terms form the spine of every validation. Learn the order: a need becomes a requirement, a requirement becomes a specification, a specification becomes a test, and the trace matrix proves nothing fell out along the way.

URS

User Requirement Specification. What the business and quality users need the system to do, written in plain, testable statements before you design or buy anything. Each requirement should be uniquely numbered, atomic, and verifiable. The URS is the anchor for PQ and the top of the traceability chain. See User Requirements and Traceability.

Worked example of a good vs weak requirement:

IDWeakStrong (testable)
URS-014”The system should be secure.""The system shall lock a user account after 5 consecutive failed login attempts.”
URS-027”Audit trails are needed.""The system shall record, for every change to a GMP record, the prior value, new value, user ID, and UTC timestamp, viewable without altering the record.”

The strong versions can be passed or failed in a test. The weak ones cannot, so they will haunt you in OQ.

FS / FRS

Functional Specification (or Functional Requirements Specification). How the system will meet each user requirement, described in terms of functions and behaviors. Written by or with the vendor or technical team. Each FS item should trace back to a URS item.

DS / DDS

Design Specification (or Detailed Design Specification). The technical “how it is built”: configuration settings, data model, interfaces, code design for custom elements. Depth scales with GAMP category; a Category 3 product may have little or no DS, a Category 5 build has a lot.

Configuration Specification

For configured products (Category 4 such as LIMS and MES), the documented record of every configuration choice (workflows, user roles, calculations, master data). It is what you verify in OQ and restore from after disaster recovery.

RTM / Traceability Matrix

Requirements Traceability Matrix. The table that links each requirement to its specification and to the test that verifies it, proving every requirement is covered and every test traces to a requirement. It is the single artifact inspectors use to check that nothing was dropped.

Worked RTM snippet:

Req IDRequirement (short)Spec refTest IDResult
URS-014Lock account after 5 failed loginsFS-009OQ-031Pass
URS-027Audit trail captures old/new valueFS-022OQ-045Pass
URS-041Result calc to 4 sig figsDS-018OQ-052Pass

An empty cell in the Test column is an uncovered requirement. A test with no Req ID is a test with no reason to exist. Both are the kind of gap inspectors regularly cite. More in User Requirements and Traceability.


Qualification and testing

Qualification

Documented evidence that equipment or a system is installed and operates correctly. For equipment it is the equivalent of validation for systems. The EU framework is Annex 15. The lifecycle is in Equipment Qualification Lifecycle.

The three terms below nest inside one another rather than sitting side by side: qualification is often a building block inside a validation, and verification is a lighter check used when someone else already did the heavy validation work and you are confirming it holds in your hands.

Qualification, validation, and verification, at a glance

TermAnswers the questionTypical objectExample
QualificationIs this equipment or system installed and operating correctly?Equipment, instruments, computerized systems (DQ/IQ/OQ/PQ)Qualifying an autoclave before it is put into GMP use
ValidationDoes this process or system consistently deliver its intended result across its full operating range?Manufacturing processes, computerized systems, analytical methodsValidating a manufacturing process across three PPQ batches
VerificationDoes this already-established method or already-built item work correctly in your hands, at your site?Compendial methods, transferred methods, systems already validated elsewhereVerifying a USP monograph method performs as expected in a new lab

DQ

Design Qualification. Documented verification that the proposed design meets the user requirements and intended use, done before purchase or build.

IQ

Installation Qualification. Documented verification that the system or equipment is installed correctly per specification: right components, right version, right environment, utilities connected, documents in place.

OQ

Operational Qualification. Documented verification that the system functions as intended across its operating range: each function works, alarms fire, security enforces, calculations are correct, boundary and challenge conditions behave. This is where most functional test scripts live.

PQ

Performance Qualification. Documented verification that the system performs reliably for its intended use in the real production setting, often with real or representative data and real users. PQ traces to the URS.

IOQ / OQ-PQ combined

Smaller or lower-risk systems often combine IQ and OQ, or OQ and PQ, into one protocol. Acceptable when justified by risk; document the rationale.

FAT / SAT

Factory Acceptance Test and Site Acceptance Test. Vendor-side (FAT, at the vendor’s facility before shipment) and customer-side (SAT, after installation) acceptance testing of equipment or systems. Well-run FAT/SAT can be reused as part of IQ/OQ to avoid duplicate testing, if the protocols and data integrity controls support it. See Factory and Site Acceptance Testing.

Commissioning / C&Q / ASTM E2500

Commissioning and Qualification, the science and risk-based approach in ASTM E2500 that uses verification activities (including good engineering practice and reused vendor testing) to qualify systems efficiently while focusing rigor on what affects product quality (critical aspects, critical design elements). See Commissioning and Qualification (ASTM E2500).

Test script / test case

The step-by-step instruction with expected results and a place to record actual results, pass or fail, with evidence. Each step should be unambiguous. Good scripts predefine acceptance criteria so the tester is not deciding pass or fail on the fly.

Deviation (test) / test incident

A documented mismatch between expected and actual results during testing. It must be investigated, assessed for impact, resolved, and closed before the validation can be summarized. See Validation Test Failure Management.

VSR

Validation Summary Report. The document that pulls together all protocol results, resolves open deviations, states whether acceptance criteria were met, and releases the system for GxP use. See Validation Summary Report and Release.


Operating the validated system

A validated system is not “done.” It must be kept in a validated state. These terms govern the operational phase, which is where most inspection findings actually live.

Change control

The formal process to assess, approve, test, and document any change to a validated system before it is made, so the change does not break the validated state. The gate question is always “what is the GxP impact and what revalidation is needed?” See Change Control for Validated Systems.

Configuration management

Knowing and controlling the exact configuration baseline of a system at any time: versions, settings, patches. You cannot assess change impact if you do not know your baseline. See IT Change and Configuration Management (GxP).

Periodic review

The scheduled re-evaluation (often annual or risk-based) confirming a system is still validated, still under control, and still fit for use: open changes, incidents, access reviews, audit trail review status, patch level. Required by Annex 11 clause 11.

Backup and restore / disaster recovery (DR)

Backup is copying data so it can be recovered; restore is proving you can bring it back; disaster recovery is the plan to resume the whole system after a major failure. Inspectors ask for evidence of a tested restore, not just a backup schedule. See Backup, Restore, and Disaster Recovery Validation.

Business continuity

The plan to keep the GxP process running (often on paper) while a system is down, so you do not lose data or batches during an outage.

Decommissioning / data migration

Retiring a system and, where data must persist, moving it to a new system with documented evidence that completeness and meaning were preserved. Migration is itself a validated activity. See Data Migration Validation.

Access control / RBAC

Role-Based Access Control: granting system privileges by job role so people can only do what their role allows, and no one has rights that let them bypass controls. Segregation of duties (the person who runs a test cannot also approve its result, the admin who can delete data is not a routine analyst) is a core DI control. See CSV Cybersecurity and Access Control.

Time stamp / system clock control

Trustworthy timestamps depend on a controlled, synchronized, tamper-resistant clock (often network time, with users unable to change it). Uncontrolled clocks undermine the Contemporaneous and Consistent attributes and are a frequent finding. See Time Stamps and System Clock Control.


The systems by acronym

You will hear these named constantly. Know the category and what data integrity question each one raises.

LIMS

Laboratory Information Management System. Manages samples, tests, specifications, and results in the QC lab. Typically GAMP Category 4. DI focus: result entry controls, spec limits, audit trail on result changes. See LIMS Implementation and Validation.

CDS

Chromatography Data System. Acquires and processes chromatography data (HPLC, GC). The single most cited system in DI warning letters because of manual reintegration, “test injections,” and disabled audit trails. DI focus: who can reprocess, audit trail on integration, no deleting failing runs. See Chromatography Data System Integrity.

MES / EBR

Manufacturing Execution System and Electronic Batch Record. Runs and records production on the floor, enforcing the recipe and capturing the batch record electronically. DI focus: enforced sequencing, review by exception, e-signature at each step. See MES, EBR, and SCADA Data Integrity.

SCADA / DCS / PLC / HMI

SCADA (Supervisory Control and Data Acquisition), DCS (Distributed Control System), PLC (Programmable Logic Controller), and HMI (Human Machine Interface) are the layers of process automation that run and monitor equipment. DI focus: who can change setpoints, alarm handling, recipe control, data archiving. See PLC, DCS, and HMI Fundamentals and Automation Validation (PLC, SCADA, DCS).

Process historian

The time-series database that archives process data (temperatures, pressures, flows) from automation systems. DI focus: data completeness, no gaps, controlled access. See Process Historian Data Integrity.

ERP

Enterprise Resource Planning. The business backbone (materials, inventory, batch genealogy, release status). GxP-relevant where it holds disposition or genealogy data.

EDMS / DMS

Electronic Document Management System. Controls SOPs and quality documents: versioning, approval workflow, controlled distribution. See Document Control Fundamentals.

QMS (system)

Quality Management System software that runs deviations, CAPAs, change controls, and complaints as electronic workflows. Distinct from the QMS as an organizational concept (below).

CTMS / EDC / eTMF (clinical)

Clinical Trial Management System, Electronic Data Capture, and electronic Trial Master File: the clinical-side systems for running trials, capturing subject data, and holding the trial’s essential documents. See Clinical Systems and GCP Digital Quality and eTMF and the Trial Master File.


AI and machine learning in GxP

Artificial intelligence and machine learning are entering GxP workflows faster than most quality systems have built vocabulary for, so this cluster of terms is worth learning even before an AI-enabled system reaches your desk.

AI / ML

Artificial Intelligence is the broad field of building systems that perform tasks normally requiring human judgment. Machine Learning is the subset that learns its behavior from data rather than being explicitly programmed rule by rule. A GxP tool built on fixed, deterministic logic (a calculation, a rule engine, a lookup table) is not ML, even if people call it “AI” in conversation. Whether a system is genuinely ML changes what you validate: you are qualifying a model’s learned behavior across its real operating range and relevant subgroups, not just testing a fixed set of logic paths. See Validating AI-Enabled GxP Systems and AI Governance in GxP.

GMLP

Good Machine Learning Practice, a set of practices, echoing the structure of established Good Practice guides like GMP and GLP, for developing, validating, and monitoring machine learning models used in regulated settings: representative and well-managed training data, appropriate reference standards, meaningful human oversight, and performance monitored across the model’s actual deployment conditions rather than only its training conditions. The concept originated in FDA and international medical device guidance and is now referenced more broadly wherever a machine learning model touches a GxP decision. A conformance-evidence checklist is in GMLP Conformance Evidence.

PCCP

Predetermined Change Control Plan. A pre-specified plan, agreed before deployment, describing what changes an AI/ML model is expected to undergo after go-live (commonly, periodic retraining on new data) and exactly how each type of change will be validated and controlled. It matters because ML models can legitimately need to change on a cadence that a traditional one-time change control process cannot keep pace with; a PCCP lets you plan for that instead of treating every retrain as an unplanned deviation. See Predetermined Change Control Plan for an AI-Enabled Device.

Model card

A structured, standardized summary of a specific trained model version: its intended use, training data characteristics, performance across relevant subgroups, known limitations, and version identity. It functions much like a certificate of analysis for a model, giving a reviewer or downstream user the information to judge whether the model is fit for a specific use without re-deriving that judgment from scratch. See the AI Model Card record.

Model drift

The gradual degradation of a deployed model’s real-world performance as the data it sees in production diverges from the data it was trained or validated on. Undetected drift is the machine learning equivalent of a process quietly going out of trend, except the model itself does not fail the way equipment fails; it just gets worse without announcing it. Scheduled monitoring, not a wait-for-a-complaint posture, is the control. See ML Model Monitoring and Drift SOP and GxP ML Model Lifecycle.

Human-in-the-loop

A design and control principle where a person reviews, can override, or must affirmatively approve an AI/ML system’s output before it takes effect in a GxP process, rather than the system acting on its own. The required level of human oversight scales with risk: a low-risk drafting aid may need only periodic spot-checking, while a system that influences a batch disposition or a safety decision needs a defined, documented human review step every time. See AI Risk Assessment (GxP).

LLM-as-judge

The practice of using one large language model to evaluate or score the output of another system, or of a human process, typically to scale a quality check that would otherwise require a person to review every output by hand. Treat the judge model itself as a system that needs qualification: its scoring must be checked against a human-rated reference set before you trust its verdicts, because an unqualified judge just adds a second layer of automation on top of the original uncertainty rather than resolving it. See Qualifying LLMs and GenAI for GxP Use and the LLM-as-Judge Qualification Protocol.


Quality system terms

QMS

Quality Management System, the organizational framework of processes that ensures product quality. The pharmaceutical model is ICH Q10. See Pharmaceutical Quality System.

PQS

Pharmaceutical Quality System, the ICH Q10 name for a GMP-specific QMS covering the product lifecycle from development through discontinuation.

CAPA

Corrective and Preventive Action. Corrective action fixes the cause of a problem that happened; preventive action stops a potential problem before it happens. Effectiveness must be verified, not assumed. See What Is a CAPA and CAPA Effectiveness Verification.

Deviation / nonconformance

A departure from an approved procedure, specification, or standard. Must be documented, assessed for impact, investigated to root cause when warranted, and closed with actions. See Deviation Management.

RCA

Root Cause Analysis. The structured search for the true underlying cause (not the symptom) using tools like the 5 Whys, fishbone (Ishikawa), and fault tree. Weak RCA, stopping at “human error” or “retrained the operator,” is one of the most common inspection criticisms. See Root Cause Analysis Techniques.

OOS / OOT

Out of Specification and Out of Trend. OOS is a result outside an established acceptance criterion; OOT is a result within spec but inconsistent with the expected pattern. OOS investigations follow a defined two-phase structure (lab assessment, then full investigation). See OOS Investigation Process and Out-of-Trend Investigations.

QRM

Quality Risk Management. The systematic process to assess, control, communicate, and review risk to quality, defined in ICH Q9(R1). Tools include FMEA and risk ranking. See Quality Risk Management.

FMEA

Failure Mode and Effects Analysis. A risk tool that scores failure modes by severity, occurrence, and detectability to prioritize controls. The product of the three is the Risk Priority Number (RPN).

Management review

The periodic leadership review of QMS performance and quality metrics required by ICH Q10. See Management Review (Q10).

Batch record / BMR / BPR

The complete record of a batch’s manufacture: the Master record (the approved template) and the executed Batch Manufacturing/Packaging Record (the filled-in copy for one batch). Review-and-release of this record is a GMP decision. See Batch Record Review (GMP).

Batch disposition / QP release

The decision to release or reject a batch. In the EU, certification is made by a Qualified Person (QP) under Annex 16. See Batch Disposition Decisions and Qualified Person Batch Release (Annex 16).

COA

Certificate of Analysis. The document summarizing a batch’s test results against specifications, supporting release and sent to customers. See Certificate of Analysis.

SOP

Standard Operating Procedure. The approved, controlled instruction for how to perform a task consistently. See How to Write an SOP.


Process validation and lab terms

PV / PPQ / CPV

Process Validation is the lifecycle proving a manufacturing process consistently produces conforming product. The FDA 2011 guidance defines three stages: Stage 1 process design, Stage 2 PPQ (Process Performance Qualification, the formal validation batches), Stage 3 CPV (Continued Process Verification, ongoing monitoring). See Process Validation Lifecycle, Process Performance Qualification (PPQ), and Continued Process Verification (CPV).

QbD / DoE / CQA / CPP

Quality by Design builds quality into the process by understanding it, using Design of Experiments (DoE) to map how Critical Process Parameters (CPP) affect Critical Quality Attributes (CQA) within a defined design space. The ICH basis is Q8, Q9, Q10, Q11. See Quality by Design and DoE.

Method validation / verification / transfer

Validation proves an analytical method is fit for purpose (accuracy, precision, specificity, linearity, range, and so on) per ICH Q2(R2). Verification confirms a compendial (USP/Ph. Eur.) method works in your lab. Transfer moves a validated method between labs with documented equivalence. See Method Validation Essentials, Compendial Method Verification, and Analytical Method Transfer.

AIQ

Analytical Instrument Qualification, the USP <1058> framework that classifies instruments into Groups A, B, and C and scales the DQ/IQ/OQ/PQ effort to the group. Group A (standard apparatus and non-measuring equipment) needs only documented conformance to a specification or SOP, while Groups B and C require progressively fuller qualification, with Group C (computer-controlled systems) adding software validation. It is the link between qualifying the instrument and validating the software on it. See Analytical Instrument Qualification.

Cpk / control chart

Cpk is a process capability index measuring how well a process fits within its specification limits relative to its variation; higher is better, and values around 1.33 are a common target. Control charts (run charts with control limits) distinguish normal variation from a signal that something changed. See Statistics in Quality (Cpk and Control Charts).

Stability / APR-PQR

Stability programs (ICH Q1A-Q1F) establish shelf life and storage. The Annual Product Review (US) or Product Quality Review (EU, Chapter 1) is the yearly look-back across a product’s batches, deviations, and trends. See Stability Programs (ICH) and Annual Product Review and PQR.


Inspection and audit terms

Form 483 / Warning Letter

An FDA Form 483 is the list of inspectional observations handed over at the end of a US inspection; it is not a final agency finding. A Warning Letter is the more serious follow-up when responses or conditions are inadequate. Knowing the difference signals you understand the escalation ladder. See 483 and Warning Letter Response and FDA Warning Letter Patterns.

Untitled Letter

A step below a Warning Letter on FDA’s advisory-action ladder. It cites violations that do not rise to the level of regulatory significance a Warning Letter requires, and unlike a Warning Letter it does not carry the explicit statement that failure to correct may trigger further enforcement action. It still calls for a written response and a correction plan; treating it as a letter you can quietly file away is a mistake, because an inadequate response can still draw further scrutiny. Confirm current response-window expectations in FDA’s Regulatory Procedures Manual before you cite a specific day count, since advisory-action practice is periodically revised.

Import Alert

A mechanism that lets FDA detain shipments from a specific firm or product line at the US border without physically examining each one, commonly called detention without physical examination. FDA uses it when a pattern of violations, including unresolved data integrity findings, makes the agency unwilling to admit the product on the usual basis. An import alert can follow a Warning Letter when responses or a reinspection do not resolve FDA’s concerns, and for an exporter it can be a bigger commercial problem than the letter itself, because it stops product movement rather than just documenting a finding.

A permanent injunction, negotiated between the company and the Department of Justice acting for FDA and entered by a federal court, that imposes binding, court-enforceable operational requirements, often including independent expert certification before the firm may resume certain operations, until the firm demonstrates sustained compliance. It is the most severe tool on the escalation ladder short of criminal prosecution, and it can keep a facility under court supervision for years.

The FDA escalation ladder, in order of severity:

StageWhat it isBinding?Typical trigger
Form 483Inspectional observations handed over at the end of an inspectionNot itself a final findingInvestigator observes a condition or practice during the inspection
Untitled LetterA lower-severity advisory letter citing violationsNo enforcement statement includedViolations below the significance a Warning Letter requires
Warning LetterFormal notice of significant violations requiring prompt correctionNot itself, but signals enforcement risk if ignoredAn inadequate 483 response, or violations serious enough to skip straight here
Import AlertDetention without physical examination at the US borderYes, operationallyA pattern of violations, including unresolved data integrity, not corrected
Consent DecreeCourt-entered, binding injunction with operational conditionsYes, legally, enforced by a federal courtA Warning Letter and reinspection do not resolve the underlying violations

FDA does not have to move through every rung for every case; a serious enough finding, particularly a data integrity finding with evidence of intent, can jump straight to a Warning Letter or beyond.

CAPA plan / response

The structured reply to an inspection finding, with corrections, root cause, systemic actions, and timelines. See FDA 483 Response Strategy.

Inspection readiness

The ongoing state of being ready for an unannounced inspection: documents retrievable, SOPs current, staff trained to answer. See FDA Inspection Readiness.

Mock inspection / gap assessment

A rehearsal inspection or a structured comparison of current state to requirements, used to find and fix gaps before a real inspector does. See Mock Inspection Program and DI Gap Assessment Methodology.

Supplier / vendor qualification

The assessment that a vendor (including a software supplier) is capable and reliable enough to rely on, often via a documented audit. For software it can reduce your own testing burden under GAMP. See Supplier and Vendor Qualification and Software Supplier Assessment (CSA).


How the same concept is named across regions

The underlying concept is usually the same everywhere; the label and the exact legal mechanism differ by region. Knowing both names for a concept keeps you from assuming a global company’s documents disagree with each other, when they are actually using two correct, regional names for the same idea. For the practical differences in how inspections run day to day, see FDA vs EMA Inspection Dynamics.

ConceptUS / FDA termEU termUK / MHRA termICH / global term
Electronic records and signatures controlPart 11 (21 CFR Part 11)Annex 11 (EudraLex Volume 4)Annex 11 (UK retains the EU GMP annexes post-Brexit)No single ICH equivalent; both anchor to the same control objectives
Narrative data integrity guidanceFDA Data Integrity Guidance (2018)EU GMP Chapter 4 plus national inspectorate guidancesMHRA GxP Data Integrity Guidance and DefinitionsPIC/S PI 041, adopted across PIC/S member authorities
Batch release decision-makerQuality unit signs release; no separate statutory titleQualified Person (QP) certifies under Annex 16Qualified Person (QP), the same concept as the EUNo single ICH title; ICH Q10 describes the process, not a title
Post-inspection observations documentForm 483, a list of observations, not itself a final findingInspection report citing deficiencies, classified by the national inspectorateGMP inspection report classifying deficiencies Critical, Major, or OtherNo harmonized single document; PIC/S promotes mutual recognition of member inspection outcomes
Nonclinical safety study practiceGLP, 21 CFR Part 58GLP, aligned to the OECD GLP PrinciplesGLP, aligned to the OECD GLP PrinciplesOECD GLP Principles, the reference nearly every jurisdiction maps to
Organizational quality frameworkQMS (generic term); QMSR now anchors device QMS to ISO 13485Pharmaceutical Quality System per EU GMPPharmaceutical Quality System, the same as the EUPharmaceutical Quality System (PQS), ICH Q10
Software assurance approachCSA, an FDA guidance formally scoped to device production and quality system software under 820.70(i)No equivalent formal EU guidance; Annex 11 stays the risk-based validation referenceSame position as the EUGAMP 5 (ISPE industry guide), used as the de facto reference regardless of region

A quick map of how the terms connect

If you only carry one mental model into an interview, carry this chain and be ready to narrate it:

  1. You decide a system is GxP and assign its GAMP category and risk.
  2. You write the URS, then FS, then DS, and link them in the RTM.
  3. You verify them through DQ, IQ, OQ, PQ, possibly reusing FAT/SAT and C&Q under ASTM E2500.
  4. You release with a VSR against the Validation Plan, itself under the site VMP.
  5. You keep the system validated with change control, configuration management, access control, audit trail review, backup/DR, and periodic review.
  6. Underneath all of it, every record must satisfy ALCOA+, supported by Part 11 and Annex 11 controls.

Each link in that chain is a question an interviewer can open up. When you can place any single acronym into this flow, you are not reciting definitions, you are showing you understand the system.


Interview questions you should be ready for

“What is the difference between qualification and validation?” Qualification is documented evidence that equipment or a system is installed and operates correctly (DQ/IQ/OQ/PQ). Validation is the broader documented evidence that a process or computerized system consistently delivers its intended result. Qualification is often a building block within a validation.

“Explain ALCOA+ and give a real failure for one attribute.” Recite the nine attributes, then make it concrete: a Contemporaneous failure is recording chromatography results into a logbook the next morning from memory; a Complete failure is deleting a failing injection and reporting only the passing rerun. The interviewer wants a real example, not the acronym.

“What is the difference between static and dynamic records, and why does it matter?” A static record is fixed (a PDF printout); a dynamic record can be reprocessed (a CDS data file). A printout of a dynamic record is not the complete record because you lose the ability to reintegrate and audit. Inspectors require retention of the dynamic original.

“Walk me through CSV vs CSA.” CSV is the documented evidence a computerized system is fit for use. CSA is the FDA guidance for device production and quality system software that shifts effort toward risk-based critical thinking and testing over documentation volume. CSA does not lower the bar for high-risk functions; it stops you over-documenting low-risk ones.

“What goes in an RTM and why do inspectors ask for it?” It links every requirement to its specification and verifying test. Inspectors use it to confirm coverage: no requirement untested, no test untraceable. Gaps in either direction are the kind of thing inspectors regularly cite.

“A CDS audit trail shows aborted runs before a passing result. What do you do?” Treat it as a data integrity signal. Investigate whether the aborted runs were legitimate (an instrument error, a documented trial injection per procedure) or selective reporting. Check the procedure, the rationale recorded at the time, and whether all data was reviewed. Do not assume innocence or guilt; investigate and document.

“How do you keep a system in a validated state after go-live?” Change control with impact assessment, configuration management of the baseline, access reviews, scheduled audit trail review, tested backup and restore, and periodic review. Validation is a state to maintain, not a one-time event.

“What’s the difference between FDA’s CSA guidance and GAMP 5, and does CSA apply to your drug GMP systems?” CSA is an FDA guidance formally scoped to device production and quality system software under 21 CFR 820.70(i). GAMP 5 is an ISPE industry guide used globally as the risk-based method for CSV regardless of which regulation applies. Most drug and biologics programs use CSA’s critical-thinking, risk-based testing principles inside a GAMP 5 framework as a deliberate quality-policy choice, not because CSA itself is an FDA guidance issued under Part 211. Naming that distinction signals you read the actual guidance rather than a summary of it.

“What changed under QMSR, and what happened to the old Part 820 subparts?” QMSR incorporates ISO 13485:2016 by reference as the core device quality system requirement, effective 2 February 2026, with FDA-specific provisions layered on top. Most of the old Part 820 subparts, covering areas like design controls, production and process controls, and records, are removed or reserved because ISO 13485’s clauses now cover that ground; records control specifically moved to the new 820.35.

“Someone tells you a value is ‘data-integrity compliant,’ so it must be correct. What’s wrong with that statement?” Data integrity and data quality are different questions. A record can be fully attributable, contemporaneous, and unaltered, meaning data-integrity compliant, while still being wrong because the underlying measurement or method was imprecise. Compliant record-keeping does not guarantee a correct number; it guarantees that the number you see is the number that was actually generated, unaltered.

“Walk me through FDA’s escalation ladder past the Warning Letter.” A Form 483 lists inspectional observations; an Untitled Letter or Warning Letter can follow if the response or the underlying violations warrant it; an Import Alert can detain product at the US border without physical examination if violations, including unresolved data integrity, are not corrected; a Consent Decree is the court-entered, binding endpoint when a Warning Letter and reinspection do not resolve the underlying problem. FDA can also skip rungs for a sufficiently serious finding.

“How would you validate a system that includes a machine learning model, and what’s different from validating a rules-based system?” You still qualify the infrastructure and verify any deterministic parts the same way, but the model itself needs its performance validated across its real operating range and relevant subgroups, a predetermined change control plan for retraining, and ongoing drift monitoring after go-live, because the model’s behavior is learned from data rather than fixed by code you can trace line by line.


Practical tips

  • When you cite a regulation in an interview or a report, name the document and the specific part. Precision reads as competence.
  • Do not confuse GLP with GMP QC testing. It is a frequent trip-up. GLP is nonclinical safety studies under 21 CFR 58.
  • Keep the URS testable. Most validation pain traces back to vague requirements that cannot be passed or failed.
  • Audit trails are two requirements, not one: the system must capture them, and a human must review them. Inspectors check both.
  • “True copy” means meaning plus metadata preserved, not just a scan; “certified copy” is the UK/EU name for the same underlying control, with a signed confirmation step attached.
  • Do not use “data integrity” and “data quality” interchangeably in a written investigation. They call for different fixes.
  • CSA’s formal scope is device production and quality system software under 820.70(i); say so plainly rather than implying it is an FDA guidance for Part 211 drug systems.
  • An Untitled Letter is not a Warning Letter you can ignore. It still expects a written response and a correction plan.
  • For deeper interview preparation across the whole quality function, work through GxP Quality Interview Preparation.

Use madhadi.com as an app Full screen, works offline, one tap from your home screen.