ISO 9001 document control runs through four human decision gates: a reviewer confirms the change request is warranted, an approver checks the content is technically adequate, and a final combined gate completes master sign-off, external and support documents included. Automation's job is to carry out what happens after each gate closes. It never stands in for the person at the gate.
Stated plainly, that sounds obvious. It gets less obvious the moment a vendor shows you a dashboard with an "auto-approve" toggle. So here are the four gates, what each one decides, and exactly where automation is allowed to touch the process.
Where the four gates come from
The gates are not a framework we invented. They are the change-control steps we found already written into a manufacturer's own SOPs during our reference build: a Thai manufacturer, ISO 9001:2015 certified across two sites. We automated around those gates, because ISO automation that ignores your existing gate structure is not automation. It is a rewrite of your quality system by a software vendor, which is exactly what you do not want.
The four gates, in sequence:
Gate 1: the reviewer marks the change-request form
Someone raises a change-request form, on paper or on screen. A reviewer, usually someone close to the process being changed, marks whether the request is legitimate and worth pursuing. This is the first filter. Not every proposed change should go further.
Gate 2: the approver checks content adequacy
Once a request clears Gate 1, an approver evaluates the actual content of the proposed document or revision. Is it technically correct? Does it conflict with another controlled document? Does it reflect the real process? This is the clause 7.5 judgment, the one no system should ever be trusted to make.
Gates 3 and 4: combined master sign-off
The final gate completes master sign-off. In the SOP we automated around, it is a combined gate: it finalises internal documents and also covers external and support documents, which many document-control systems treat as an afterthought even though they carry the same control requirements.
What "preserving a gate" means in a build
Preserving a gate does not mean adding an "approved" checkbox to an app and trusting whoever clicks it. It means the automation's trigger is the same physical or documented approval event your SOP already requires, and the automation does nothing until that event has happened and been recorded.
In the reference build, all four gates stayed exactly where the manufacturer's process had them: a reviewer marks the paper change-request form, an approver checks content adequacy, the combined gate completes sign-off. The system takes no part in those decisions. It watches for the outcome.
Only after the final sign-off does the system act, and what it does is entirely clerical. To be precise, because "acts after approval" can still sound vague: it writes eight specific fields a document controller used to retype by hand. Revision number, effective date, an amendment-record entry, a master-list row across a ten-department distribution matrix, a change-register entry, the year-keyed request number, the page count, and a calculated retention and disposal date. Every write is logged individually, and the workflow is idempotency-keyed, so one approval can never produce two register rows.
The document's lifecycle state (draft, under review, approved, superseded and so on) is mirrored in real Google Drive folders across a nine-step lifecycle. Moving a document between those folders is still a human action. The automation reacts to the move. It never decides to make it.
What crosses the line and what does not
| Automation action | Inside the boundary? |
|---|---|
| Writing the revision number after the final sign-off | Yes |
| Updating the ten-department distribution matrix after sign-off | Yes |
| Logging a change-register entry tied to a recorded approval | Yes |
| Calculating a retention and disposal date from the effective date | Yes |
| Marking a document "approved" without a recorded human action | No |
| Skipping Gate 2 for changes a script rates as "low risk" | No |
| Generating document content and self-approving it | No |
| Moving a Drive folder to advance lifecycle state on its own | No |
Every row follows the same rule: automation may act on a decision. It may never make one.
Why the boundary is worth defending
Auditors see more "AI-powered QMS" claims every year. The ones worth taking seriously can show exactly where human judgment sits in the process, rather than asserting compliance. A system that preserves four distinct, individually named gates, with every downstream write logged to an activity log, gives you a clearer trail than a hand-maintained register ever could. You can show an auditor precisely which person recorded which decision, and precisely what the system did as a mechanical consequence.
That is also why automation should never be confused with buying QMS software off the shelf. A generic platform gives you fields to fill in. It does not derive its gate structure from your SOPs, and it does not guarantee the gates match how your reviewers and approvers work today.
FAQ
Can any of the four gates be automated to save time?
No. All four are human decisions by design. ISO 9001 requires competent human review of document adequacy, and a gate that is silently skipped is a compliance gap, not a time saving.
What does automation do, then?
It carries out the clerical consequences of a gate closing: numbering, register updates, distribution updates and retention calculations. Nothing that involves judging document content.
Do gates 3 and 4 have to be combined?
In the reference build they were combined into one master sign-off covering internal and external or support documents, because that is how the manufacturer's SOP was written. Your gate structure should follow your SOP, not a vendor's template.
How do we know the system did not skip a gate?
Every automated write is logged individually, tied to the approval event that triggered it. That log is your evidence trail at audit.
Does this work if our gates are still on paper?
Yes. The reference build's gates were paper-based: a physical change-request form marked by hand. Automation picks up from the recorded outcome. It does not require your review process to be digital first.
To see how this gate structure held up in a real build, with 19 of 19 acceptance criteria passed and all 51 unrelated workflows on the same tenant verified unchanged, read the 1% EVO build record on the ISO automation page. Every rule in it came from the manufacturer's own written SOPs.