This is a ready-to-use form for the first decision in any validation program: is the system GxP at all, and if so, what part of it is in scope. Replace every <<FILL: ...>> placeholder with your specifics. A worked filled specimen follows. This determination is the input to a full risk assessment; see the article this serves for the method that follows.
Document control header
| Field | Entry |
|---|---|
| Form title | GxP Applicability (System Determination) Assessment |
| Form / record number | <<FILL: FORM-ID, e.g. FRM-VAL-021-01>> |
| Parent SOP | <<FILL: SOP-ID for risk-based validation scoping>> |
| System name / ID | <<FILL: SYSTEM NAME / ID>> |
| Assessment date | <<FILL: date>> |
| Assessor | <<FILL: name, role>> |
1. Purpose
This form records whether <<FILL: SYSTEM NAME / ID>> is a GxP computerized system and, if it is, the boundary of what is in scope for validation. A clear scoping decision, signed by the system owner and Quality, settles the question and gives an inspector a one-page answer. It prevents both validating software that had no business in the program and leaving a genuinely regulated system unvalidated.
2. System summary
| Field | Entry |
|---|---|
| Business purpose | <<FILL: what the system is used for>> |
| Users / departments | <<FILL>> |
| Data created / stored / processed | <<FILL>> |
| Interfaces to other systems | <<FILL: list, or None>> |
| Hosting | <<FILL: on-premise / vendor-hosted / SaaS>> |
3. The four determining questions
Answer each with the basis, not just yes or no. A single yes puts the system in scope.
| # | Question | Answer | Basis |
|---|---|---|---|
| 1 | Does the system create, store, process, or transmit data used to make a GxP decision (release, in-process, disposition, clinical endpoint, lot acceptance)? | Yes / No | <<FILL>> |
| 2 | Does it control or monitor a process that directly affects product quality or patient safety? | Yes / No | <<FILL>> |
| 3 | Does it generate records required by FDA, EMA, MHRA, or another authority, including records producible in an inspection? | Yes / No | <<FILL>> |
| 4 | Is it referenced in a regulatory submission or relied on for a submission’s data? | Yes / No / Indirect | <<FILL>> |
4. Decision rule
- If every answer is No: the system is not GxP. Record the rationale and stop. No pharmaceutical validation is required. It may still need general IT controls, security, and business continuity, which are outside this determination.
- If any answer is Yes (or Indirect for question 4 with a Yes elsewhere): the system is in scope. Continue to section 5 to set the boundary.
5. In-scope boundary (extent of use)
A blanket “in scope” forces the team to validate modules nobody uses for GxP work. State the boundary explicitly.
| Module / function area | In scope for GxP? | Reason |
|---|---|---|
<<FILL: module A>> | Yes / No | <<FILL>> |
<<FILL: module B>> | Yes / No | <<FILL>> |
<<FILL: module C>> | Yes / No | <<FILL>> |
6. Determination
| Field | Entry |
|---|---|
| GxP determination | In scope / Not GxP |
| In-scope boundary summary | <<FILL: one-line summary of what is and is not in scope>> |
| Provisional GAMP category (if known) | <<FILL: 1 / 3 / 4 / 5 / TBD>> |
| Next step | <<FILL: proceed to risk assessment / no further action>> |
7. Acceptance criteria
- All four questions answered with a basis, not a bare yes/no.
- The decision rule is applied consistently with the answers given.
- For an in-scope system, the boundary names which modules are and are not GxP.
- A “not GxP” determination carries a rationale a reviewer can agree with.
- The record is signed by the system owner and Quality.
8. Signatures
| Role | Name | Signature | Date |
|---|---|---|---|
| Assessor | <<FILL>> | ||
| System owner | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
9. References
21 CFR Part 11 (electronic records and signatures). EU GMP Annex 11 (computerised systems). ISPE GAMP 5 (Second Edition), for the risk-based approach and system categorization. ICH Q9(R1), Quality Risk Management.
Confirm the current version of each reference before issue.
Filled specimen
The following shows the form completed for an example expense-and-approval tool that a validation team was asked to validate, and for a chromatography data system. The specifics are illustrative.
Example A, not GxP: expense reporting tool
| # | Question | Answer | Basis |
|---|---|---|---|
| 1 | GxP-decision data? | No | Records travel and expense claims only, no product or trial data |
| 2 | Controls a quality-critical process? | No | No process control |
| 3 | Generates regulated records? | No | Financial records, not FDA/EMA-required GxP records |
| 4 | Referenced in a submission? | No | Not linked to any submission |
Determination: Not GxP. Rationale: no answer to the four questions is yes; the tool handles finance data with no product-quality, patient-safety, or regulated-record role. No pharmaceutical validation required; standard IT and finance controls apply. Signed by the system owner and QA. An inspector who asks “why did you not validate this?” gets a one-page answer.
Example B, in scope: chromatography data system (CDS)
| # | Question | Answer | Basis |
|---|---|---|---|
| 1 | GxP-decision data? | Yes | Acquires and processes assay results used for batch release |
| 2 | Controls a quality-critical process? | Partly | Controls the HPLC acquisition sequence |
| 3 | Generates regulated records? | Yes | Chromatograms, audit trail, e-signatures under Part 11 |
| 4 | Referenced in a submission? | Indirect | Release and stability results feed filings |
Determination: In scope. Boundary: acquisition, integration, results, audit trail, e-signature, and user management in scope; the instrument-maintenance-scheduling module out of scope (administrative only). Provisional GAMP category 4 with a custom reporting calculation flagged as Category 5. Next step: full risk assessment.
Common findings this form prevents
- A validation package produced for software that carried no GxP risk, because no one asked the four questions first.
- A genuinely regulated system left unvalidated because “IT owns it,” with no determination on file.
- A blanket “in scope” with no boundary, forcing validation of modules nobody uses for GxP work.
- A “not GxP” call with no rationale, indistinguishable from an oversight.
How to adapt this form
- Set your form number and point the parent-SOP field at your risk-based validation scoping procedure.
- Keep the four questions verbatim; they map to the standard GxP definition and are what an inspector expects.
- Add rows to section 5 for each module of large enterprise platforms.
- Route completed forms into your validated-system inventory so the determination is retrievable.