Who Can Change Your Quality Records? Reviewing Access Beyond the Permissions List

A permissions list can show who appears to have access. It does not, by itself, explain whether that access still makes sense for the work a person is expected to do.

An access review connects the two: the records and actions in scope, the responsibilities people have now, and the decision about whether their access remains appropriate. It is a review of context and evidence—not just a check that names are present in a system.

This article offers practical questions for planning and recording that review. It is not a legal checklist, a validation protocol, or a determination that a particular system or process is compliant. Apply your organisation’s approved procedures and the requirements relevant to its intended use.

Start with the decision you need to make

Before looking at permissions, define what the review covers:

• Records and systems: Which record types, workflows, and systems are in scope?
• People and responsibilities: Which roles or individuals need to be considered, and what are their current approved responsibilities?
• Access in view: Which actions matter for those records—for example, viewing, changing, approving, or administering them?
• Evidence and period: What information will support the comparison, and what period or change event prompted the review?
• Decision owner: Who is responsible for reaching and documenting the conclusion?

These boundaries make the review understandable. Without them, a list of accounts or permissions can be difficult to interpret: it may not be clear what records it relates to, which actions matter, or what “appropriate” means in that context.

There is no universal review frequency offered here. Use the timing and depth established by your organisation’s approved process and relevant risk assessment; a material change in responsibilities may also prompt a review under that process.

Compare access with current responsibilities

For each person or role in scope, ask whether the access being reviewed has a clear connection to current responsibilities. Consider changes such as:

• a person moving into or out of a role;
• responsibilities changing while the person remains in the same team;
• temporary work or cover arrangements reaching their end;
• a person leaving the organisation or no longer needing a particular responsibility; and
• elevated or administrative access that needs a specific, current rationale.

Treat these as prompts to investigate, not automatic findings. A role title alone may not explain what someone does, and an unfamiliar permission does not prove misuse. Where the evidence is unclear, identify who can explain the responsibility or access decision and keep the question open until it is resolved.

If access is represented through groups, inherited permissions, or another mechanism, use the evidence available in your environment to understand what access is actually in scope. This is a review question, not an instruction to configure a particular platform or permission model.

Ask whether the evidence tells a coherent story

For each access decision, look for enough context to understand:

1. Who the access relates to.
2. What records or actions it covers.
3. Why the access supports a current responsibility.
4. What changed, if the person’s role or circumstances changed.
5. Who decided to retain, change, or escalate the access, and on what basis.

The answers may be recorded across approved sources rather than in one list. The important point is to make the relationship between responsibility and access traceable. If sources disagree, record the discrepancy and its owner instead of silently choosing one.

In the United States, where 21 CFR Part 11 applies to covered closed-system electronic records, §11.10 includes access limitations and authority checks among its controls. That provision is not a universal access-review schedule or a checklist for every organisation; applicability and implementation depend on the circumstances. Other jurisdictions and requirements are outside the scope of this short practice guide.

A fictional role-change example

Imagine that a fictional quality specialist moves from preparing records to coordinating a review process. The access information shows the specialist still has an action associated with the former responsibility.

That observation is a question, not a conclusion. The reviewer checks the current approved responsibilities and asks the relevant process owner whether the access is still needed for handover, retained work, or another documented reason. If it is no longer justified, the reviewer records the decision and routes any change through the organisation’s approved process. If the reason remains unclear, the item stays open with an owner and follow-up.

The review record should show what evidence was considered and why the conclusion was reached. It should not imply that an unexplained entry proves improper activity or that a completed review guarantees compliance.

Record the decision and follow-through

A useful review record lets someone understand the reasoning later. Depending on your approved process, record:

• the review scope, evidence sources, and period;
• the responsibilities used as the comparison point;
• access that was retained, changed, or escalated, with the rationale;
• unresolved differences or missing evidence;
• who owns each follow-up and when it will be revisited under the applicable process; and
• the reviewer and any required approval or acknowledgement.

Close the loop on follow-up. A decision to change access is not the same as evidence that an authorised change was completed and checked. Likewise, a decision to retain access should have a documented reason that can be understood without relying on the reviewer’s memory.

Keep the review proportionate and bounded

An access review is easier to sustain when its scope, responsibilities, and decision criteria are clear. Start with the record types and actions that matter to the process, use evidence that is appropriate to that scope, and direct technical configuration questions to the team that owns the system.

For broader context on governance of data and systems, see QikSolve’s data and system governance guidance. That page owns the product-depth discussion; this article stays with the corporate-level review practice.

Source note

The limited US regulatory reference above is a paraphrase of 21 CFR 11.10, retrieved from the eCFR version available for 2026-10-08 on 2026-10-12. The cited section is titled “Controls for closed systems.” The practical questions in this article are suggestions, not quotations from that regulation.