CSV Interview Questions and Answers: A Preparation Guide
Computer System Validation (CSV) interviews, in pharma, biotech and medical devices, test two things at once: whether you understand the regulations behind the work, and whether you can apply them with judgement to a real system. This guide groups the questions the way interviewers actually move through them — from fundamentals, through the validation lifecycle and the regulations, to scenario questions that probe how you think.
For each question, read the model answer, then practise saying it in your own words with an example from your own experience. Interviewers tell a memorised definition from real understanding in seconds, so the examples matter more than the wording. If you are new to the field, start with the fundamentals below, then what Computer System Validation is and how to become a CSV engineer.
Fundamentals
What is Computer System Validation? It is the documented process of demonstrating that a computerised system does what it is intended to do, consistently and reproducibly, throughout its life, and that it stays in a controlled state. The emphasis is on documented evidence and intended use, not on testing everything a system can do.
Why is CSV needed in regulated industries? Because computerised systems create, process or store data that decisions about product quality and patient safety rely on. Regulators require assurance that this data is trustworthy and that the system behaves predictably. CSV provides that assurance and the evidence to show it during an inspection.
What is the difference between verification and validation? Verification asks “did we build the system right?” against its specifications. Validation asks “did we build the right system?” against the intended use and user needs. A system can pass verification and still fail validation if the requirements did not reflect what the user actually needed.
What does GxP mean? It is shorthand for the family of Good Practice regulations, such as GMP, GLP, GCP and GDP. A system is a GxP system when it supports an activity those regulations govern. Whether a system is GxP, and how critical it is, drives how much validation effort it needs.
What do you mean by intended use? The defined purpose of the system in your specific process, written down before validation. It scopes what must be validated. Two companies running the same software can have different intended uses and therefore different validation scope.
What counts as the computerised system? Not just the software. It includes the application, the operating environment and hardware it runs on, interfaces to other systems and instruments, and the people and procedures (SOPs, training) that operate it. GAMP describes this wider view of the system.
What is the difference between qualification and validation? Qualification usually refers to demonstrating that equipment or infrastructure is installed and operates correctly (for example IQ/OQ/PQ of an instrument). Validation is the broader lifecycle activity for the whole computerised system and its intended use. Qualification activities are often part of the overall validation.
Lifecycle, SDLC and the V-model
Describe the validation lifecycle. It runs from planning (validation plan), through requirements and specification, risk assessment, design, build or configuration, testing (IQ/OQ/PQ), to a validation report and release, then operation and maintenance under change control, and finally retirement. Validation is not a one-off event; it continues for as long as the system is in use.
What is the V-model? A way of showing that each specification on the left side has a matching test on the right. User requirements pair with PQ, functional specifications with OQ, and design or configuration specifications with IQ. It makes the point that you verify against what you specified, at the matching level.
What are URS, FS and DS? The User Requirements Specification states what the user needs the system to do. The Functional Specification states what the system does to meet those needs. The Design (or Configuration) Specification states how it is built or configured. Each lower level must trace back to the one above.
What is a traceability matrix? A table that links each requirement to its specification and to the test that verifies it, and back again. It demonstrates that every requirement is tested and that every test exists for a reason, with no gaps and no orphan tests. Inspectors use it to navigate the package.
What documents make up a validation package? Typically a validation plan, URS, a risk assessment, functional and design/configuration specifications, IQ/OQ/PQ protocols and their executed records, a traceability matrix, any deviations and their resolution, and a validation summary report. The exact set scales with the system’s risk and complexity.
Why is the validation plan written first? It defines scope, approach, responsibilities, deliverables and acceptance criteria before work starts, so the effort is agreed and risk-based rather than decided after the fact. It is the document an inspector often reads first to understand your strategy.
IQ, OQ and PQ
What is DQ? Design Qualification, where used, documents that the proposed design meets the requirements and intended use before build or purchase. It is more common for equipment than for pure software systems.
What is IQ? Installation Qualification verifies that the system is installed correctly in its intended environment: the right software version and build, hardware and operating environment, interfaces, and that installation followed the specification. It answers “is it installed as specified?”
What is OQ? Operational Qualification verifies that the system functions as intended across its operating range: functions work, security and access control behave correctly, the audit trail captures what it should, alarms and limits fire. It answers “does it work as specified?” and is usually where the bulk of functional testing sits.
What is PQ? Performance Qualification verifies that the system performs reliably in the actual process, with real workflows, real users and production-like data, typically against the user requirements. It answers “does it do what we need in routine use?”
Give an example of each for a chromatography data system. IQ: confirm the correct software version is installed on qualified servers and clients, with the instruments connected. OQ: confirm user roles restrict access correctly, the audit trail records method changes, and calculations give expected results on a test data set. PQ: run a representative method end to end with trained users and confirm the workflow and reporting meet the requirements.
Who executes these protocols? Trained personnel following the approved protocol, with results reviewed and approved, commonly with Quality oversight. The key point is that execution is contemporaneous, documented, and any deviation is recorded and assessed rather than quietly fixed.
GAMP 5 and software categories
What is GAMP 5? GAMP 5 is ISPE’s guide “A Risk-Based Approach to Compliant GxP Computerized Systems”, now in its second edition. It is guidance, not a regulation, but it is the widely accepted framework for how to validate computerised systems in a scalable, risk-based way. Interviewers expect you to know it is risk-based and lifecycle-based.
What are the GAMP software categories? Category 1 is infrastructure software (operating systems, databases). Category 3 is non-configured products used as supplied. Category 4 is configured products. Category 5 is custom or bespoke software. (There is no longer a separate category 2.) The category reflects how much of the system is standard versus built for you.
How does the category affect validation effort? The more a system is configured or custom (moving toward Category 5), the more it carries your own requirements and the more you must specify and test yourself. A standard Category 3 product can lean more on the supplier’s testing and your own risk-based verification of intended use. Effort scales with risk and novelty, not with a fixed checklist.
What does “risk-based and scalable” mean in practice? You do not validate every system to the same depth. You focus effort where failure would most affect product quality, data integrity or patient safety, and apply lighter controls where risk is low. The validation of a simple Category 3 tool should look very different from a custom Category 5 system.
What does the GAMP 5 second edition emphasise? It reinforces critical thinking, leveraging supplier activities, and fitting the approach to modern methods and service models rather than producing documents for their own sake. Showing you understand critical thinking — applying judgement rather than following a template blindly — signals maturity to an interviewer.
Risk management
What is a risk-based approach to validation? Matching the amount of validation effort and control to the risk a system poses to product quality, data integrity and patient safety. High-risk functions get more rigour; low-risk functions get proportionately less. It avoids both under-validating critical systems and over-documenting trivial ones.
How do you carry out a risk assessment for a system? Identify the GxP functions and the risks to each (what could go wrong, how likely, how it would be detected), then rate and prioritise them, decide controls or tests that reduce the significant risks, and document the rationale. The assessment then drives test depth and the controls you put in place.
Which guidance underpins quality risk management? ICH Q9 (Quality Risk Management) is the usual reference for the principles. The key idea is that risk is assessed on impact and probability (and often detectability), and that decisions are documented and justified.
How does risk drive how much you test? A function whose failure would corrupt GxP data or harm a patient is tested thoroughly, including negative and boundary cases. A low-impact, standard function may need only a light confirmation. The traceability from risk to the depth of testing is what you should be able to show and explain.
Data integrity and ALCOA+
What is data integrity? The assurance that data is complete, consistent and accurate throughout its lifecycle, and that you can trust it reflects what actually happened. It covers how data is created, recorded, processed, stored, retrieved and eventually archived or destroyed.
What is ALCOA? The core principles data should meet: Attributable (who did it and when), Legible (readable and permanent), Contemporaneous (recorded at the time), Original (the first record or a true copy), and Accurate (correct and reflecting reality).
What does the ”+” add in ALCOA+? Four further expectations: Complete, Consistent, Enduring and Available. Together they extend the principles across the whole data lifecycle, including that records remain retrievable and readable for as long as they are needed.
Give examples of data integrity breaches. Sharing login accounts so actions are not attributable; turning off or not reviewing the audit trail; testing “into compliance” by reprocessing until a result passes and keeping only the passing one; recording results on scrap paper and transcribing later (not contemporaneous or original); changing the system clock.
What is the difference between static and dynamic data? Static data is a fixed record, such as a printout or PDF. Dynamic data can be interacted with and reprocessed, such as a chromatogram you can re-integrate. Dynamic data usually needs to be kept in a form that preserves that ability, which affects how you store and migrate it.
21 CFR Part 11 and EU Annex 11
What is 21 CFR Part 11? The US FDA regulation on electronic records and electronic signatures, in force since 1997. It sets the conditions under which the FDA treats electronic records and signatures as trustworthy and equivalent to paper and handwritten signatures: validation, audit trails, access controls, and specific controls around electronic signatures.
What is EU GMP Annex 11? The EU GMP guidance on computerised systems, part of EudraLex Volume 4. It takes a broader, lifecycle view of the whole system, covering risk management, suppliers, validation, data, security and periodic review. It is guidance rather than a standalone statute, but it is the operative inspection expectation in the EU. (A draft revision was published for consultation in 2025.)
What is the main difference between them? Part 11 is narrowly focused on electronic records and electronic signatures and is highly specific. Annex 11 is broader and more lifecycle-oriented, and places more explicit weight on topics such as supplier oversight and periodic review. Complying with one does not automatically satisfy the other.
What is the difference between an electronic record and an electronic signature? An electronic record is any data created, modified, stored or retrieved electronically. An electronic signature is the electronic equivalent of a handwritten signature, linked to a record so it cannot be transferred, and carrying the signer’s name, the date and time, and the meaning of the signing.
What are open and closed systems under Part 11? In a closed system, access is controlled by the people responsible for the records. In an open system, it is not (for example records passing through third-party infrastructure), so additional controls such as encryption may be needed. The distinction changes what controls you must apply.
What is a signature manifestation? The requirement that a signed electronic record clearly shows the printed name of the signer, the date and time, and the meaning of the signature (such as review or approval). A signature is more than a click.
Audit trails
What is an audit trail? A secure, computer-generated, time-stamped record of actions that create, modify or delete data. It lets you reconstruct what happened to a record: who did what, when, and ideally why for a change. It is a cornerstone of data integrity.
What should an audit trail capture? At minimum the original value and the new value, who made the change, the date and time, and, for changes, the reason. It should be secure against alteration, enabled and not switchable off by ordinary users, and retained for as long as the underlying record.
What is audit trail review? The routine, documented review of audit trail entries to catch unauthorised or suspicious changes, done at a frequency and scope driven by risk, typically as part of reviewing the associated records. Having an audit trail is not enough; regulators expect evidence that it is reviewed.
Why do audit trails matter so much in inspections? Because they are where data integrity problems surface: changes made and not explained, the trail disabled, or results altered after the fact. An inspector checks that the trail exists, is secure, captures the right information, and is actually being reviewed.
Testing and Computer Software Assurance (CSA)
What kinds of testing are used in CSV? Installation checks, functional testing, and tests of security, audit trail, calculations, interfaces and recovery (backup and restore). Depending on the system you may also see data migration verification and interface testing between systems.
What is the difference between positive and negative testing? Positive testing confirms the system does what it should with valid input. Negative testing confirms it handles invalid input correctly, such as rejecting a bad value, enforcing a permission, or failing safely. Critical functions usually need both.
What makes a good test script? Clear, unambiguous instructions; an objective, pre-defined expected result; the evidence to be captured stated up front; and acceptance criteria that are measurable, not “works as expected”. A tester who has never seen the system should be able to execute it and get a repeatable outcome.
What is Computer Software Assurance (CSA)? A risk-based approach the FDA set out in draft guidance for production and quality-system software, emphasising critical thinking and focusing effort (and testing) on what matters to patient safety and product quality, rather than producing documentation for its own sake. It is an evolution of CSV thinking in the same risk-based direction as GAMP 5, not a different rulebook.
How can you reduce testing effort without cutting corners? By leveraging supplier documentation and testing where it is reliable and assessed, reusing evidence instead of re-testing standard functionality, and concentrating your own testing on configuration, intended use and high-risk functions. The justification for what you rely on must be documented.
Scenario and behavioural questions
These check judgement. The interviewer wants your reasoning, not a textbook line. A good answer names the right action, the reason behind it, and who you involve.
A test fails during execution. What do you do? You do not quietly fix and re-run. You record the result as it happened, raise a deviation, investigate the cause (test error, environment, or a real system defect), decide and document the resolution with Quality, and only re-test under a controlled, approved route. A failure is evidence, not something to erase.
You find a system that has been in GxP use but was never validated. How do you handle it? Assess and document the risk and the gap first, put interim controls in place if the risk warrants, inform Quality, and plan a retrospective validation based on risk and available evidence. You do not keep quiet and you do not stop its use without assessing the impact of doing so.
You discover a data integrity issue, for example a shared login. What is your response? Treat it seriously: contain it, assess the impact on affected data and decisions, escalate to Quality, and address the root cause (individual accounts, training, access controls), with it all documented. Showing you escalate rather than hide is the point of the question.
How do you work with QA and with software vendors? With QA, early and openly: agree the approach and acceptance criteria up front and keep them involved in deviations and release. With vendors, you assess what they provide (audit or qualification of the supplier), leverage their testing where justified, but keep accountability for intended use with you. Collaboration, with ownership retained.
How do you keep your knowledge current? Name concrete sources: the regulations and guidance themselves (Annex 11, Part 11, GAMP, ICH), industry bodies such as ISPE, and following how inspectors’ expectations evolve. This shows you treat the field as moving, not fixed.
How to prepare
- Be able to explain every answer in your own words with one real example from your experience. One concrete story beats five definitions.
- Know the difference pairs cold: verification vs validation, qualification vs validation, IQ vs OQ vs PQ, Part 11 vs Annex 11, positive vs negative testing, static vs dynamic data.
- Expect a data-integrity question and an audit-trail question in almost every interview; have an ALCOA+ example ready.
- For scenario questions, always show the same shape: record it, assess the risk, involve Quality, fix the root cause, document it.
- Read the actual job advert and map your examples to the systems it names (MES, LIMS, CDS, ERP). Tailor, don’t recite.
Work through these out loud until the answers feel like yours. The candidates who stand out are the ones who clearly understand why each control exists, not just what it is.