Writing a good SOP requires thinking about two audiences simultaneously: the employee who will use it to perform a task and the auditor who will use it to verify that the task was performed correctly. This article walks through what FDA actually requires in an SOP, the structure that holds up under inspection, and the common writing mistakes that create compliance risk.

What FDA requires from a standard operating procedure

FDA does not prescribe a specific SOP format. What the regulations require is that procedures exist, that they are documented, that they are kept current, and that employees follow them. The specific requirements come from several places depending on your regulatory framework:

• 21 CFR Part 820.40 (Document Controls) — requires procedures for document approval, change control, and distribution
• 21 CFR Part 820 QMSR broadly — requires that your quality system be documented and implemented
• 21 CFR Part 211 (GMP for pharmaceuticals) — requires written procedures at virtually every stage of drug manufacturing, testing, and distribution
• ISO 13485:2016 — requires documented procedures for processes that affect product quality, with control and maintenance of those documents

What inspectors actually look for when they review an SOP: Is it approved? Is it the current version? Does it describe what actually happens? Are employees trained to it? Are records showing the procedure was followed?

Missing any link in that chain — approved but not trained, trained but not followed, followed but not matching the written steps — creates a finding.

The structure of an FDA-defensible SOP

A standard operating procedure that holds up under inspection typically includes these sections, in this order:

Header block

The header identifies the document unambiguously. It should include: document number, document title, version number, effective date, the name and signature of the person who wrote it, the name and signature of the person who reviewed it (usually the quality manager), and the name and signature of the person who approved it (usually a department head or above).

The effective date matters. A document that shows a review date but no effective date, or a version number that does not match what your document control system shows as current, will raise questions immediately.

Purpose

One to three sentences describing what the procedure accomplishes and why it exists. Keep this factual and specific. “This procedure establishes the requirements for incoming inspection of raw materials and components to ensure they meet specified requirements before release for use in manufacturing” is useful. “This document provides guidance for quality activities” is not.

Scope

Define what the SOP covers and what it does not cover. Name the product types, process steps, facilities, or job functions that fall under this procedure. This section prevents the argument that a procedure either applies to everything (over-broad) or nothing (too narrow to catch the situation at hand).

Responsibilities

List job titles — not individual names — and their specific responsibilities under this procedure. Using job titles rather than names means the procedure does not need to be revised every time personnel change. “The Quality Manager is responsible for approving all deviations identified during incoming inspection” is correct. “John Smith is responsible for…” requires a revision every time John changes roles or leaves the company.

Definitions and abbreviations

Define any term in the procedure that a new employee might not know, and spell out all acronyms on first use. This section protects you when an auditor asks whether your team understands the difference between a deviation and a non-conformance, or what “IQ” means in the context of validation. If the terms are defined, the document teaches its own vocabulary.

Referenced documents

List every other document that this SOP refers to — work instructions, forms, specifications, other SOPs. Reference by document number and title. This section creates a document network your quality system can navigate. During an inspection, an investigator tracing a process from SOP to record can follow the references forward and backward without gaps.

Procedure body

This is the actual process. Write it as numbered steps in the sequence in which the task is performed. Each step should describe a single action. Use active voice and direct instructions. “Record the lot number in Field 3 of Form QA-042” is a correct procedure step. “Documentation of lot information should be completed” is not — it is vague about who does it, what they record, and where they record it.

If the procedure has branches — different steps depending on conditions — use conditional language explicitly: “If the incoming inspection result is out of specification, proceed to Step 8. If the result meets specification, proceed to Step 5.” Decision trees and flowcharts in an appendix can help for complex branching logic, but the numbered procedure body should still capture the linear path of most normal execution.

Records

Identify every record generated by following this procedure — forms, logs, system entries. List the form number or system location. Describe who is responsible for completing each record and where completed records are stored. This section closes the loop between procedure and evidence: if an investigator asks “show me that this was done,” the records section tells them exactly where to look.

Revision history

A table at the end showing version number, effective date, description of changes, and the name of the person who made the change. Every version in the revision history should be traceable to a change control record explaining why the revision was made.

Common SOP writing mistakes that create inspection findings

Writing to the ideal, not the actual

The most common and most damaging SOP mistake is writing how a process should work in theory rather than how it actually works. If your incoming inspection SOP says materials are quarantined and labeled within two hours of receipt, but your actual practice is to label them the next morning, your SOP and your practice are misaligned. When an inspector finds this gap, the finding is that the procedure is not being followed — even if your actual practice is perfectly reasonable and defensible on its own terms.

The fix: write the procedure by observing what people actually do, then review with the people who do it before finalizing. Do not write from behind a desk based on how you think the process works.

Using vague language

Words like “appropriate,” “as needed,” “timely,” and “properly” have no meaning in a regulated procedure. “Document the result appropriately” is not a procedure step — it is an instruction to use judgment that the person performing the task may or may not have. Replace every vague term with a specific requirement: what to document, where to document it, in what format, within what timeframe.

