Your SOP changed. Is your training now wrong?

When an approved SOP changes, the related training should enter change control immediately. That does not mean every edit requires a new course or organization-wide retraining. It means someone must identify the training that depends on the SOP, evaluate what changed, update the affected learning content, make a documented retraining decision, and secure the right approval before the revised training becomes active.

Without that link, a company can maintain a current procedure and an outdated course at the same time. The LMS may show 100% completion while employees are confidently following yesterday's process.

This article presents an original LoreGraph framework for managing that risk. It adapts established ideas from training quality, configuration management, and regulated change control; it is not a universal legal standard. Industry, jurisdiction, contract, and organizational policy may impose additional requirements.

Key takeaways

• Treat a course as a governed artifact that depends on one or more approved sources.
• Record source-to-course and source-to-lesson relationships before a change occurs.
• Separate the content-update decision from the employee-retraining decision.
• Base retraining on the change's effect on job actions, decisions, hazards, obligations, and evidence requirements.
• Preserve the old source, course, approvals, impact decision, and learner records instead of overwriting history.

The real failure is broken traceability

An outdated course is usually not just an editing problem. It is a traceability problem.

The organization may know that SOP 4.2 changed, but not that it supports three courses, seven lessons, two quiz questions, an onboarding checklist, and a supervisor observation form. If those relationships live only in one instructional designer's memory, every document update becomes a scavenger hunt.

The first control is therefore not “review courses more often.” It is a visible chain from an authoritative source to every learning artifact that relies on it. At minimum, the organization should be able to answer:

• What is the approved source and current version?
• Who owns its meaning and effective date?
• Which courses and job aids depend on it?
• Which lessons, examples, activities, and scored answers use it?
• Which learner groups completed or are assigned to each course version?
• Who owns the update and approval decision?

The CDC Quality Training Standards recommend that subject-matter experts ensure content is accurate, evidence-based, and up to date. They also recommend giving training an expiration date so it can be reviewed, updated, or retired. A review date catches aging content; a dependency link catches a specific source change sooner.

The source-to-training change-control lifecycle

The complete lifecycle is:

Approved source → linked course and lessons → source changes → impact review → affected content updates → reapproval → notification or retraining → historical evidence preserved

This framework borrows the discipline of configuration management. NIST Special Publication 800-128 describes a formal change-control process in which changes are requested, recorded, evaluated for impact, tested, approved, implemented, verified, and closed. The publication concerns information-system security, not workplace training, but its underlying lesson transfers cleanly: a controlled asset should not change without evaluating the downstream consequences and recording the decision. NIST also notes that the rigor can vary with organizational risk and system impact.

Apply that lifecycle to training in seven stages:

1. Approve the source. Assign the SOP an owner, version, effective date, review date, status, and approval record. A draft or superseded document should not silently feed active training.
2. Register the dependencies. Connect the source to each course and, where feasible, to specific lessons, activities, questions, job aids, and performance checks.
3. Capture the change. Preserve the old version and record what changed, why, when it becomes effective, and who authorized it.
4. Review the impact. Determine whether the change affects facts, sequence, decisions, responsibilities, exceptions, hazards, legal obligations, system steps, or assessment answers.
5. Update and test affected artifacts. Revise only what the impact analysis identifies, then verify links, scenarios, assessments, accessibility, and learner flow.
6. Reapprove the release. Route the new course version to the source owner and any required learning, operations, compliance, legal, safety, or quality reviewers.
7. Notify or retrain and preserve the record. Assign the appropriate action to affected people, monitor completion when required, and retain the evidence behind the decision.

The process should also support urgent changes. A company may need to communicate a critical instruction before a full course revision is ready. In that case, issue a controlled interim notice, identify the affected population, record acknowledgement or training as appropriate, and reconcile the formal course as soon as practical. “Emergency” should shorten the path, not erase it.

Build a dependency register before you need it

A dependency register is the practical backbone of this lifecycle. It can begin as a controlled spreadsheet, but it should behave like a small data model rather than a loose list of filenames.

Record	Minimum information
Source	ID, title, owner, version, status, approval date, effective date, next review date
Course	ID, owner, risk level, status, current version, approval date
Dependency	Source version, course version, affected lesson or artifact, nature of dependency
Change	Previous and new source versions, summary or diff, reason, effective date
Impact decision	Affected artifacts and people, risk assessment, required action, rationale
Release	Updated artifacts, reviewers, approvers, approval dates, publication date
Learner action	Notification or retraining assignment, due date, completion and assessment evidence

Lesson-level mapping takes more effort than course-level mapping, so use risk to decide the depth. A low-risk reference course may only need a source-to-course relationship. A safety, clinical, financial, or compliance course may justify mapping individual source sections to instructions and scored answers.

This is also where reusable sources become more than a content-production convenience. A source should be a managed object with ownership, history, and visible downstream uses. LoreGraph's July 2026 Product Update describes source reuse, versioning, change detection, ownership, and downstream updates as important directions for a stronger knowledge-to-training system.

Decide whether to edit, notify, or retrain

Do not use word count as the decision rule. A one-word change from “may” to “must” can matter more than a rewritten page of background information.

Evaluate the change across five questions:

1. Behavior: Must someone perform a task differently?
2. Decision: Does a trigger, threshold, exception, or escalation path change?
3. Risk: Could using the old instruction harm a person, customer, product, record, or operation?
4. Obligation: Does a law, regulation, contract, accreditation rule, or internal control require new knowledge or documented training?
5. Evidence: Would the organization need to show that affected people understood the new requirement before performing the work?

