Matrix: GxP Quality Roles and Sign-Off Authority Across Core Processes

This is a ready-to-use RACI (Responsible, Accountable, Consulted, Informed) matrix for the standing quality processes that run continuously across a GxP organization, not a single project. Unlike a project RACI that closes when the project ends, this matrix is a living reference: the answer to “who is accountable for this class of decision” on any ordinary Tuesday. Replace every <<FILL: ...>> placeholder with your own roles and names. A worked filled specimen follows the template. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This matrix assigns exactly one Accountable role and one or more Responsible, Consulted, and Informed roles to each of the recurring quality-system processes listed below, so that “who owns this decision” has one answer that does not depend on who happens to be asked. It complements, rather than replaces, a project-specific RACI: use the validation project RACI for a single system’s validation effort, and use this matrix for the ongoing decisions the organization makes every week.

2. The four roles, defined

• Responsible (R): does the work or performs the review.
• Accountable (A): owns the outcome and signs for it. Exactly one Accountable role per process row, never zero, never two. If two roles both believe they are Accountable, in practice neither is.
• Consulted (C): gives input before the decision is finalized. Two-way, sought out for expertise or impact.
• Informed (I): told after the decision or the work is complete. One-way, no input expected.

3. How to build this matrix

1. List every recurring quality-system process down the left column. Use the starter list in section 4 and add anything specific to your organization, such as a separate device or combination-product release process.
2. List every function that touches quality decisions across the top. The starter columns below are QA, QC, Manufacturing / Operations, Validation, Regulatory Affairs / QP, and Data Integrity; add or remove columns to match your actual structure.
3. For each cell, assign one letter. Every row must contain exactly one A. If the honest answer is “it depends,” that dependency itself needs to be written down as a rule, not left as a gap.
4. Check that no role is Accountable for a decision it also independently reviews or approves in a way that removes independence: the same person cannot be the sole author of a change and the sole QA approver of that same change.
5. Route the completed matrix through document control and QA approval, and set a periodic review interval so it is checked against reality rather than trusted indefinitely.
6. When an organizational change moves a decision right, update this matrix under change control on the same day the reporting or authority change takes effect; do not let the matrix lag the reality it is supposed to describe.

4. The matrix

5. Acceptance criteria

• Every row has exactly one Accountable entry and at least one Responsible entry.
• QA holds Accountable status, at minimum, on batch disposition, deviation closure, and audit trail exception disposition; these are the decisions the quality unit’s independence exists to protect.
• No role is Accountable for a decision it also solely authors and solely reviews with no second, independent party in the chain.
• The matrix is current with the actual organization; a role listed as Accountable is genuinely the person or function that would answer for that decision in front of an inspector.
• The matrix is reviewed at a defined interval (commonly annual, or on any organizational change) and version-controlled.

6. References

21 CFR 211.22, quality control unit authority to approve or reject. EudraLex Volume 4, Chapter 2, personnel and organization. ICH Q10, Pharmaceutical Quality System, management responsibility and defined roles. FDA Guidance for Industry, Quality Systems Approach to Pharmaceutical CGMP Regulations (2006).

Confirm the current version of each reference before issue.

7. Revision history

8. Approvals

Filled specimen

The following shows the matrix completed for an example mid-size commercial manufacturer, so you can see the level of detail expected. The names and structure are illustrative; replace them with your own.

Reading the “Regulatory submission quality content sign-off” row, RA holds the A and QA appears only as Consulted, which reflects that the submission itself is RA’s deliverable even though the quality data feeding it is QA-controlled; QA’s earlier Accountable role on batch disposition and CAPA is what makes that data trustworthy before it ever reaches RA. When an investigator challenges a complaint disposition, this matrix answers “who decided that” before anyone has to reconstruct it from memory.

Common inspection findings this matrix prevents

• No documented answer to “who is accountable for this class of decision,” producing inconsistent answers from different staff during the same inspection.
• QA present in name on a process but with no real Accountable weight, functioning as an informed bystander rather than the independent decision-maker the regulation requires.
• A change control or CAPA decision made informally by whoever was available, with no role held accountable, discovered only when the same failure recurs.
• Two functions both believing they were Accountable for the same decision, so both under-reviewed it on the assumption the other had it covered.

How to adapt this matrix

1. Set the scope and document number in the header, and confirm this matrix does not duplicate a process-specific RACI you already maintain elsewhere, such as the inspection RACI or the validation project RACI.
2. Add rows for any process specific to your organization: device or combination-product release, clinical supply disposition, or a second-site oversight process.
3. Add or split columns to match your real structure; a global organization may need separate site-level and corporate-level columns for several rows.
4. Assign every cell before this matrix is approved, and revisit it whenever a reporting line or a role changes, using the same trigger events as your signature authority log.