This is a ready-to-use, function-by-function matrix that turns the CSA reliance decision into a documented, auditable record instead of an informal judgment call. For every function in scope, it asks the same three questions in order and records the resulting test decision, so an inspector challenging a “we relied on vendor testing” position can see exactly which functions that applies to and why. Replace every <<FILL: ...>> placeholder with your own specifics. A worked specimen follows.
Document control header
| Field | Entry |
|---|---|
| System | <<FILL: SYSTEM NAME, version>> |
| GAMP category | <<FILL>> |
| Linked supplier assessment report | <<FILL: report number>> |
| Owner | <<FILL: Validation / CSV lead>> |
| Effective date | <<FILL>> |
1. Purpose
Record, function by function, the reliance decision for <<FILL: SYSTEM NAME>>: what is accepted on supplier evidence, what receives a focused confirmation, and what is fully tested by us, so the resulting test strategy is traceable to a documented rationale rather than an unstated assumption.
2. Decision logic
For each function, answer in order:
- Did the supplier test this function, and is the evidence credible? (Seen during the assessment, or a credible sample reviewed, from an SDLC judged sound.)
- Is the function GxP-critical or data-integrity-critical for our specific use?
- Did we configure or extend this function beyond delivered, default behavior?
Resolve to one of three outcomes:
| Outcome | When it applies |
|---|---|
| Accept + verify install | Supplier tested credibly, not GxP/DI-critical for us, used as delivered |
| Focused confirm | Supplier tested credibly, but GxP/DI-critical for us, so we confirm independently with targeted (not necessarily full-script) testing, even without configuration |
| Full scripted test | We configured or extended it, regardless of supplier testing, or supplier evidence was not credible/available |
3. Function-level decision matrix
| Function | Supplier tested credibly? | GxP/DI critical for us? | We configured/extended it? | Outcome | Rationale |
|---|---|---|---|---|---|
<<FILL>> | <<FILL: Yes/No>> | <<FILL: Yes/No>> | <<FILL: Yes/No>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
4. Reliance statement (roll-up)
<<FILL: one paragraph summarizing, in plain terms, which functions are accepted on supplier evidence and which are tested internally, referencing this matrix by document number. This paragraph is the sentence an inspector reads.>>
5. Acceptance criteria
- Every function named in the system’s intended-use and requirements documents has a row; none are omitted.
- Every “Accept” or “Focused confirm” outcome cites specific supplier evidence reviewed (a record name, a report reference), not a general impression.
- Every configured or extended function resolves to full scripted test regardless of supplier testing.
- The reliance statement in section 4 is consistent with every row’s outcome; a spot check should not find a contradiction.
- The matrix is re-reviewed on any change to the assessed version, per change control.
6. References
FDA final guidance, Computer Software Assurance for Production and Quality Management System Software (current version issued 3 February 2026). GAMP 5 Second Edition, key concept of supplier involvement and reliance. ICH Q9(R1), Quality Risk Management.
Confirm the current version and title of the CSA guidance against the source before issue.
7. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL>> | Initial matrix. |
8. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Validation / CSV lead | <<FILL>> | ||
| Subject matter expert (software-literate) | <<FILL>> | ||
| QA | <<FILL>> |
Filled specimen
The following reproduces the worked LIMS example from the parent article. System: configured LIMS, GAMP Category 4, high GxP and DI impact overall.
| Function | Supplier tested credibly? | GxP/DI critical? | Configured/extended? | Outcome | Rationale |
|---|---|---|---|---|---|
| Core login / access control | Yes, evidence seen in remote audit | High (DI) | No | Focused confirm | Standard delivered function with credible supplier evidence, but access control is DI-critical for us, so we independently confirm our role assignments work as intended |
| Standard sample login screen | Yes | Medium | No, used as delivered | Accept + verify install | Not DI-critical beyond standard controls; supplier test report SA-2026-0031 Section 4 reviewed |
| Custom result calculation (site-specific formula) | No, supplier never saw our formula | High | Yes | Full scripted test | We configured this; supplier testing cannot cover logic they never had |
| Audit trail capture | Yes | High (DI) | No | Focused confirm | Delivered capability with credible evidence, but DI-critical, so we confirm it captures our specific critical actions (result edits, re-integrations) |
| Custom CoA report template | No | High | Yes | Full scripted test | Our template, our layout logic, never tested by supplier |
| Built-in unit conversion library | Yes | Low | No | Accept + verify install | Standard, low-criticality, credible supplier evidence, sample-checked at install |
Section 4 reliance statement: “We rely on the supplier’s release testing (report SA-2026-0031) for standard, delivered functions used without configuration (sample login, unit conversion). Access control and audit trail capture are delivered functions with credible supplier evidence, but as data-integrity-critical functions for our use, we independently confirm them with focused testing rather than accepting supplier testing alone. Our configured result calculation and custom CoA template were never tested by the supplier and receive full scripted testing by us.”
Common inspection findings this matrix prevents
- A blanket “we relied on vendor testing” claim with no function-by-function record showing which functions that actually covers.
- A configured or custom function accepted on generic supplier testing that never touched the site-specific logic.
- A DI-critical delivered function accepted with no independent confirmation at all, on the assumption that “supplier tested it” is sufficient regardless of criticality.
- A reliance statement that does not match the underlying function-level decisions when an inspector spot-checks it.
How to adapt this matrix
- Pull the function list from the system’s requirements or intended-use document, not from a generic template list; the functions must match what this specific system actually does.
- Answer question 1 (credible supplier evidence) only from evidence actually reviewed during the supplier assessment; do not infer credibility from the vendor’s reputation alone.
- Route every “Full scripted test” row into your test plan and confirm it is actually scripted, not dropped.
- Re-run this matrix, at least for affected functions, whenever the assessed version changes or a vendor release notifies a change to a function’s behavior.