Then choose the smallest action that controls the actual risk:

Change impact	Typical action	Examples
No learning impact	Record “no training impact”	Formatting, grammar, document owner title
Minor clarity change	Update the course; optional notice	Clearer wording that does not alter an action or answer
Material knowledge change	Update affected content and notify targeted people	New definition, responsibility, deadline, or system location
Material performance change	Targeted retraining with practice or verification	Changed sequence, decision rule, exception, or escalation path
High-risk or mandated change	Controlled retraining before affected work, when required	New hazard, safety control, regulated step, or critical prohibition

These are governance defaults, not legal conclusions. For example, OSHA's Process Safety Management rule applies to covered processes involving highly hazardous chemicals. Within that scope, it requires affected employees to be informed and trained in a change before startup, and it requires affected process information and operating procedures to be updated. The rule also requires a training record identifying the employee, training date, and method used to verify understanding. See 29 CFR 1910.119.

Other rules use different triggers. OSHA's Hazard Communication standard requires training when a new chemical hazard that employees have not previously been trained about enters their work area—not simply whenever any sentence changes. See 29 CFR 1910.1200(h). These examples illustrate why retraining should follow the applicable requirement and the operational impact, not a blanket rule.

Preserve evidence without freezing the system

Updating a course should create a new version, not erase the old one. The historical record must show what employees were expected to know at a particular time.

Preserve at least:

• The approved source version and effective period
• The course version and its mapped source version
• The change description or controlled comparison
• The impact analysis, including a “no retraining” decision and rationale
• The names or roles of reviewers and approvers, with dates
• The affected audience and method used to identify it
• The notice, acknowledgement, retraining, practice, or assessment assigned
• Completion, assessment, and verification records required by policy or law
• The publication, supersession, withdrawal, and retirement dates

Retention is not one-size-fits-all. Define it with records management, privacy, legal, compliance, and operational owners. Keep enough information to demonstrate the decision and the learner's applicable training state, but avoid collecting personal data with no clear purpose or retention rule.

Regulated environments show why source approval, training currency, and historical evidence must connect. Current US drug-manufacturing rules, for example, require changes to specified written procedures to be reviewed and approved by appropriate units and require continuing training in current good manufacturing practice and applicable written procedures. See 21 CFR 211.100 and 21 CFR 211.25. Those requirements are industry-specific, but they demonstrate the broader governance problem: an approved procedure, current training, and proof of qualification cannot live in separate worlds.

A worked example: one change, three actions

Consider a hypothetical non-medical home-care agency. Its incident-reporting SOP changes the escalation timing and assigns a new responsibility to the on-call supervisor.

The dependency register shows that the SOP supports a caregiver onboarding course, a supervisor course, and a downloadable job aid. The impact review maps the change to one caregiver lesson, two supervisor scenarios, three scored questions, and the job aid.

The agency does not rebuild every course from scratch. It updates the affected content, retires the invalid questions, tests the revised scenarios, and sends the new versions to the operations owner and training owner for approval.

Its audience decision is also targeted:

• Active caregivers receive a short update and a decision-based knowledge check.
• On-call supervisors complete the revised scenario practice because their responsibility changed.
• New hires receive only the new onboarding version.
• Office employees with no incident-response role receive no assignment, and that exclusion is recorded.

This example does not establish what any real agency is legally required to do. It demonstrates the framework's purpose: connect the changed source to affected content and people, then choose evidence proportionate to the change.

Common failure modes

Relying only on annual review dates. A course can become wrong the day after its review. Calendar reviews are a backstop; source-change triggers are the faster control.

Overwriting the existing course. This destroys the ability to prove what a learner completed and which instructions were active at the time.

Retraining everyone after every edit. Blanket reassignment creates noise, wastes time, and teaches employees that training alerts are administrative clutter.

Updating lessons but not assessments. A revised lesson paired with an old “correct” answer makes the course internally inconsistent.

Letting AI infer the impact alone. AI may help compare versions and suggest affected passages, but accountable owners should confirm materiality, audience, approval, and retraining decisions.

Treating acknowledgement as understanding. A click may document receipt. It does not show that someone can apply a changed decision or procedure. Match the verification method to the performance risk.

A practical change-review checklist

When an SOP changes, ask:

• Is the new source approved, owned, versioned, and effective-dated?
• Which courses, lessons, questions, scenarios, job aids, and checklists depend on it?
• What behavior, decision, responsibility, risk, or obligation changed?
• Which people perform the affected work now or will perform it soon?
• Is an update, notice, acknowledgement, practice activity, assessment, or retraining assignment appropriate?
• Who must review and approve the revised learning content?
• Can the organization show which source and course version each learner received?
• Have old versions been preserved, superseded, or retired without remaining accidentally active?
• Is there a follow-up measure to confirm that the new process is being used correctly?

Start with one high-value SOP and build its dependency map. If you cannot trace that document to the lessons, assessments, owners, and learners that rely on it, your first job is not generating more training. It is repairing the chain of trust.

Sources and further reading

• CDC Quality Training Standards
• NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems
• OSHA 29 CFR 1910.119: Process Safety Management
• OSHA 29 CFR 1910.1200: Hazard Communication
• 21 CFR 211.100: Written procedures; deviations
• 21 CFR 211.25: Personnel qualifications