ISO 27001 Document Security: Role-Based Access and MFA

ISO 27001 document security comes down to one question: who may see, change or approve each document, and can you prove it later? Role-based access plus multi-factor login answers that question for most teams. Below you will find how to define roles, add a second factor and keep a record auditors can trust.

Why document access is the first thing auditors probe

In our experience as an agency building software for quality teams, access questions come up early in almost every audit conversation. An auditor rarely starts with your encryption settings. They ask who can edit the procedure on screen and how that person was authorized.

The reason is simple. Most information leaks and accidental changes happen inside the organization, through shared folders, forwarded attachments and accounts nobody reviewed. A policy that says access is restricted means little if the folder permissions tell another story.

ISO 27001:2022 expects you to manage access according to need and to be able to demonstrate it. Documents are the place where that expectation becomes very concrete.

Start from roles, not from people

The most common mistake is granting permissions person by person. It feels fast on day one. A year later nobody remembers why a former intern can still approve revisions.

Role-based access control (RBAC) flips the logic. You define a small set of roles, attach permissions to each role, and then assign people to roles. When someone changes jobs, you change one assignment instead of hunting through folders.

Filezonia, our quality and document management product, works with a 6+1 role model. The point for you is not the number itself but the discipline: few roles, clearly named, each tied to a real responsibility such as authoring, reviewing, approving or read-only viewing.

Designing roles that match how your team works

Begin with the document lifecycle. Who drafts? Who checks? Who signs off? Who only needs to read the current version? Write those answers on one page before you touch any settings.

Then test the draft against separation of duties. The person who writes a procedure should not be the only person who approves it. If your team is tiny and one person must hold both roles, record that as a known exception and review it regularly.

Keep an administrator role narrow. Administrators manage the system, but they do not need to read every confidential file. Treat that distinction as a design decision, not an afterthought.

• List the document types you hold, such as procedures, records and contracts.
• Name one owner per type.
• Map each lifecycle step to a role.
• Mark any person who holds two conflicting roles.
• Review the map after every reorganization.

Zero trust: every request proves itself

Traditional setups trust anyone who is inside the network. Zero trust assumes nothing. Each request to open or change a document is checked against the user's role and session, whether they sit in the office or at home.

This matters for document security because teams are rarely in one place. A contractor on a hotel connection and an employee at a desk should face the same checks. The role decides what they can do; the verification decides whether they are who they claim.

It also limits damage. If one account is compromised, the attacker inherits only that role's permissions, not the whole archive.

Multi-factor login: what to require and what to avoid

A password alone is the weakest link in most access models. Multi-factor authentication (MFA) adds a second proof, so a leaked password is no longer enough. Filezonia uses time-based one-time codes following RFC 6238, the standard behind common authenticator apps.

Alongside the code, IP address and browser fingerprint checks help flag unusual sign-ins. A login from a device you have never seen deserves more suspicion than one from a familiar browser.

Avoid making MFA optional for privileged roles. We often see teams enforce it for everyone except managers, who happen to hold the broadest permissions. That is exactly backwards.

Permission changes belong in the audit trail too

Teams log document edits and forget to log who granted the right to edit. Yet an auditor will ask both questions. If a role was widened for a project and never narrowed again, the record should show it.

In Filezonia, permission changes are written to the same audit chain as document activity. That gives you one continuous history: who changed what, and who allowed them to.

Schedule a periodic review. Export the current role assignments, compare them to the real organization chart and remove what no longer fits. Quarterly is a sensible starting rhythm for many teams, though you should set it by your own risk.

Uploads are an access path as well

Access rights cover what goes in, not only what comes out. A file renamed to look harmless can still carry something else. Magic-byte checks inspect the real content signature of an upload instead of trusting the file extension, which blocks many disguised files.

Document control and privacy connect here too. If you already manage revisions, see our notes on ISO 9001 document control, revisions and approvals. For personal data inside files, masking and erasure in document management covers the other half of the picture.

Your next step: map roles this week, enforce MFA next

Do not wait for the audit calendar. Spend an hour this week drawing the role map described above, and remove permissions nobody can justify.

Next, turn on a second factor for every privileged role, then confirm that permission changes are being recorded. If you want a system where roles, TOTP login and the audit chain are built in, look at Filezonia quality and document management.

Finish by testing it. Ask a colleague in a read-only role to try an edit. If it fails and the attempt is logged, your iso 27001 document security is working as intended.