An auditor doesn’t just ask whether you have a policy. They ask who approved it, when, what version was in effect at a given point in time, and whether anyone can produce the one before it. The most common cause of an audit finding isn’t a missing program – it’s not being able to answer those questions fast, on the spot, with a record instead of a guess.
What Auditors Actually Ask For
- Who approved this document, and when.
- What version was in effect on a given date.
- What changed between versions, and why.
- Evidence that a document control process is actually being followed – not just described in a policy binder.
How HACCP Builder Answers It
Every time an SOP, SSOP, or a HACCP Plan record – Business Information, Program Overview, your HACCP Team roster, Process Overview – gets edited, at either the facility or corporate level, HACCP Builder automatically records who made the change and when. Nothing extra to fill out, no separate log to maintain – it happens as part of the normal edit-and-save workflow your team already uses.
The Previous Version Is Never Gone
HACCP Builder archives the version of a document as it existed right before each edit, so the prior version is never overwritten or lost. Pull it up any time to see exactly what a document said before a given change – not a reconstruction, the real thing.
A Real Record of What Changed, and Why
Whoever makes an edit can optionally note what changed and why, right at the point of the edit. That turns your document history into something an auditor can actually read – who changed what, when, and their own words on why – instead of a stack of raw before-and-after diffs.
Built In, Not Bolted On
This isn’t a separate compliance module you have to remember to use. It runs underneath your Documents and Plan Index editing exactly as they already work today, so the evidence builds itself while your team does its normal job.
Documents Stay Editable. Records Don’t.
Everything above is about documents – SOPs, plans, program overviews. Those are supposed to change, and the job of document control is to keep an honest history of how they changed.
An operational record is a different thing entirely. A completed checklist or a log entry isn’t a living document; it is evidence of what was true at a particular moment. And a record that anyone can quietly edit afterward is not evidence at all.
A 24-Hour Window to Correct Your Own Entry
When an employee submits a checklist or a log entry, they have 24 hours to go back and correct their own mistake – a mistyped temperature, a missed comment. People do make errors, and forcing them to live with one is its own kind of bad record.
That correction window belongs to the person who made the entry. A manager cannot reach into someone else’s record and change it, even inside the window.
After 24 Hours, It Is Permanent
Once the window closes, the record is static. Not editable by the employee, not by their facility manager, not by corporate, and not by us. If something later turns out to be wrong, the path is a new entry that references the original – never a quiet edit to the old one.
This is deliberate, and it is the point. A system where records can be changed after the fact is a system where records can be changed after the fact – which is exactly what someone reviewing your compliance history in a dispute will want to know. If the record cannot be altered, it cannot be dressed up later.
Employees Respond. They Don’t Author.
The same principle runs through how entries get made in the first place. Employees answer what corporate and facility management have defined – the checklist questions, the corrective action options, the logs that apply to their area. They can add their own comments in the open fields, but they cannot change the questions or invent the choices they are picking from. What they can do is respond honestly and on time, and that response is then fixed.
Two Different Histories, on Purpose
So the system keeps two kinds of history, because the two kinds of information need different treatment:
- Documents and programs – editable indefinitely, with every version kept and every change attributed. Your SOPs should improve over time.
- Operational records – correctable briefly by their author, then frozen. What happened on the floor last Tuesday should not improve over time.
Most systems apply one model to both, and it is almost always the wrong one for half your data.
Why This Matters for GFSI Readiness
Document control, with real version and approval history, is one of the core requirements every GFSI-recognized scheme shares – SQF, BRCGS, FSSC 22000, and IFS all ask for it in some form. See how it fits into the bigger GFSI-recognized schemes picture, or contact HACCP Builder to see it on your own documents.
We can be reached at (866) 577-4030 ext. 800 or via email at [email protected]. Leave us a message or book a free demo today!





