SOP: Controlled Emergency Direct Database Edit

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. Use this procedure only when the application layer offers no path to correct the problem; verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This procedure defines the only route by which a GxP record may be altered directly at the database tier, bypassing the application, so that when this route is used, the resulting edit is fully reconstructable, pre-approved, witnessed, and independently corroborated. It exists because direct edits are occasionally the only way to correct a genuine defect (data corruption, a stuck workflow, an orphaned row from a migration defect) that the application itself cannot resolve, and an undocumented back-end edit is indistinguishable from falsification.

2. Scope

This procedure applies to every direct INSERT, UPDATE, or DELETE statement executed against a production database table holding GxP data, outside the normal application path. It does not apply to DBA activity that does not alter GxP business data (backup, restore of a non-GxP environment, performance tuning, schema changes under separate change control). Governance of who may hold direct database access at all is defined in <<FILL: SOP-ID for DBA governance and segregation of duties>>.

3. Responsibilities

4. Definitions

• Before image: a saved query result showing the exact rows and values immediately before the edit.
• After image: a saved query result showing the exact rows and values immediately after the edit, confirming the change did exactly what was authorized and nothing more.
• Scoped statement: a SQL statement whose WHERE clause is reviewed in advance and confirmed to touch only the intended row(s), typically by primary key.
• QA witness: a Quality Assurance representative, independent of the executor, present (in person or via a controlled remote session) during execution to attest that what ran matched what was approved.

5. Procedure

5.1 Confirm no application path exists

1. The requester documents the defect and confirms, in writing, that no supported application function, administrative screen, or standard workflow can correct it.
2. If an application path exists, use it. This procedure is not a shortcut around slower application-mediated fixes.

5.2 Raise the change and obtain pre-execution approval

1. Raise a change record per <<FILL: SOP-ID for change control>> describing the defect, the business or compliance impact of not fixing it, the exact proposed SQL statement, the affected record(s) identified by primary key, and the rollback plan.
2. Attach application-side evidence of the problem (screenshots, error logs, the stuck workflow state).
3. QA and the system owner review and approve the change before any statement is executed. For a genuine emergency, use the expedited approval path defined in <<FILL: SOP-ID for change control>>; expedited means faster, not skipped.

5.3 Capture the before image

1. Immediately before execution, the DBA runs and saves a SELECT of exactly the rows to be changed, capturing every column that will be affected.
2. Attach the before image to the change record.

5.4 Execute under a witnessed transaction

1. Open an explicit transaction (BEGIN TRANSACTION or the platform equivalent).
2. Execute the exact statement reviewed and approved in section 5.2, no ad hoc modification.
3. Run a verifying SELECT to confirm the new state and the number of rows affected.
4. The QA witness confirms the row count matches expectation and the resulting values match the approved change before authorizing commit.
5. If the row count or values do not match, ROLLBACK immediately and return to section 5.2 to re-plan; do not attempt to patch the statement mid-transaction.
6. On confirmation, COMMIT.

5.5 Capture the after image and close the record

1. Immediately after commit, run and save a SELECT of the same rows to serve as the after image.
2. Attach the after image and the QA witness attestation to the change record.
3. Within <<FILL: number>> business days, confirm the native database audit log recorded the statement, with a row count and account matching the change record; attach the audit-log excerpt.
4. The system owner assesses whether the edited value feeds a calculation, a release decision, or a submission, and triggers a deviation or impact assessment per <<FILL: SOP-ID for deviation management>> if so.
5. Close the change record with the approval, both images, the witness attestation, and the audit-log confirmation all attached.

6. Acceptance criteria

An emergency edit is defensible only when all of the following are true: QA approved the exact statement before execution; the statement was scoped to named rows by primary key; a before image and an after image were both captured; the edit ran inside a transaction with a verified row count before commit; a QA witness independent of the executor attested to the execution; the native database audit log independently corroborates the statement; and downstream data impact was assessed. Any one missing element makes the edit indistinguishable from an unauthorized change, regardless of intent.

7. References

21 CFR Part 11.10(e) (audit trails) and the general expectation that changes to electronic records be justified, approved, and traceable. EU GMP Annex 11, clause 9 (audit trails). PIC/S PI 041, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments.

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

8. Record generated: emergency database edit record

9. Revision history

10. Approvals

Filled specimen

This is what a defensible emergency edit looks like end to end: pre-approved, scoped to one row, witnessed at the moment of execution, and corroborated by an independent log, so an inspector reviewing it sees a fully reconstructable action rather than a quiet fix.

Common inspection findings this SOP prevents

• A back-end fix applied first, with the change paperwork completed afterward or not at all.
• An UPDATE with a loose or missing WHERE clause that affects more rows than intended, discovered only later.
• No before image, so the prior value can never be proven and the edit cannot be reversed with confidence.
• No independent QA witness present at execution, only a signature added afterward.
• The native database audit log never checked against the change record, so the two independent trails were never actually reconciled.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Point the cross-references in sections 2, 5.2, and 5.5 to your real DBA governance, change control, and deviation management procedures.
3. Set the audit-log confirmation window in section 5.5 to match how quickly your platform’s audit log becomes available for review.
4. If your organization requires a specific remote-witness tool or protocol, name it in section 5.4.
5. Confirm every regulation in section 7 against the current published version before issue.