What Happens to Your Evidence When a Procedure Changes?

A revised procedure does not merely change the instructions for the next task. It changes the context against which future work will be judged. Unless completed records remain linked to the specific approved version in force when they were created, an organisation can lose the ability to explain what was actually done, why it was acceptable at the time, and who authorised the method.

This is an evidential problem, not simply a document-control problem. A record stating that an inspection passed, an instrument was calibrated, or a batch was released is incomplete if the applicable acceptance criteria, method, equipment requirements and approval status cannot be reconstructed. A current procedure may be useful for operating the system now. It is not necessarily the correct basis for interpreting an event that occurred six months earlier.

A procedure is part of the record context

Procedures often define much more than a sequence of actions. They may specify:

the authorised method and its preconditions;
permitted equipment, reference standards or software versions;
acceptance limits and decision rules;
required environmental conditions;
mandatory checks, review stages and independent approvals;
required fields, attachments and deviations handling.

When any of these change, the meaning of a completed record may change with them. For example, a revised calibration procedure might introduce a tighter tolerance, require additional measurement points, or change how measurement uncertainty is considered in a conformity decision. A calibration performed under the earlier method cannot be assessed fairly by reading only the revised procedure.

The historical record should therefore identify the controlled procedure version or immutable revision identifier that applied at execution. Where work is undertaken from a controlled electronic workflow, that identifier should be captured automatically and retained with the resulting record. Relying on a user to type a document revision is weaker: it is vulnerable to transcription errors, use of local copies and later ambiguity.

Superseded does not mean irrelevant

A common failure is to treat superseded procedures as obsolete material to be removed from operational systems. They should indeed be prevented from being selected for new work, except where an authorised exception applies. But retirement from current use is different from destruction of historical context.

Superseded versions need controlled retention for at least as long as the records they support must remain interpretable. Retention periods will depend on the intended use, contractual obligations, applicable regulation and the organisation's quality system. The precise requirement must be determined from the relevant authoritative sources and governance arrangements. The engineering principle is straightforward: if a retained result may need to be defended, the applicable method must also be recoverable.

Recoverability means more than storing a PDF in an archive. The organisation should be able to establish that the retained version is authentic, complete and unchanged since approval. Useful controls include immutable version identifiers, approval metadata, effective dates, access control, cryptographic integrity mechanisms where appropriate, and a traceable history of issue, replacement and withdrawal.

Effective dates create operational boundaries

A procedure revision needs an explicit effective date or controlled release condition. Without one, teams may apply different interpretations of when the new requirements became mandatory.

The boundary is rarely as simple as the time a document was approved. Consider work that begins under one revision and ends after another becomes effective. Consider open calibration jobs, production lots in progress, corrective actions already underway, or field work performed with intermittent connectivity. The change process should define how such in-flight work is handled.

Possible controls include completing work under the version under which it started, requiring a documented transition assessment, or stopping and restarting work under the new method. The appropriate choice depends on the risk introduced by the change. A clarification to wording may need little more than communication. A revised acceptance limit, changed reference standard or altered safety control can require a more deliberate transition.

A technically functional workflow may allow users to finish a task under an old procedure. A controlled workflow must also show whether that was permitted, who made the decision, and what evidence supports it.

Change control must assess records as well as documents

Procedure change control is often focused on drafting, review and approval of the new document. It should also assess effects on the evidence already held and the work currently in progress.

Questions worth asking include:

Does the revision alter the interpretation of existing data or results?
Are previous records still complete enough to be understood under their original method?
Must affected assets, batches or cases be identified and reviewed?
Does the change require new training, system configuration or validation?
Are linked forms, templates, instruments, software rules and reports revised consistently?
Can an investigator reconstruct which revision was available to a user at the time of execution?

This assessment is particularly important where procedure logic is embedded in software. Updating an electronic form, a workflow rule or a calculation engine can silently alter execution even if the associated document revision is well controlled. The deployed configuration, test evidence and release approval form part of the procedural context. A document revision alone cannot demonstrate how the system behaved.

Preserving defensible provenance

Evidence becomes defensible when its provenance can be followed from the reported outcome back through the data, method, approvals and controlled system state that produced it. Procedure versioning is one link in that chain, but it connects several others.

For measurement work, the record may need to identify the procedure revision, instrument and reference standard used, calibration status, raw readings, environmental conditions, calculation method, uncertainty treatment and reviewer approval. For a digital process, it may also need the software version, configured rules, identity of the operator, timestamps and any authorised deviation.

Timestamps require care. They should distinguish when work was performed, when data was entered, when it was reviewed and when the procedure became effective. Systems using distributed devices should have controlled time sources and a defined approach for clock drift or loss of synchronisation. Otherwise, an apparently simple question about whether work preceded a procedural change can become difficult to answer reliably.

The practical objective is not to preserve every artefact without discrimination. It is to retain sufficient, controlled evidence to reproduce the decision context. That requires defining the record set deliberately during system and process design.

When a procedure changes, historical evidence should not be rewritten to resemble the new state of the system. It should remain anchored to the approved instructions, limits and approvals that governed the work when it occurred. Version control provides the mechanism, but disciplined change assessment, controlled retention and traceable system behaviour provide the evidence. Without those links, a record may still exist, yet no longer say enough to support the decision it claims to document.