SOP: Writing, Reviewing, Approving, and Maintaining Standard Operating Procedures

This is a ready-to-use SOP, the one that governs how every other SOP is written and maintained. Replace each <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your own document control, review, and approval. 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 procedure defines how <<FILL: COMPANY NAME>> authors, reviews, approves, trains, issues, maintains, and retires standard operating procedures, so that every controlled procedure is accurate, followable, traceable to a version, and matched by the records it generates. The objective is procedures that a qualified person can execute correctly with the document in hand, and that stay matched to how the work is actually done.

2. Scope

This procedure applies to all GxP standard operating procedures across the sites and departments named in the header, and to the work instructions and controlled forms subordinate to them. It does not set the policy expectations those procedures implement, which sit in <<FILL: policy or quality manual reference>>, and it does not govern validation protocols or batch records, which follow <<FILL: their own governing SOP-IDs>>.

3. Responsibilities

4. Definitions

• Standard operating procedure (SOP): an approved, controlled document that describes how a specific repeatable activity is performed and who performs it, so the activity is done the same correct way every time.
• Altitude: the level a document is written at. Policy states intent, an SOP states how, a work instruction states the step-level mechanics of one task, and a form or log captures the record.
• Usability dry run: a controlled test in which a qualified but new user attempts the task using only the draft procedure and its forms, so unfollowable steps surface before approval.
• Periodic review: the scheduled, documented confirmation that a procedure still matches current practice, equipment, and references.

5. Procedure

5.1 Confirm the instrument and the altitude

1. The author confirms an SOP is the correct document for the activity: a repeatable, cross-role activity that needs one agreed way. Single one-time tasks use a protocol or work order; binding intent belongs in a policy; single-machine step detail belongs in a work instruction.
2. The author confirms the SOP does not duplicate or contradict an existing procedure by searching the master list (section 8) for overlapping scope.

5.2 Walk the process before drafting

1. The author observes the activity where it happens, or interviews the people who perform it, and records what actually happens, including any undocumented workarounds and the reason each one exists.
2. The author identifies every decision point, every value read or recorded, every handoff between roles, and every point where the task can go wrong.

5.3 Identify the regulatory and risk drivers

1. The author establishes which regulation or standard mandates the activity and which steps are critical control points for product quality, patient safety, or data integrity.
2. For each data-handling step, the author applies data-integrity thinking so the resulting records are attributable, legible, contemporaneous, original, accurate, and complete, and requires the record at the time of the action.

5.4 Draft the steps, then the framing

1. The author writes the procedure section first as numbered single-action steps, in the active voice, each with a named role as the actor and the acceptance criterion stated inside the step.
2. The author writes every decision as an explicit branch with the failure path defined, including what to record, when to stop, and who to notify.
3. The author designs the controlled form alongside the steps so the record captures exactly what the steps require.
4. The author then writes purpose, scope, responsibilities, definitions, references, materials, records, and revision history.

5.5 Run the usability dry run

1. A qualified user who did not write the draft attempts the task using only the draft and its forms.
2. The author records every point of hesitation, question, or reach for tribal knowledge as a defect on the usability dry-run record (<<FILL: form-ID>>) and revises the draft to close each one.
3. The dry run is repeated after material revisions until a new user can complete the task without external help.

5.6 Route for review and approval

1. The author routes the revised draft to the SME (technical correctness), the usability reviewer (executability), and QA (document-control and regulatory alignment).
2. Reviewers record findings and resolutions; the author dispositions each.
3. The named approvers sign and date the approved version. Electronic approvals follow the electronic-records and signature controls in <<FILL: SOP-ID for electronic records>>.

5.7 Train, then make effective

1. The training coordinator ensures all affected staff are trained on the approved version and records completion.
2. Document control sets the effective date on or after training completion, so there is never a window where the SOP is in force but staff are untrained, and never a window where staff follow a draft.

5.8 Maintain through review and change control

1. Document control schedules the periodic review at <<FILL: default cycle, e.g. every 2 years>>, shortened for higher-risk procedures.
2. Any change between reviews is made under change control per <<FILL: SOP-ID for change control>>, with the revision history describing what changed and why, traceable to the change record.
3. When a deviation shows the procedure was not followable, the corrective action revises the procedure, not only the training.

5.9 Supersede or retire

1. On revision, the prior version is superseded and archived; the master list and any references to it are updated.
2. On retirement, document control withdraws the procedure from points of use, records the rationale, and updates every document that referenced it.

6. Acceptance criteria

A procedure is ready for approval when all of the following are true:

• A qualified but new user completed the task in the dry run using only the document and its forms.
• Every step has one actor and one action, and every acceptance criterion sits inside the step that needs it.
• Every decision point is an explicit branch with the failure path defined.
• Scope states both what is covered and what is excluded; references are current; every referenced form is under document control.
• Responsibilities match the roles that appear in the steps, with no orphan roles and no unnamed actors.
• The records section states what is generated, where it goes, and how long it is retained.
• The effective date is on or after training completion, and the revision history describes what changed and why.

7. Records generated

• Usability dry-run record (<<FILL: form-ID>>).
• SOP review and approval record (<<FILL: form-ID>>).
• Training completion records (per the training SOP).
• Change control record for any revision (per the change control SOP).
• Master list entry and periodic review record (section 8).

8. Master list and periodic review

Document control maintains a controlled master list of every SOP with its number, title, owner, current version, effective date, review cycle, and next-review-due date, and drives the periodic review from it. See the paired <<FILL: log-ID for the SOP master list>>.

9. References

21 CFR 211.22(d) (quality unit procedures in writing), 211.100(a) and (b) (written production and process control procedures, followed and documented at the time of performance). 21 CFR 211.180 and 211.186 (records, and master production and control records). EudraLex Volume 4, GMP Chapter 4 (Documentation). ICH Q10 (Pharmaceutical Quality System) and ICH Q7 section 6 (documentation and records) for the expectation of a system of written procedures.

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

10. Revision history

11. Approvals

Filled specimen

The following shows section 5 applied to an example: authoring a new SOP for receiving incoming raw material samples. The company, numbers, and names are illustrative; replace them with your own.

In this example the dry run caught a real ambiguity (record before or after the move) that would otherwise have produced inconsistent records, and the QA review caught a dead reference. Both defects were closed before the procedure ever reached the floor, which is exactly what this SOP is for.

Common inspection findings this SOP prevents

• A procedure was approved but no one could actually follow it, and the deviation was closed with “retrain” instead of fixing the document.
• An SOP took effect before the affected staff were trained on it, or staff were found following a superseded or draft version.
• Two procedures described the same activity differently because neither scope stated its boundary.
• A referenced form was uncontrolled, or a reference pointed to a retired document.
• Revision histories read “updated for clarity” with no traceable description of what changed.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Point the cross-references in sections 5 and 7 to your real electronic-records, change-control, training, and deviation procedures.
3. Set your own default periodic-review cycle in 5.8 and your risk basis for shortening it.
4. Reference your real usability dry-run and review-and-approval forms in sections 5 and 7.
5. Confirm every regulation in section 9 against the current published version before issue.