This is a ready-to-use record for the moment a RACI does not resolve itself: the data owner and the data steward, or the owner and the custodian, reach different conclusions about the same fact and someone has to decide. An undocumented resolution, whoever was more senior or pushed harder in a hallway conversation, is its own inspection finding. This form makes the disagreement, the escalation path followed, and the final decision and its rationale a traceable record. Replace every <<FILL: ...>> placeholder. A filled specimen follows.
Why this form exists
A data governance RACI assigns exactly one Accountable name per activity, but accountability is not the same as being right every time, and a steward’s independent judgment is worth little if it is quietly overridden with no record of why. This form exists so a disagreement resolves through a visible, timeboxed path rather than informally, and so a pattern of recurring disagreements is visible to the governance board instead of buried in a series of one-off conversations nobody wrote down.
Section 1: the disagreement
| Field | Entry |
|---|---|
| Data set / system | <<FILL>> |
| Date the disagreement was identified | <<FILL>> |
| Raised by | <<FILL: name, role, typically the steward>> |
| Type of disagreement | <<FILL: access grant / audit trail exception classification / data criticality tier / retention or disposition / change control or revalidation trigger / other>> |
Section 2: both positions
Record both positions before any resolution attempt. A record that starts from the outcome and works backward is not a real escalation record.
| Party | Position and rationale |
|---|---|
| Data owner | <<FILL: what the owner wants to do and why>> |
| Data steward (or custodian, if the disagreement is owner/custodian) | <<FILL: the specific concern, stated in enough detail that someone who was not in the room can evaluate it>> |
Section 3: direct resolution attempt
| Field | Entry |
|---|---|
| Direct resolution window (start / end) | <<FILL: e.g. 1 to 3 working days>> |
| Resolved directly? | <<FILL: Yes / No>> |
| If resolved directly, outcome and rationale | <<FILL, or "escalated, see Section 4">> |
Section 4: escalation
Complete this section only if Section 3 did not resolve the disagreement.
| Field | Entry |
|---|---|
| Escalated to | <<FILL: QA, and governance board if cross-functional or recurring>> |
| Date escalated | <<FILL>> |
| Does the disagreement touch a control QA holds independent authority over (segregation of duties, audit trail exception handling, a data integrity deviation classification)? | <<FILL: Yes / No>> |
| If Yes, QA’s decision governs regardless of the owner’s preference | <<FILL: confirm>> |
| If No, the owner’s accountability governs once the steward’s concern is heard and recorded | <<FILL: confirm>> |
Section 5: decision
| Field | Entry |
|---|---|
| Decision | <<FILL>> |
| Rationale | <<FILL: reference both positions from Section 2 and explain why the decision resolves the disagreement>> |
| Compensating or alternate control, if any | <<FILL: e.g. an alternate workaround that addresses the steward's concern without granting the disputed request as originally framed>> |
| Decided by | <<FILL: name, role>> |
| Date decided | <<FILL>> |
Section 6: action and closure
| Field | Entry |
|---|---|
| Action arising from the decision | <<FILL>> |
| Owner of the action | <<FILL>> |
| Target closure date | <<FILL>> |
| Closure confirmed (name, date) | <<FILL>> |
| Reviewed at governance board (date, if applicable) | <<FILL>> |
Section 7: signatures
| Party | Name | Signature | Date |
|---|---|---|---|
| Data owner | <<FILL>> | ||
| Data steward | <<FILL>> | ||
| QA (decision authority, where applicable) | <<FILL>> |
Acceptance criteria for this form
- Both positions are recorded in Section 2 before the resolution attempt, not reconstructed afterward to match the outcome.
- The direct resolution window is timeboxed and its outcome (resolved or escalated) is explicit.
- Where the disagreement touches a segregation-of-duties or audit-trail-integrity control, QA’s decision is recorded as governing, not deferred to the owner.
- The decision carries a stated rationale referencing both positions, not just a conclusion.
- The arising action has a named owner and a target date, and closure is confirmed rather than assumed.
- A pattern of recurring escalations on the same system or the same type of disagreement is flagged to the governance board rather than treated as a series of unrelated one-off events.
References
PIC/S PI 041-1, “Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments” (2021), on defined responsibilities and an escalation path within the data governance system. FDA guidance, “Data Integrity and Compliance With Drug CGMP: Questions and Answers” (December 2018), on the quality unit’s independent authority. 21 CFR 211.22, on the quality control unit’s authority and responsibility. EU GMP Annex 11, on segregation of duties and access control.
Confirm the current version of each reference before you rely on it.
Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
Filled specimen
Illustrative example. The company, names, and system are invented.
| Field | Entry |
|---|---|
| Data set / system | MES electronic batch records, oral solid dosage line |
| Date identified | 14 September 2026 |
| Raised by | T. Ibrahim, MES super-user (steward) |
| Type of disagreement | Access grant |
Section 2, both positions:
| Party | Position and rationale |
|---|---|
| Data owner | D. Ferreira, Head of Manufacturing: wants to grant operator K. Wallace elevated MES access, including batch record approval, to cover an absent line supervisor for the remainder of the week; production schedule is tight and a qualified backup supervisor is not immediately available. |
| Data steward | T. Ibrahim: the requested access would let the same operator both execute and approve their own batch record entries for the shift, a segregation-of-duties breach; recommends an alternate workaround instead of the grant as requested. |
Section 3: direct resolution window 15 to 16 September 2026, not resolved directly.
Section 4: escalated to QA on 16 September 2026. The disagreement touches segregation of duties, a control QA holds independent authority over. QA’s decision governs.
Section 5: decision, QA (R. Gomez): access denied as originally requested. Alternate control: a qualified approver from the adjacent line covers the batch record approval step for the affected shift for the remainder of the week, with the arrangement documented and time-limited. Rationale: the production-schedule pressure is real but does not override the segregation-of-duties requirement; the alternate control addresses the operational gap without creating an undetectable approval conflict.
Section 6: action, document and communicate the temporary cross-line approval arrangement to both shifts, owner T. Ibrahim, closed 17 September 2026. Reviewed at the October governance board meeting alongside one other access-related escalation from the same quarter, flagged as a pattern worth addressing with a standing backup-approver list.
Common inspection findings this form prevents
- A disagreement between the owner and the steward resolved informally, with no record of either position or the reasoning behind the final decision.
- A segregation-of-duties concern raised by a steward and overridden by an owner under schedule pressure, with QA’s independent authority never actually invoked despite existing on paper.
- An access grant made under a “temporary” justification that is never time-limited, reviewed, or closed.
- Repeated disagreements on the same system that nobody notices form a pattern, because each one was handled as an isolated conversation instead of a logged, reviewable record.
How to adapt this form
- Route this form through whatever document control or quality-event system already handles similar records at your site; it does not need a separate numbering scheme if a comparable log already exists.
- Make clear to every steward, at onboarding, that raising a documented disagreement on this form is expected practice, not an escalation that will be held against them; a steward who stays silent to avoid friction is a control that has quietly stopped working.
- Review closed records at the governance board on a defined cadence, watching for a pattern by system, by disagreement type, or by owner, not just clearing the individual record.
- Where QA’s independent authority applies, confirm the decision was actually made by QA and not merely attributed to QA after the fact.