Document revision log template
A document revision log template, also called a change log: track a change to any controlled document from request through a pending entry, implementation and verification to a closed, dated record.
How it works
Rename the lanes to your own roles
Replace Requester, Log owner, Author, Reviewer and Auditor with the roles you actually have. In a small team the log owner and reviewer are often the same person; keep them as one lane rather than drawing a review that never happens. If more than one person can author a change, keep Author as a role rather than naming individuals, so the chart survives staff turnover.
Decide what counts as a loggable change
Not every edit needs an entry: fixing a typo is different from changing a control limit. Set a threshold at the "Change approved for logging?" decision, for example material changes to scope, responsibility, numbers or requirements get logged and formatting or spelling fixes do not, and write the threshold down, because "material" is the word every argument about this decision comes back to.
Fix your entry-numbering scheme
At "Assign entry number and link the document", decide whether entry numbers run per document, change #4 to this policy, or as one sequence across the whole log. Per-document numbering reads better inside a single document's own history; a single sequence is easier to search and report on across the whole register.
Write the before-and-after standard
"Record before-and-after description, author and date" is only useful if every entry meets the same bar. Require the previous wording or value, the new wording or value, who made the change and the date, in that order, so an auditor sampling entries reads the same shape of record every time regardless of who wrote it.
Set what verification actually checks
Give the reviewer a concrete test at "Compare the log entry against the implemented change": open the document, find the change, and confirm the entry's before-and-after text matches what is actually there. A check that only proofreads the log entry is not verification against the document.
Define your audit sampling rule
"Sample closed entries in periodic audit" needs a stated frequency and sample size, for example ten entries a quarter or every entry above a defined risk tier, set in your audit programme rather than decided ad hoc whenever someone asks for evidence.
Frequently asked questions
What is a document revision log?
It is a chronological record of every change made to a controlled document, separate from the document itself: who requested the change, who implemented it, a before-and-after description of what changed, the date, and whether it was verified against the actual document. Some organisations call the same record a change log; both terms describe a running history of changes rather than the document's current content.
Is a document revision log the same as a change log?
Yes, in the sense that both describe a running record of changes rather than current content. "Revision log" is more common in quality and regulatory settings tied to a specific controlled document; "change log" is used more broadly, from a single policy to a shared reference table. This template models the generic lifecycle behind either name: request, pending entry, implementation, verification, closed entry.
How is this different from a document's own version history?
A document's version history usually lives inside the file or its metadata and shows the sequence of numbered versions issued. A revision log is a separate register that can sit across many documents at once and records the change activity itself, who touched what and when, rather than only the resulting version number. Many organisations keep both: the document carries its version number and effective date, and the log carries the narrative of every change that produced them.
Who should verify a logged change?
Someone other than the person who implemented it. The point of the "Verified against the document?" decision is an independent check that the before-and-after description in the entry actually matches what changed in the document, not a second opinion from the same person who wrote both. In a very small team this can be the log owner rather than a dedicated reviewer, but it should not be the author checking their own entry.