Form: GxP Analytics Tool Risk Classification and Assurance Level

This is a ready-to-use classification record. It is the document that decides how much validation effort a homegrown analytics tool gets, and it is the first thing an assessor reads when asking why a tool was validated lightly. Complete one per tool before development is released for GxP use. Replace every <<FILL: ...>> placeholder with your own specifics and route the completed form through your normal review and approval. A worked classification table and a filled specimen follow. This content is educational reference, not legal or regulatory advice; verify each cited regulation against the current source before you rely on it.

Record control header

Section 1: Tool description

Section 2: The five determining questions

Answer each question with the level that describes the tool as it will actually be used, not as the author intends it to be used. Record the evidence or reasoning for each answer. An answer without a reason is not a classification.

Q1. What GxP decision does the output support?

Reason: <<FILL: name the decision and the document or record where it is taken>>

Q2. Is the output the record of origin, or a view of a record held elsewhere?

Reason: <<FILL>>

A view is not automatically low risk. If a filter, join, or security rule can drop or duplicate rows, the view can misrepresent a correct source. Record here whether the view can change the apparent value: <<FILL: Y/N and how>>

Q3. How complex is the calculation?

Reason: <<FILL: state the calculation and the source method, SOP, or compendial procedure it implements>>

Q4. How much reliance is placed on it, and how often?

Reason: <<FILL: state expected frequency and the number of consumers>>

Q5. Could an undetected error in this tool reach product or patient?

This is the question the FDA Computer Software Assurance framing turns on, and it is the one that overrides the others. Note the scope: that guidance addresses software used in medical device production and in the device quality management system under 21 CFR Part 820, so in a drug GMP setting it is applied here by analogy rather than as a directly binding requirement. Borrowing its risk-based framing across into drug manufacturing is normal and widely accepted practice, but state in your governing SOP that you are doing so, so that the basis is on record.

Reason and named downstream check if E2: <<FILL>>

Section 3: The risk grid

Apply the rules in order. The first rule that matches sets the class.

Additional escalation triggers, any one of which raises the class by one level: the tool reads from a source system that is not validated; the tool writes back to a source system; the output is transcribed by hand into a controlled record; no downstream check on the output exists at all; the tool is the only route by which the value can be produced.

Downgrade requests

A class may be reduced by one level only where a specific, named, independent control makes the risk demonstrably lower, and only with QA approval. A downgrade justified by workload, timeline, or the author’s confidence is not acceptable.

Section 4: Assurance level

The risk class sets the deliverable set. Confirm each deliverable is planned, or record why it does not apply.

Section 5: Rationale statement

Write the rationale in plain sentences that a person who has never seen the tool can follow. State what the tool decides, why the class is what it is, and what specifically would have to go wrong for the classification to be wrong.

<<FILL: rationale, typically 4 to 8 sentences>>

Stated limitations of validity, meaning what the tool is explicitly not approved for:

<<FILL>>

Section 6: Signatures

Section 7: Reclassification history

Worked classification table

Four tools taken through the same five questions. The point of putting them side by side is that the answers, not the technology, decide the outcome: the statistical script and the small spreadsheet both land in class A, while the far larger dashboard lands in class B.

Filled specimen

Completed form for the macro workbook, which is the case that most often gets misclassified downward.

Section 1. A spreadsheet with a macro that takes the viable cell concentration reported by the cell counter and the patient weight recorded on the manufacturing order, and returns the volume in millilitres to be dispensed into the final container to deliver the prescribed dose per kilogram. Written in a spreadsheet application with a signed macro. Author J. Boateng, MSAT Lead; proposed owner J. Boateng. Serves autologous cell therapy manufacturing. Inputs come from MES-03 (validated) for patient weight and from the cell counter export (validated instrument) for concentration. The calculated volume is written by hand into the batch record by the operator and verified by a second operator. Consumed by the manufacturing operator performing the fill.

Section 2.

Section 3. Rule 1 matched on Q5 = E3. Rules 2 and 3 would also have given class A. Escalation trigger present: output is transcribed by hand into a controlled record. Resulting risk class: A. No downgrade requested. A downgrade was discussed and rejected: the proposal was that the second-operator check compensates, but that check reads the same output and therefore is not independent of the calculation.