Omitting decision criteria

Many SOPs describe a task but omit the criteria for making decisions within that task. An incoming inspection SOP that says “inspect the material and release or reject” without specifying the inspection criteria, acceptable limits, or reference to a specification document has left the most important part out. Every decision point in a procedure needs defined criteria.

Making the document too long

An SOP that requires an hour to read before performing a five-minute task will not be read. Length is not quality. If a procedure runs more than ten pages, evaluate whether it should be split into a parent procedure with subordinate work instructions. Parent-child document structures work well for complex processes: the SOP captures the what and the who, while work instructions capture the detailed how for specific sub-tasks.

Not updating after process changes

A procedure that describes a step using equipment that was replaced two years ago, or a form that was retired eighteen months ago, is an out-of-control document. Regulated companies must have a change control process that captures process changes and triggers corresponding SOP revisions. This is one of the places where a document management system earns its keep — when a change control is initiated, the system can identify every document that references the affected process and flag them for review.

Approving without reading

Signatures on an approval block mean nothing if the signatories have not read and verified the document. When an investigator identifies an error in an approved SOP, the follow-up question is always “how did this get approved?” The answer cannot be “we trusted the author.” Build a real review process: the reviewer reads the procedure and independently verifies that it reflects actual practice.

SOP templates and when to use them

A controlled SOP template standardizes formatting across your document library and reduces the effort of writing new procedures. Templates should enforce the required sections — header, purpose, scope, responsibilities, procedure body, records, revision history — and establish font, heading style, and page numbering conventions.

Use templates to enforce structure, not content. A template that pre-populates procedure steps with placeholder text encourages authors to edit minimally rather than think through the actual process. The template should provide blank fields with clear instructions for what belongs in each section.

Critically, the SOP template itself must be a controlled document. It needs a document number, a version, and a change control process. If the template changes, existing procedures written on the old template do not need to be immediately revised — but the next revision of each should use the current template format.

Training employees to SOPs

An SOP that nobody has been trained to is, for regulatory purposes, a document that does not govern the process it describes. Training requirements under FDA and ISO 13485 require that employees performing quality-affecting tasks are trained and that training is documented.

Training documentation should link each employee to the specific SOP version they were trained to, the date of training, and the method of training (read and understood, practical demonstration, competency assessment). When an SOP is revised, employees who use that procedure must be re-trained to the new version before the new version becomes effective — or, at minimum, within a defined transition window.

The most defensible training records show not just that training occurred, but that the employee demonstrated understanding. A signature on a “read and understood” form is evidence of training; a passed competency assessment or documented practical demonstration is stronger evidence.

Managing SOP revisions and version control

Every revision to an SOP must go through a formal process: a documented reason for the change, review and re-approval following the same pathway as the original, and controlled distribution of the new version. Obsolete versions must be removed from use and archived in a way that makes clear they are no longer current.

In a paper-based document control system, version control failures are common — printed copies circulate, people miss the notification that a new version is available, outdated forms get used for months after a revision. Electronic document control systems solve most of these problems by making the current version the only accessible version for active use, automatically notifying affected users when a new version is approved, and routing training confirmation before a revised SOP becomes effective.

How Cloudtheapp supports SOP management in regulated environments

Cloudtheapp’s document control application manages the complete SOP lifecycle in a single validated platform. SOPs are created from controlled templates, routed through defined approval workflows, and published to users with automatic training task generation. When a revision is initiated, the system identifies affected employees, routes re-training confirmations, and prevents users from accessing an obsolete version while the new one is in effect.

The platform’s audit trail captures every action on every document — who viewed it, who approved it, who completed training, and when. During an FDA inspection, investigators can trace any document event without paper logs or manual reconstruction. The system maintains full version history with change control linkage, so every revision is traceable to the change that triggered it.

With 60+ applications in a single platform, Cloudtheapp connects your SOP management to your CAPA process, training records, supplier qualification program, and audit management — giving you a quality management system where every process feeds into the next rather than operating in isolated silos.

To see how SOP lifecycle management works inside Cloudtheapp, request a demo.

Summary

FDA does not require a specific SOP format, but it does require that procedures exist, stay current, match actual practice, and that employees follow them with documented evidence. The gap between any two of these requirements creates an inspection finding.

Good SOPs are written by observing what people actually do, expressed in specific and unambiguous language, reviewed by the people who perform the process, and maintained through a change control system that keeps the documents current as processes evolve. The structure — purpose, scope, responsibilities, procedure steps, records, revision history — is less important than the accuracy and specificity of what goes into it.

A document management system that automates version control, routes training, and creates an audit-ready record of every document event eliminates most of the operational failure modes that turn SOP deficiencies into inspection findings.

This post created by and appeared first on Cloudtheapp