Security in a cloud QMS comes down to two questions: who can move a document between lifecycle states, and who can read the record of what happened after they did. Everything else — encryption, hosting, uptime — is table stakes that any reasonable cloud platform already provides. The part that's specific to ISO document control is access control mapped to your actual decision gates, and an audit trail nobody can quietly edit.
This gets skipped over in a lot of QMS security conversations, which tend to default to generic checklist language about "enterprise-grade security" without saying what that means for a document that can only be released by two specific people. If a system can't answer "who was allowed to approve this, and can I prove only they did," the encryption standard behind it is beside the point.
Access control means gate-mapped permissions, not generic roles
Most software access control is built around generic roles — admin, editor, viewer — that don't map cleanly onto how ISO 9001 document control actually works. Document control access isn't really about who can "edit" a document. It's about who can trigger each of the decision gates your SOP already defines, and who can only observe.
A cloud QMS built around your real document lifecycle should let you define permissions in terms your SOP already uses, not generic app roles:
- Who can submit a change request (usually broad — anyone can propose)
- Who can act as reviewer at the first gate (usually a defined role, not everyone)
- Who can act as approver at the content-adequacy gate (usually narrower still)
- Who can execute the final combined sign-off that releases a master document
- Who can only read the register and the activity log, without any write access at all
This maps directly onto the four gates that hold in any properly built automation — reviewer sign-off, approver check, and the combined final gate covering master and external/support documents. The permission structure isn't a separate security layer bolted onto the workflow; it's the same structure the workflow already enforces, applied to who's allowed to trigger which step.
The folder is the access boundary, not just the workflow trigger
In a system where document lifecycle state is mirrored by real folders — draft, under review, approved, cancelled, and so on across a defined lifecycle — folder permissions and workflow permissions should be the same thing, not two systems that can drift out of sync. If someone has write access to a folder but isn't a defined approver in the workflow, that's a security gap disguised as a convenience.
This is also where "who moved the folder" earns its place as a security question, not just a process one. Moving a document into an approved-state folder is the human decision that triggers everything downstream — the register writes, the distribution update, the retention clock. Restricting who can perform that move is functionally identical to restricting who can approve a document, which means folder-level permissions deserve the same scrutiny as any approval role, not looser scrutiny because it "just" moves a file.
Why cloud QMS security starts with who owns the environment
The security question most QMS vendors don't want asked is: whose environment is this actually running in? A system built to be client-owned — deployed in your own Google Workspace and your own automation instance, not a shared multi-tenant SaaS platform run by the vendor — means your document data, your access logs, and your permission structure live inside infrastructure you already control and can audit independently. No vendor lock-in also means no dependency on a vendor's continued existence, pricing, or security posture to keep your own records accessible.
This is a genuinely different security model from a typical SaaS QMS, where your document control data lives on a vendor's shared infrastructure and your access to your own audit trail depends on your contract with them staying active. Client-owned deployment doesn't replace good access control practice — it just means the boundary of what you're securing is entirely your own, not shared with a vendor's other customers.
The activity log as a security control, not just a compliance artifact
Every automated write — the eight fields a document controller used to retype by hand — should be individually logged to an activity log, timestamped, and tied to the human event that triggered it. That log serves two purposes at once: it's the audit evidence ISO 9001 wants, and it's a security control, because it makes unauthorized or out-of-process changes visible rather than silent.
A well-built activity log should be:
| Property | Why it matters for security |
|---|---|
| Append-only | A tampered or deleted entry is itself detectable |
| Tied to the triggering human event | Every write traces back to a named decision, not an anonymous system action |
| Readable by more people than can write to it | Oversight (QMR, auditor) shouldn't require write access |
| Separate from the register it logs | A compromised register doesn't erase its own history |
This is also why idempotency matters for security, not just data integrity. A workflow that's idempotency-keyed means replaying the same approved event — accidentally or maliciously — doesn't duplicate register entries. That closes off a specific manipulation path: nobody can inflate or corrupt a register by resubmitting the same approval multiple times.
What automation should never be allowed to touch
No level of access control changes the underlying rule: automation doesn't get a permission level that lets it approve content. There's no admin role, no override, no emergency-bypass setting that should let a system mark a document adequate on its own. Every permission structure in a properly built automated QMS exists to control which humans can trigger which gate — never to create a path where the system substitutes for one.
FAQ
Can an admin override the approval gates in an automated QMS?
An admin can typically manage who holds which role, but shouldn't be able to grant a document approval on the system's behalf, or approve content without going through the same gate a designated reviewer or approver would use. If a system offers an "admin override" that skips a gate, that's a design flaw, not a feature.
Who should be able to read the activity log?
Broader than who can write to it — typically the QMR, internal auditors, and document control, even though only a smaller set of people can trigger the events being logged. Read access to the audit trail is oversight; write access is execution.
Does a cloud QMS mean our data sits on someone else's servers?
Not necessarily. A client-owned deployment runs inside infrastructure you already operate — your Google Workspace, your automation instance — so "cloud" describes where the software runs, not who controls the data.
How does idempotency relate to security rather than just data quality?
It closes a manipulation path. Without it, resubmitting or replaying an approved event could duplicate register entries, whether by accident or by someone testing the system's edges. An idempotency-keyed workflow makes replay attempts inert.
What's the difference between folder permissions and workflow permissions in this kind of system?
In a well-built system, there shouldn't be a difference — moving a document between lifecycle-state folders is the trigger for the workflow, so folder write access and workflow trigger access need to be the same permission, checked the same way.
If you want to see how gate-mapped access control would actually map onto your own reviewer and approver list, that's a conversation worth having with your real roles in front of you. Book a free consultation with 1% EVO. Bring your current sign-off list; we open a running system and walk it through, live.