This is a ready-to-use matrix for the step between “the system is in scope” and “score the risk”: deciding which functions are GxP-critical, so FMEA is applied where it matters. Replace every <<FILL: ...>> placeholder with your specifics. A worked filled specimen follows. Drive the function list from the user requirements, not a feature tour of the software.
Document control header
| Field | Entry |
|---|---|
| Matrix title | GxP-Critical Function Identification and Criticality |
| Record number | <<FILL: FORM-ID, e.g. FRM-VAL-021-03>> |
| Parent SOP | <<FILL: SOP-ID for risk-based validation scoping>> |
| System name / ID | <<FILL: SYSTEM NAME / ID>> |
| GAMP category | <<FILL: from the categorization worksheet>> |
| Assessment date | <<FILL: date>> |
| Assessor | <<FILL: name, role>> |
1. Purpose
This matrix identifies the GxP-critical functions of <<FILL: SYSTEM NAME / ID>> and rates each function’s criticality with a one-line rationale, so risk scoring is concentrated on the functions that affect quality, safety, and the record, and low-value functions are not scored at the same depth. It also traces each critical function to a user requirement, which is the thread that ties the assessment to testing.
2. Criticality definitions
A function is GxP-critical when it directly supports or affects: data used for batch release, lot acceptance, or disposition; patient safety; the integrity of a regulated record; or control of a critical quality attribute or critical process parameter.
| Criticality | Meaning | Default handling |
|---|---|---|
| High | Direct impact on a decision, patient safety, or record integrity | Carry to FMEA; expect scripted testing |
| Low | Indirect or presentation-only impact | Light verification or vendor documentation |
| None | No GxP impact (display preference, administrative convenience) | Named and excluded, with a reason |
3. Function criticality matrix
List every function, including the ones you will exclude; naming and justifying out-of-scope functions is part of the record.
| Function | What it does | GxP impact | Criticality | Requirement ID | To FMEA? |
|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL: direct / indirect / none>> | High / Low / None | <<FILL: URS-ID>> | Yes / No |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | ||
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
4. Requirement traceability check
Every GxP-critical function should trace back to a user requirement, and every high-risk requirement should trace forward to a test. Use this check before handoff.
| Check | Result |
|---|---|
| Every High-criticality function has a requirement ID | Yes / No, list gaps |
| Every “critical function” without a requirement is resolved (add requirement or remove function) | Yes / No |
| Out-of-scope functions are named and justified, not silently omitted | Yes / No |
5. Acceptance criteria
- Every function is rated High, Low, or None with a one-line rationale.
- High-criticality functions each trace to a user requirement.
- Out-of-scope and None functions are named and justified.
- The matrix hands a defined set of functions to FMEA; nothing critical is left unscored.
- The record is signed and filed with the risk assessment.
6. Signatures
| Role | Name | Signature | Date |
|---|---|---|---|
| Assessor | <<FILL>> | ||
| System / process owner | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
7. References
ISPE GAMP 5 (Second Edition), for the risk-based, requirements-driven approach. FDA guidance, Computer Software Assurance for Production and Quality Management System Software. 21 CFR Part 11 (electronic records and signatures). EU GMP Annex 11 (computerised systems). ICH Q9(R1), Quality Risk Management.
Confirm the current version of each reference before issue.
Filled specimen
The following shows the matrix completed for an example LIMS. The specifics are illustrative.
| Function | What it does | GxP impact | Criticality | Requirement ID | To FMEA? |
|---|---|---|---|---|---|
| Sample login and assignment | Determines what is tested and when | Direct | High | URS-012 | Yes |
| Result entry and spec comparison | Determines pass/fail and disposition | Direct | High | URS-018 | Yes |
| OOS flagging | Gates the investigation trigger | Direct | High | URS-021 | Yes |
| Electronic signature binding | Record authenticity and attribution | Direct | High | URS-030 | Yes |
| Access control configuration | Determines who can do what | Direct | High | URS-033 | Yes |
| Audit trail capture | Record integrity and traceability | Direct | High | URS-034 | Yes |
| Report template formatting | Presentation of a report | Indirect | Low | URS-041 | No |
| Dashboard configuration | Display preference | None | None | n/a | No |
| Email notification settings | Administrative convenience | None | None | n/a | No |
Requirement traceability check: all six High functions trace to a URS ID; no critical function lacks a requirement; the three excluded functions are named with a reason. Six functions go to FMEA; the rest are handled by light verification or excluded.
In this example, the audit trail and e-signature rows map directly to 21 CFR Part 11 and EU Annex 11 expectations, so they are High regardless of vendor maturity. The dashboard and notification rows are honestly rated None and excluded with a reason, which is what keeps the downstream FMEA focused instead of bloated.
Common findings this matrix prevents
- FMEA run on the entire feature list, so the assessment reads as no real decision was made.
- A high-risk function with no requirement behind it, meaning either the requirement is missing or the function is out of scope.
- Out-of-scope functions silently omitted, so a reviewer cannot tell whether they were considered.
- Audit trail or access control quietly dropped from the critical set despite direct Part 11 and Annex 11 relevance.
How to adapt this matrix
- Set your record number and parent-SOP reference, and carry the GAMP category over from the categorization worksheet.
- Populate the function list from the user requirements specification, not a click-through of the software.
- Hand the “Yes to FMEA” functions to your functional risk assessment (FMEA) template.
- Keep the requirement IDs live; they are the traceability thread an inspector pulls from risk to test.