Five steps
- Identify the function. State the activity, calculation, control or record being relied on.
- Ask what can go wrong. Describe a realistic failure.
- Determine impact. Follow the failure to patient safety, product quality, data integrity or a regulated process or record.
- Consider existing controls. Explain what prevents or detects the error, and what evidence shows the control works.
- Determine testing. Choose activities that challenge the failure and resolve remaining uncertainty.
Two functions, different evidence
Worked exampleFictional examples. A control description alone does not demonstrate its effectiveness.
| Function | Failure | Impact | Existing control | Testing |
|---|---|---|---|---|
| Calculate release result | Incorrect calculation | Product may be incorrectly accepted | Formula locked | Scripted challenge testing of formulas, limits and incorrect inputs |
| Dashboard color | Wrong color displayed | No GxP decision depends on the color | Underlying data remains visible | Exploratory testing of display and use |
A locked formula reduces unauthorized changes; it does not prove the formula is correct. If the display color becomes a release signal, reassess its impact.
Record the reasoning
Keep the function, failure, impact, control, evidence and testing decision together. An unexplained numerical score is not a substitute for that reasoning.
Detailed practice, examples and references
A GxP function is a bounded use that you can describe, assess, and support with evidence. It is an assessment aid, not necessarily a screen, module, or microservice.
A training platform might have separate units for training assignment, completion approval, and operator eligibility. Split these uses because their failure consequences and evidence differ. Keep dependencies visible: eligibility still depends on completion data and role mapping.
How to apply it
Describe the activity and decision. Identify its inputs, outputs, actors, and interfaces. State the failure that matters. Identify shared dependencies. Link controls and evidence. Explain the conclusion within that boundary.
Do not split a system so finely that you lose the end-to-end process. A perfectly tested field does not prove that the correct record reaches the correct downstream decision.
Worked example
Completed example — fictional
| Field | Example |
|---|---|
| GxP function | F-03: operator eligibility for OP-21 |
| Intended use | Prevent task start unless required training is current |
| Inputs | Operator ID, role requirements, completion records, effective dates |
| Output | Eligible/ineligible response with transaction identity |
| Failure | Expired training produces eligible response |
| Dependencies | Identity mapping, time configuration, training records, MES handling |
| Evidence | Expiry boundary, role mapping, timeout, interface and override tests |
| Limit | Does not establish practical competency beyond the training process |
Contrasting uses
An overdue-training dashboard may be a separate unit if it serves a distinct review process. An AI summary and an AI-executed workflow action should normally be examined separately because the action introduces permissions and consequences beyond the text.
Reusable worksheet
Write: function name; process decision; users; inputs and provenance; outputs and consumers; boundaries; failure; controls; dependencies; evidence; unresolved uncertainty; authorized conclusion; reassessment criterion.
Exercise: Should a LIMS–ERP transfer be divided into “send” and “receive” and then assessed independently?
Answer: Component assessments can help, but retain an end-to-end function view or explicit integration evidence. Otherwise, both sides can pass while using different units or meanings.
Practitioner guidance by Sandip Thorat · Simplified 17 September 2026. Apply the requirements and approved procedures relevant to your system. Report a correction.
Questions and discussion
Ask a question or share a perspective. Contributions are reviewed before publication.
Loading contribution options…