The SOP exists — where's the evidence that anyone actually followed it?

I came into quality from an engineering background, so I tend to treat procedures like APIs: they specify an interaction contract between people and the system. In practice, though, audits don't ask whether the API (SOP) exists. They ask whether the call happened, when, and with immutable proof that it returned the expected result. That "did it actually happen?" gap is where every audit I've been through lives.

In our Class II setup the SOPs are fine on paper. Training matrices are signed. The gap appears when an auditor wants to trace an event — a device change, a complaint, a supplier nonconformance — back to evidence that the procedure was followed end-to-end.

Typical failures I see in the wild

These are not hypothetical; they're things I've encountered repeatedly:

• The SOP for nonconforming product specifies raising an NCR and routing it to the supplier team. The NCR form exists — but the NCR record is empty except for a title and a later CAPA reference. No timestamps, no signature, no evidence the supplier was notified.
• Calibration SOP requires date-stamped calibration records tied to equipment IDs. The equipment has a calibration sticker, but no digitized record, no scanned certificate, and the sticker's date is ambiguous.
• Change control SOP says you must perform impact analysis across the Technical File. The change ticket links a few documents, but there's no linkable evidence that the usability engineer reviewed risk items or that the DHF artifacts were updated.
• Training lists show "training completed" as a check in a spreadsheet, but there's no proof the correct revision of the SOP was read, nor a quiz or traceable acknowledgement.

Auditors don't care that "we have an SOP" — they care that you can produce traceable, time-stamped, reviewable records that are tied to the product artifact and to the people who executed the procedure.

Why this gap happens

A few practical causes repeat across companies:

• Procedures are written by QA for auditors, not for the users who must execute them. They are correct, but not runnable.
• Evidence capture is manual and frictionful: people file a PDF, email a report, or scribble on a paper log. Manual steps get skipped.
• Tools are siloed. Device history, supplier emails, CAPA tracker, and document control live in separate systems without reliable links or searchable metadata.
• Forms are optional. If a form field is not required (or enforcement is manual) the quickest path becomes "skip the paperwork and close the loop later".
• Training is checkbox-focused: records show "training completed" when the trainee barely skimmed the SOP and cannot demonstrate rationale or version awareness.

Standards highlight the evidence requirement. ISO 13485 expects records of conformity; 21 CFR 820 expects device history records and proper procedural implementation. The standards don't accept "we say we did it" — they expect records.

What I try to do (practical fixes that helped)

I've found the problem becomes tractable when you treat evidence capture as part of the process design, not as an afterthought.

Make evidence discoverable and native

• Add required, machine-readable fields to forms: equipment ID, timestamp, signer (with e-signature), and linking metadata (lot number, change ticket ID).
• Where possible make artifacts linkable: link NCRs to supplier records, link change requests to specific design outputs and to the risk assessment that was updated.
• Use search-friendly metadata — if auditors can "find evidence instantly (no forensic investigation required)" you'll reduce stress and audit time.

Reduce manual handoffs

• Remove "email a PDF" steps. Use a QMS that captures artifacts within the workflow and stores a revisioned record with an audit trail.
• For critical activities (testing, calibration), require an upload of a signed certificate or a log export before the action can move forward.

Drive execution via enforced gates

• Use gating in your workflow tooling: you can't close a change request without a completed impact analysis checklist, with required fields filled and links to documents.
• Make required attachments obligatory (e.g., test reports for design verification).

Design forms for the people who use them

• Reduce cognitive load: short, clear checklists beat long prose that gets ignored.
• Provide inline help: "What to attach" and "how to fill this field" reduces incorrect or incomplete evidence.

Automate where it makes sense

• Integrate lab systems, LIMS, CI systems, and source control with the QMS via APIs/webhooks so test results, commit hashes, or build artifacts can be attached automatically to the DHF or change ticket.
• For example, a CI job that runs unit tests could push a signed test report into the change ticket when a design file changes. That removes human friction and creates a time-stamped artifact.

Make auditability part of training

• Train people on "what evidence looks like" and why it's required. Show examples of acceptable vs unacceptable records.
• Use controlled assistance or templated responses for common activities (e.g., supplier notification), so the authoring moment is guided.

Balancing control and usability

There is a real tradeoff: too much enforcement becomes a bottleneck and encourages workarounds. The goal is "friction where it matters, smooth where it doesn't." Start with critical processes (CAPA, change control, release testing, supplier nonconformance) and make those evidence-rich. Use lighter controls for low-risk administrative work.

Final thought and question

Auditors are asking for demonstrable, linked, time-stamped proof — not rhetorical compliance. Treat the SOP as the contract and the record as the audit log.

For those who've actually implemented this end-to-end: what has been the single most effective change for closing this gap in your org — a tooling integration, a form redesign, a training tactic, or something else?