Section 4. Full assurance, scaled to the size of the tool. Deliverables planned: specification stating the equation and the units of every term; the workbook held as a locked, signed template under version control with the macro source exported to a text file so it can be reviewed by diff; independent code review by the MSAT engineer who did not author it; scripted test protocol including a known-answer dose calculation, the unit boundary, a zero and a negative concentration, and a rounding boundary; release statement; annual periodic review; provenance recorded by template version stamped on the printed output.

Section 5 rationale. This workbook is three lines of arithmetic and it decides how much of a cell therapy product a patient receives. Its size is irrelevant to its risk. The determining answer is Q5: the only downstream check is a second operator reading the same number off the same screen, which detects transcription errors and cannot detect a wrong formula or a wrong unit. Because the workbook is also the sole origin of the value, there is no reconciliation available later. It is therefore class A and gets a specification, an independent review, and a scripted test with a hand-calculated known answer, even though the whole tool fits on one screen. The classification would be wrong only if an independent recomputation of the dose volume were introduced before the fill, by a different tool or by hand from source values; if that control is implemented, resubmit this form for reclassification.

Known-answer case agreed for testing: viable cell concentration 1.25 x 10^7 cells/mL, prescribed dose 2.0 x 10^6 cells/kg, patient weight 70 kg. Required cells = 2.0 x 10^6 x 70 = 1.4 x 10^8. Required volume = 1.4 x 10^8 / 1.25 x 10^7 = 11.2 mL.

Stated limitations. Valid only for the autologous product <<FILL: product code>> and only for dose prescriptions expressed in cells per kilogram. Not valid for flat-dose prescriptions, not valid where the counter reports cells per microlitre, and not valid for patient weights outside 30 kg to 150 kg without reassessment.

Section 6. Owner J. Boateng, signed 26 February 2026. SME reviewer L. Andersen, MSAT Engineer, signed 26 February 2026. Validation lead P. Nwosu, signed 27 February 2026. QA approval T. Marchetti, signed 02 March 2026, with the note that the rejected downgrade rationale is to be cited in the training material for the procedure because it is the error the team is most likely to repeat.

Common inspection findings this form prevents

• A tool feeding a GxP decision was validated lightly, and there is no record of anyone deciding that light was appropriate.
• Risk was assigned by tool size or technology, so every script got the same treatment regardless of what it decided.
• A spreadsheet macro determining a dose or a release result was treated as not software.
• A dashboard was excluded from scope because it only views validated data, with no assessment of whether its filters or joins can change what is shown.
• The classification exists but has no rationale, so it cannot be defended when the assessor asks why.
• An exploratory tool’s output was used in a controlled document because nothing on record said it was non-GxP.
• The classification was never revisited after the tool’s use changed, so the deliverable set no longer matches how the tool is used.
• A risk class was downgraded on the basis of a compensating check that turns out not to be independent of the thing it is supposed to check.

How to adapt this form

1. Map the class labels A, B, C to whatever tier names your quality system already uses, and keep them identical across the inventory register, the specification, the test protocol, and this form.
2. Set the periodic review intervals in section 4 once, in the governing SOP, and reference them here rather than restating them, so they cannot drift apart.
3. If your organization uses a numeric scoring model elsewhere, resist converting these five questions into a score. A score invites arguing about the number instead of the decision, and the override in rule 1 is the whole point.
4. Add a sixth question if your regulatory context needs it, for example whether the output is submitted to a health authority or supports a commitment made in a filing. Keep it as an override rather than a contributing factor.
5. Train on the downgrade section specifically. Inappropriate downgrades routinely cite a compensating control that is not independent of the calculation, exactly as in the specimen, which is why the independence test deserves its own training time.
6. Where a tool is one component in a chain, classify the chain by its output and record the component tools as dependencies rather than classifying each separately at the same rigor.
7. Confirm the current status of every cited reference in the governing SOP before issue, including the FDA Computer Software Assurance guidance, current version issued 3 February 2026, which is scoped to device production and quality management system software under 21 CFR Part 820 and is used here by analogy in a drug GMP context, and the EU GMP Annex 11 revision that was still in draft at the time of writing.