RACI & SOW Boundaries: Who Does What, When, and Why

Why this matters

Ambiguity costs time. In clinical studies it also risks protocol deviations, blinding breaks, and missed lock dates. A clear RACI and a precise SOW make ownership visible so issues land with the right owner on the first attempt—not after three emails and a steering‑committee detour.

RACI sets who decides and who does; the SOW sets what is delivered, by whom, to what standard, and how fast. Together they prevent “everyone thought someone else had it” problems.

Core concepts & definitions

• RACI — A simple roles grid for each activity/decision:

  • Responsible (R): does the work.
  • Accountable (A): the single owner who makes/approves the decision and is answerable for outcomes (exactly one A per decision/deliverable).
  • Consulted (C): provides input before the decision (two‑way).
  • Informed (I): kept updated after the decision (one‑way).

• SOW (Statement of Work, also called scope of work): The contract document (usually under a master services agreement) that fixes scope, deliverables and how many of each are priced (e.g., number of transfers, interim locks, listings), SLAs (service‑level agreements: targets like turnaround time), acceptance criteria, escalation paths, and change control for CROs/vendors. Work beyond the contracted scope or counts needs a signed change order before it starts. File layouts and variables belong in the data transfer agreement or specification that the SOW references. The sponsor stays ultimately responsible for transferred work and oversees the vendor.

• Decision rights: Who approves changes (e.g., CRF forms, edit‑checks/rules, coding conventions/dictionaries, reconciliation cadence), who can unblind (in an emergency, the investigator may unblind one participant as the protocol allows, documents it and informs the sponsor promptly), who signs at database lock.

• Common terms:

  • CRF (Case Report Form): eCRF pages used by sites to capture data.
  • DMP (Data Management Plan): How data will be collected, cleaned, reconciled, reported.
  • DVP (Data Validation Plan): Detailed edit checks and derivations.
  • CRO: Contract Research Organization (outsourced execution).
  • DM, Biostats, ClinOps, PV, QA, PM: Data Management, Biostatistics, Clinical Operations, Pharmacovigilance (drug safety), Quality Assurance, project manager (e.g., CRO PM, Vendor PM).
  • CCG / CCB: Change Control Group/Board—the forum that reviews study changes and records each approval; the approval is signed by the single A for that RACI row, so the board itself is never the A.
  • Blinded vs unblinded roles: Separate teams to protect masking (e.g., unblinded statisticians vs blinded DM/ClinOps).

Build the RACI & SOW, step‑by‑step

1. List study decisions & deliverables Create a one‑line inventory covering the full data lifecycle. Typical lines:

   • CRF/eCRF design and amendments
   • Edit checks/derivations (DVP) and deployments
   • Coding approaches and dictionary/version upgrades
   • External data transfers (specs, delivery schedule, re‑deliveries)
   • Reconciliation scope (SAE↔CRF, labs↔CRF, device data↔CRF), frequency, and lock gates
   • Query workflows and escalation rules
   • Interim and final lock sign‑offs and unblinding procedures

2. Assign RACI (one A rule)

   • Exactly one A per row. A cannot be a committee.
   • At least one R (who actually performs it); the A may also be the R (shown as R/A).
   • List C and I explicitly (e.g., Pharmacovigilance, Biostats, ClinOps, DM Lead, Vendor PM).
   • Note blinding boundaries (e.g., “Unblinded statistician: R for unblinded interim outputs, shared only with the Data Monitoring Committee (DMC); blinded DM and study team: no access”). Do not consult unblinded staff on blinded decisions: their input could reveal treatment allocation.

3. Encode responsibilities into the SOW For each vendor‑owned item, write clear deliverables, SLAs, acceptance criteria, and routing:

   • What: “Weekly lab file in agreed spec (v1.2), including units and reference ranges.”
   • When: “Deliver by 12:00 UTC every Tuesday.”
   • Quality bar: “≤0.5% structural defects; ≤1% code mismatches; provide defect log.”
   • Routing & escalation: “Lab discrepancies first to lab vendor within 1 business day; escalate to Sponsor DM if no response in 3 business days.”
   • Re‑deliveries: “Re‑cut within 2 business days after defect notification.”
   • Change control: “Any spec change approved through CCG change control, signed by the single A; effective date documented; regression checks required.”
   • Blinding: “Unblinded content partitioned; access restricted to named roles.”

4. Publish the matrix Place the RACI (and routing matrix) as a DMP appendix and in the vendor work instructions. Make it easy to find: link in meeting agendas and study portals.

5. Operationalize

   • Walk teams and vendors through the RACI in start‑up training; collect acknowledgements.
   • Add the routing matrix to ticketing/email templates (so issues reach the right owner).
   • Remind in governance calls (“decisions this week” slide tied to RACI rows).

6. Maintain as a living document

   • Trigger an update after protocol or mid‑study amendments, dictionary upgrades, or vendor changes.
   • Version the matrix (effective dates) and announce changes to all R/C/I parties.

Mini RACI example (illustrative)

Routing matrix (embed in SOW)

The site row is shown for routing only. Sites are not party to the vendor SOW: their data entry and query‑response timelines sit in the protocol, the eCRF completion guidelines and the clinical trial agreement with the site. DM raises the query and the site corrects its own data; a vendor corrects and re‑sends its own files.

What good looks like

• A one‑page matrix tied to real study decisions (not generic job descriptions).
• One A per row; blinding boundaries clearly called out.
• SOW includes: routing matrix, SLAs, re‑delivery timelines, acceptance criteria, and escalation contacts.
• Decision logs map back to RACI rows (you can trace who decided, when, and under which version).
• Vendors trained; acknowledgements stored; governance meetings use the matrix weekly.

Worked examples (CV trial)

