SOP: Database Administrator (DBA) Governance and Segregation of Duties

This is a ready-to-use SOP. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> governs database administrator access to the databases that hold GxP data, so that the person who can technically alter a GxP record at the database tier is organizationally independent of the function that owns the data, cannot act under a shared or anonymous identity, and cannot silently bypass the controls that make the record trustworthy.

2. Scope

This procedure applies to every database that stores, processes, or transmits GxP data, including production, validation, and any environment holding a live or restored copy of GxP data. It covers named DBA accounts, application service accounts with elevated database privileges, developer and vendor support accounts with any direct database access, and the periodic reconciliation that confirms the segregation described here is operating, not merely documented. It does not itself define how emergency direct database edits are executed; that is governed by <<FILL: SOP-ID for controlled emergency database edits>>.

3. Responsibilities

4. Definitions

• DBA (database administrator): the role responsible for the availability, performance, backup, recovery, and infrastructure-level configuration of a database, distinct from ownership of what the data in it means.
• Data-owning function: the business function (for example QC, manufacturing, clinical operations) accountable for the accuracy and disposition of the GxP data a system holds.
• Named account: a credential attributable to exactly one individual; the opposite of a shared or generic administrator login.
• Segregation of duties: the control that prevents one individual from both being able to alter a record and being the person who approves, witnesses, or relies on that record without independent oversight.

5. Procedure

5.1 Organizational placement of the DBA function

1. Place the DBA function within IT, reporting through an IT management line that is organizationally separate from QC, manufacturing, and QA.
2. Document the reporting line in the org chart referenced by this SOP and re-confirm it at each periodic review (section 5.5).
3. Where the DBA function is outsourced or shared with a parent organization, document the equivalent independence and the contractual or SLA control that enforces it.

5.2 Named-account discipline

1. Provision every privileged database account to a single named individual. No shared, generic, or role-based login (for example dba, sa, sysdba) may be used for privileged database activity.
2. Provision the application’s own service account separately from any human account; no human may log in interactively using the application service account credential.
3. Deprovision a DBA’s privileged access within <<FILL: number>> business days of role change or departure, with evidence retained per section 8.
4. Where a small organization cannot support one DBA per system, name the individual(s) holding the role explicitly and apply the compensating control in section 5.4.

5.3 The standing limit of DBA authority over GxP business data

1. The DBA role includes: backup, restore, performance tuning, patching, infrastructure-level configuration, and native audit logging configuration (subject to change control).
2. The DBA role explicitly excludes: routine alteration of GxP business data values, and any privilege that lets the DBA disable native database auditing without that disablement itself being logged.
3. Any instance where a DBA must alter GxP business data directly is a controlled emergency edit, governed by <<FILL: SOP-ID for controlled emergency database edits>>, never a routine DBA action.
4. Communicate this limit to every DBA at onboarding and at each periodic refresher training per <<FILL: SOP-ID for training>>.

5.4 Compensating control where full segregation is not achievable

1. Where one individual unavoidably holds both a DBA-adjacent role and a data-owning role (typical only in small organizations), document the overlap explicitly rather than asserting segregation that does not exist.
2. Assign an independent second person (QA or an external party) to review 100 percent of that individual’s privileged database activity from the off-box audit log, at <<FILL: frequency>>.
3. Require a witness who is not the individual in question for any emergency direct edit that individual performs.
4. Record the compensating control, its performer, and its frequency in the system’s data governance record.

5.5 Periodic reconciliation

1. At <<FILL: frequency, e.g. quarterly>>, IT security and QA jointly reconcile: the list of accounts with direct database access against current DBA staffing, the reporting-line independence of each DBA from data-owning functions, and the absence of any shared or generic privileged login.
2. Record the reconciliation outcome in section 8. Any exception found is raised as a deviation per <<FILL: SOP-ID for deviations>> and tracked to closure.
3. Feed the reconciliation into the system’s periodic review under <<FILL: SOP-ID for periodic review>>.

6. Acceptance criteria

Segregation is sound when: the DBA function reports through a line organizationally independent of QC, manufacturing, and QA; every privileged database account is a named individual account with no shared or generic logins in use; the application service account is never used interactively by a human; DBA authority over GxP business data is limited to the controlled emergency-edit process; any unavoidable role overlap carries a documented, performed compensating control; and a periodic reconciliation confirms all of the above on the defined schedule with findings routed to deviation management.

7. References

21 CFR Part 11.10(d) (limiting system access to authorized individuals). EU GMP Annex 11, clause 2 (personnel) and clause 12 (data security). PIC/S PI 041, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. MHRA GxP Data Integrity Guidance and Definitions.

Confirm the current version and clause numbers of each reference before issue.

8. Record generated: DBA segregation reconciliation record

9. Revision history

10. Approvals

Filled specimen

This example shows a clean quarter: the prior finding (a legacy shared login) was closed and its absence was re-verified rather than assumed, which is exactly the kind of evidence that survives an inspector asking “how do you know it stayed fixed.”

Common inspection findings this SOP prevents

• A DBA who also holds a laboratory or manufacturing role, with no documented compensating control.
• A shared sa or dba login used by more than one person, discovered only when investigating an undocumented change.
• The DBA function reporting to the same manager as the data-owning function it serves.
• No periodic reconciliation, so a segregation failure could exist for years without being caught.
• The application service account credential shared among analysts for convenience.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Point section 5.3’s cross-reference at your actual controlled emergency database edit procedure (see the paired SOP for that process).
3. Set the reconciliation frequency in section 5.5 based on the criticality of the databases in scope.
4. If your organization outsources or shares the DBA function, expand section 5.1 with the specific contractual or SLA control that stands in for the internal reporting-line independence.
5. Confirm every regulation in section 7 against the current published version before issue.