Version control vs change control: what's the difference
Version control tracks which revision of a document is current and what changed; change control decides whether a proposed change is allowed to happen at all, and who has to approve it first.
Version control is the mechanism that identifies and remembers successive states of a document; change control is the governance process that decides whether a change is permitted before a new version is created.
The short version
- Version control tracks identity and history: which version this is, and what came before it.
- Change control is governance: whether a proposed change is permitted, and who has to approve it.
- Change control runs first: classification and approval gate entry into a new version, not the other way round.
- A minor edit and a major edit can carry different levels of change control without changing how version control works.
- Most real processes need both, layered: change control decides, version control remembers.
Two different questions, one shared object
"Which version is this?" and "should this change happen?" are two different questions, and most process documentation only answers the first one. Version control is a labelling and history mechanism: it assigns an identifier to each successive state of a document, keeps a record of what came before it, and lets you see who changed what and when. It answers custody questions after the fact. Change control sits upstream of that: it is the governance process that decides whether a proposed change is permitted, who has to review it, and what has to be true before a new version is allowed to exist at all.
The document change control workflow below makes the boundary visible as a chart rather than a sentence. Rows 1 through 8 are entirely change control: logging the request, classifying it as minor or major, routing major changes to a reviewer who assesses the full impact, and gating everything on an "Approved?" decision. None of that touches the document's version. Only after the approval gate does "Update version number and distribution list" run, at row 9: the exact point where version control starts.
QueryChart keeps the two separate in the same way. Every edit to a chart is captured automatically in a Change Log with per-field diffs, a Compare Versions view, and one-click restore: that is version control, running whether or not anyone asks for it, at /features/version-control. Whether a given edit was allowed to happen in the first place, and who signed off on it, is the governance question a chart like the one below answers. For the fuller, more IT/ops-flavoured version of that governance process rather than the document-specific one, see /guides/how-to-create-a-change-control-process.
Version control and change control at a glance
| Aspect | Version control | Change control |
|---|---|---|
| Core question | Which revision is this, and what changed? | Should the proposed change be authorized? |
| When | Records each saved or issued state | Assesses a proposal before controlled release |
| Decision | Identifies the current and prior states | Accepts, rejects or conditions the proposal |
| Evidence | Revision log and comparison | Request, impact assessment, approval and verification |
Where change control ends and version control starts
One document's classification, review and approval, then the exact row where its version number actually changes.
A request, not yet a version change
"Change to a controlled document identified" starts the chart, then "Submit document change request" and "Log the request against the document record": three rows of change control, and the document's version is still untouched.
Classification and approval gate everything
"Change classified as minor or major?" splits into a fast-track edit or a full review where the change reviewer "assesses the full impact" and records it against related documents and forms, before the "Approved?" decision, none of it has touched the version number yet.
Row 9 is where version control begins
Only once the change is approved does "Update version number and distribution list" run, followed by publishing to the controlled location, notifying distribution list holders, and withdrawing the superseded copy: the version-control half of the process.
Rejection loops back into change control
A "Rejected" answer sends the request to "Revise the draft and resubmit for review", which returns to the change reviewer's impact assessment; rework stays entirely inside change control until "Document reissued under formal change control" closes the chart with a new version in place.
How it works
Separate the two questions in your own process
Before you draw anything, decide what belongs to change control (request, classification, review, approval) and what belongs to version control (identifier, revision number, history, restore). Naming the boundary is the design step most flowcharts skip.
Classify before you assess
Route every request through a minor/major decision before assessment begins, the way row 4 does. A minor wording fix and a major requirement change should not travel the same review path, and deciding which is which up front stops every change getting the heaviest treatment.
Put the version-control step where approval actually ends
Only increment the version number, set the effective date and update the distribution list after the approval gate, never earlier. If your chart updates the version before the decision, you have described a process that versions rejected drafts.
Give change control its own reviewer, not the document owner
A change reviewer who assesses full impact and records it against related documents and forms, separately from whoever requested the change, is what makes "approved" mean something. In the example that step sits between classification and the approval decision, not folded into either.
Let version control run itself once change control has decided
Publishing, notifying distribution list holders and withdrawing the superseded copy are mechanical once a change is approved: that is the version-control tail of the chart, and it is the half QueryChart's Change Log and Compare Versions view already handle for you at /features/version-control.
Mistakes to avoid
Treating "we have version history" as change control
A tool that timestamps every edit is not a governance process: it has no classification, no reviewer and no approval gate. Version history answers what changed; it says nothing about whether the change should have happened.
Versioning a change before it is approved
If the version number moves before the "Approved?" decision, a rejected draft still shows as a new revision. Keep the increment at row 9, after approval, the way the example does.
One category for every change
Running a typo fix through the same review as a requirement change either slows down trivial edits or lets substantive ones through on the fast track. The minor/major split at row 4 exists so both get the right amount of scrutiny; see /guides/how-to-create-a-change-control-process for how to design the categories themselves.
Related QueryChart feature
Compare versions in your own chart
Every edit to this example is already tracked automatically: open it and check the Change Log and Compare Versions view for yourself.
Related guides
Frequently asked questions
Is version control the same as change control?
No. Version control is the mechanism that identifies and remembers successive states of a document: a revision number, a history of who changed what, and the ability to compare or restore an earlier one. Change control is the governance process that decides whether a proposed change is allowed to happen, who reviews it, and what has to be true before it is approved. A document can have rigorous version control and no change control at all: every edit saved, nobody deciding whether it should have been made.
Which one should I build first?
Version control, because it is usually already running underneath you: QueryChart keeps a Change Log with per-field diffs and a Compare Versions view for every chart automatically, at /features/version-control. Change control is the part you have to design deliberately (categories, a reviewer, an approval gate) which is why it is the process worth drawing as a flowchart, like the one on this page.
How does this differ from revision control?
In practice, "revision control" and "version control" are the same mechanism under different names, both concerned with identifying and tracking successive states of a document. Change control is the different one: it governs whether a change is permitted in the first place, typically ending in a new version once approved. See /guides/revision-control-vs-version-control if it is specifically the revision-control/version-control naming question you are trying to settle.
Where does document control fit against these two?
Document control is the broadest of the three: the full lifecycle of a controlled document, from request through draft, review, approval, publication and eventual withdrawal or retirement. Change control and version control are both pieces of it: change control governs a single proposed edit, version control tracks the identifiers and history that edit produces. For the whole lifecycle rather than just the change/version boundary, see /templates/document-change-control-workflow or the broader /guides/how-to-create-a-document-control-process.