These examples are self‑contained. Acronyms: CV = cardiovascular; CRF = Case Report Form; PV = Pharmacovigilance; CCG = Change Control Group; R/A/C/I as defined above.

1) Central lab “presence gap” in subject visit data

Problem: Site entered a visit in the CRF, but no lab file was received for that subject/date. Queries were being sent to sites first, causing churn.

RACI row: “External lab reconciliation and presence checks.”

• R: Lab Vendor (runs presence check; provides exception list).
• A: Sponsor DM Lead (owns reconciliation outcomes).
• C: ClinOps, Lab Medical Director.
• I: CRO PM, Biostats.

SOW excerpt:

Vendor shall provide a weekly “presence gap” exception report listing subject/visit/date with missing lab data and shall issue first‑line queries to the lab accessioning team within 1 business day. Only after vendor confirmation that the sample was not collected or was lost shall the vendor notify the CRO within 2 business days, so that CRO DM can raise any site query. Escalation to Sponsor DM if no vendor response within 3 business days.

Why it works: Queries go to the true owner first (the lab), protecting sites from noise and speeding closure.

2) CRF amendment triggered by protocol clarification

Scenario: The cardiovascular (CV) trial clarifies timing windows for ECGs. An eCRF page needs a new field and an edit check.

RACI row: “CRF/eCRF amendments & edit‑check deployments.”

• R: DM Lead (drafts change), CRO Build Team (implements).
• A: Sponsor Clinical Lead (clinical content authority).
• C: Biostats (impact to endpoints), PV (safety fields), QA (validation traceability), CCG (change review).
• I: Sites (release notes + training), Vendor PM.

SOW excerpt:

CRO shall implement approved CRF updates within 10 business days of the approval recorded at the CCG, provide build evidence, run regression checks per DVP, support sponsor user acceptance testing (UAT) before release, and deliver training slides to sites. Release notes shall list changes, expected impacts, and effective date.

Why it works: Accountability sits with the clinical owner; DM and CRO execute; everyone else is consulted or informed at the right time.

3) Mid‑study coding dictionary upgrade (MedDRA)

Scenario: Safety wants to move from MedDRA (Medical Dictionary for Regulatory Activities) 26.1 to 27.0 to match the version in the safety database.

RACI row: “Coding dictionary versioning and upgrades.”

• R: Coding Vendor (impact assessment, re‑coding, reports).
• A: Sponsor DM Head (approves timing/impact).
• C: PV Safety Physician (signal continuity), QA (validation), Biostats (analysis impacts).
• I: ClinOps, CRO PM.

SOW excerpt:

Vendor shall provide an impact analysis (terms affected, expected change rate, blinded/unblinded impact) and a re‑coding plan. Upgrade executes only after A’s written approval, with back‑ups, audit trail, and reconciliation to prior listings. Turnaround: 15 business days from approval.

Why it works: Change is controlled, analyzed for impact, and reversible; blinding is preserved.

Pitfalls & misconceptions

• “Everyone owns quality.” Without a named A, no one truly owns it.
• Multiple A’s. Committees can advise, but only one A may sign off a decision.
• Function‑level RACI. “CRO does data management” is useless; write activity‑level rows (e.g., “Weekly lab reconciliation exception handling”).
• RACI never updated. Protocol amendments, vendor swaps, or dictionary upgrades must trigger a version update.
• SOW silence on escalation and acceptance. If SLAs and acceptance criteria aren’t written, disputes are inevitable.
• Blinding leaks. Don’t give unblinded teams R or A on blinded deliverables.
• Routing to the wrong owner. Lab issues sent to sites first, or PV discrepancies sent to DM first—add a routing matrix.

Practice in the wild (checklist)

• One‑page RACI matrix with a unique A for every decision/deliverable.
• Routing matrix in SOW (discrepancy type → first owner → SLA → escalation).
• SLAs & acceptance criteria documented (acknowledge/fix times, quality thresholds).
• Blinding/access rules written (who can view what, by role).
• Change control path (CCG, effectivity dates, regression testing).
• Training & acknowledgements captured for teams and vendors.
• Decision log maps to RACI row and version.
• Trigger list for updates (amendments, vendor change, dictionary upgrade, lock rehearsal).

Key points to remember

• RACI decides; DMP explains; SOW binds. RACI clarifies who decides and who does; the DMP explains the process; the SOW contractually fixes deliverables and their priced counts (extra work needs a change order), SLAs, escalation paths, and acceptance criteria.
• Single‑A rule. Each decision/deliverable has exactly one Accountable (A)—not a committee. Committees can advise, not own.
• Route to the true owner. Send issues to the party who can actually fix them (site vs vendor vs sponsor). For external‑data discrepancies, go to the source vendor first; query sites only after the source confirms no sample/data.
• Protect blinding through roles. Unblinded teams must not hold R or A on blinded activities; access and training are role‑segmented.
• Write the quality bar. In the SOW, specify acknowledge/fix times, quality thresholds, re‑delivery timelines, and clear escalation—so disputes are resolvable.
• Change control is formal. CRF/DVP/dictionary updates require documented approval by the single A (reviewed and recorded through the CCG), effective dates, and regression evidence before release.
• Make the matrix usable. Put the RACI/routing matrix where teams work (DMP appendix, governance decks, ticket/email templates) and train vendors; capture acknowledgements.
• Keep it living and traceable. Version the RACI/SOW, update after amendments/vendor changes/dictionary upgrades, and maintain a decision log that maps to RACI rows and versions.
• Lock ownership is explicit. Data Management is typically A for lock readiness; Biostats (co‑signs), ClinOps and PV are C; all study teams are I after sign‑off.
• Tie decisions to deliverables. Align each RACI row to a concrete study decision and a measurable SOW deliverable to prevent gaps and accelerate timelines.