Access Reviews That Actually Catch Problems in GxP Systems

Why Most Access Reviews Find Nothing

Ask a quality team how its last access review went and the answer is usually the same: completed on time, signed by the system owner, no findings. Then ask how many accounts were removed or changed as a result. In many organizations the honest answer is none, or close to none, cycle after cycle. A review that never changes anything is either reviewing a perfect system or not looking at the right things. In our experience it is almost always the second.

The pattern is easy to recognize once you know where to look. An administrator exports a list of user names, sometimes from the system and sometimes from a spreadsheet the administrator maintains by hand. A manager scans the names, recognizes most of them, and signs. Nobody opens the role definitions. Nobody compares the list with the HR record of who left last quarter. Nobody asks why eleven people hold administrator rights in a chromatography data system that needs two. The signature is real, the date is real, and the review has checked almost nothing.

What Inspectors Keep Finding

FDA warning letters show what happens when access is not reviewed in a meaningful way. They are worth reading closely, because each one describes a condition that a working access review would have surfaced long before an investigator arrived.

In a March 2022 warning letter to an over-the-counter drug manufacturer, FDA described a stand-alone computer that controlled a microbiological testing instrument used for drug product release testing. FDA wrote: “All QU users utilized a shared generic account to access the computer which had administrative privileges capable of changing and deleting files.” During the inspection, an employee opened the computer’s recycle bin and found deleted files and folders. FDA redacted the number of deleted items in the published letter.¹

In a September 2025 letter to an over-the-counter drug manufacturer, FDA reported that “System Administrator” was the only user type that could be attributed in the laboratory software, and that laboratory staff shared a common password for both the Windows operating system and the software itself. Audit trails were not reviewed at any set frequency. The firm told FDA that it had never had a formal data integrity procedure.²

An August 2025 letter to another manufacturer said the firm “did not appropriately control administrative privileges for file modification and deletion” in the data system for its liquid and gas chromatography instruments used for release testing. The firm committed to updating user access and permissions for all laboratory instruments.³

An August 2025 letter to a contract analytical laboratory records the laboratory’s own response: it would create individual logins on its computers and was looking into technology with audit trail capability. That commitment suggests the laboratory’s computers did not have individual logins at the time of the inspection.⁴

These letters went to over-the-counter drug manufacturers and a contract testing laboratory, not to large innovator pharma companies. It would be a mistake to read that as a sign that larger organizations are immune. Larger companies have more systems, more roles, more contractors, and more vendor connections, so the same conditions have more places to go unnoticed. What they usually have in addition is a formal review process that produces a signed record. The question is whether that record reflects a real check.

Three Reasons the Check Stays Shallow

The first reason is ownership. Access reviews often fall between IT, which runs the accounts, and quality, which owns the GxP risk. IT treats the review as a quality form. Quality treats the accounts as an IT matter. The business manager who signs has neither the technical view nor the regulatory context to question what they see.

The second reason is that the review is designed around people, not permissions. A list of names answers “should this person still be here?” It does not answer “what can this person do?” Most of the findings in the letters above are about what users could do: delete data, change settings, act as administrator. A names-only review cannot see any of that.

The third reason is volume. A large organization may have dozens of GxP systems and thousands of accounts. When the review is a long spreadsheet sent to busy managers once a year, it gets the attention a long spreadsheet gets. The fix is not more effort spread evenly. It is focused effort on the accounts and roles that carry the most risk, which is the subject of the rest of this article.

What the Regulations Ask For

No regulation uses the phrase “user access review” as a single, defined procedure. The expectation is built from several requirements that, taken together, only work if someone checks access on a recurring basis. It helps to know exactly which requirement supports each part of the review, because that is how an inspector will read your procedure.

United States

21 CFR Part 11 covers electronic records and electronic signatures. Section 11.10(d) requires “Limiting system access to authorized individuals.” Section 11.10(g) requires authority checks so that only authorized people can use the system, sign records, alter records, or perform the operation at hand.⁵ For electronic signatures based on user IDs and passwords, section 11.300 requires that no two people share the same combination, and it requires “Ensuring that identification code and password issuances are periodically checked, recalled, or revised.”⁶ That last requirement is the closest Part 11 comes to naming a periodic check.

For drug manufacturing, 21 CFR 211.68(b) requires appropriate controls over computer systems so that only authorized personnel make changes to master production and control records or other records. FDA cited it in the March 2022 and August 2025 manufacturer letters described above. In the September 2025 letter, FDA raised the shared password and “System Administrator” findings under the quality unit’s responsibilities in 21 CFR 211.22.^{1, 2, 3}

FDA’s 2018 guidance, Data Integrity and Compliance With Drug CGMP: Questions and Answers, fills in how the agency reads those rules. It recommends restricting the ability to change specifications, parameters, data, and methods by technical means where possible. It states: “The system administrator role, including any rights to alter files and settings, should be assigned to personnel independent from those responsible for the record content.” It also says manufacturers should document authorized personnel’s access privileges for each CGMP computer system, for example by keeping a list of authorized individuals. On shared accounts it is direct: “When login credentials are shared, a unique individual cannot be identified through the login and the system would not conform to the CGMP requirements in parts 211 and 212.”⁷

European Union

The EU GMP Annex 11 in force today is the January 2011 version. Clause 12.1 requires physical or logical controls that restrict access to authorized persons. Clause 12.2 ties the extent of security controls to the criticality of the system. Clause 12.3 states: “Creation, change, and cancellation of access authorisations should be recorded.” Clause 11 requires periodic evaluation of computerized systems, and lists security among the topics that evaluation should include.⁸

The draft revision of Annex 11, released for public consultation in 2025, is far more specific. Its section 11, “Identity and Access Management,” has eleven clauses. It says all users should have unique and personal accounts, and that shared accounts other than read-only ones are a violation of data integrity. It says access should be granted, changed, and revoked in a timely manner as people join, change, and end their involvement in GMP activities. It names two guiding principles: segregation of duties, meaning that users involved in GMP activities do not hold administrative privileges, and least privilege. Clause 11.11, “Recurrent reviews,” is the most direct statement of the access review expectation in any GMP text. It says managers should confirm the continued access of their employees “in order to detect accesses which should have been changed or revoked during daily operation, but were accidentally forgotten,” that roles should be reviewed the same way, that reviews should be documented with appropriate action taken, and that review frequency should match the risk of unauthorized changes.⁹

Clinical Systems

For systems used in clinical trials, EMA’s Guideline on computerised systems and electronic data in clinical trials has a full annex on user management. Annex 3 requires a documented process to grant, change, and revoke access in a timely manner. Clause A3.2, “User reviews,” says an overview of current and previous access, roles, and permissions should be available from the system, that it should be verified at suitable intervals, and that “There should be timely removal of access no longer required, or no longer permitted.” Clause A3.3 says users with privileged access should be sufficiently independent from the conduct of the trial and from generating, changing, and reviewing data, and that unblinded information should be visible only to pre-identified roles. Clause A3.5 calls shared group accounts unacceptable.¹¹

Read together, these sources describe a review with four parts: who has access, what each role can do, who holds special access, and how quickly access changes when people’s work changes. The rest of this article takes each part in turn.

Setting Review Frequency by Risk

The first design decision is how often to review. Here the regulations are deliberately open. The draft Annex 11 says frequency should be commensurate with the risks and consequences of unauthorized changes.⁹ EMA’s clinical guideline says “suitable intervals.”¹¹ NIST’s security control catalog, SP 800-53, leaves the frequency of account reviews and privilege reviews to be defined by each organization.¹² None of them gives a number.

That openness is useful, but only if you use it. A single annual review for every system treats a read-only reporting portal and a batch release system the same way. An inspector will ask how you chose the frequency, and “it has always been annual” is not a risk-based answer.

A Tiered Approach

The table below is the tiering we recommend as a starting point. It is our practice, not a regulatory requirement. Adjust it to your own risk assessment, and write the reasoning into your procedure so the frequency can be defended.

Event-Driven Reviews

A calendar is not the only trigger. Some events change access risk enough to justify a targeted review outside the normal schedule:

• A major software upgrade or configuration change, because role definitions and default permissions can change during an upgrade without anyone requesting it.
• A reorganization, site closure, or large reduction in staff.
• A change of hosting provider, managed service provider, or support vendor.
• A merger, acquisition, or divestiture that moves people and systems between companies.
• A data integrity deviation or security incident involving the system.
• An inspection or audit finding about access at any site, because the same weakness usually exists elsewhere.

Keeping the Volume Manageable

Tiering does not mean doing four times the work. It means moving effort from low-risk accounts to high-risk ones. Many identity management platforms can schedule recurring reviews at set frequencies, notify reviewers, and record their decisions. Microsoft’s documentation for Entra ID access reviews, for example, describes reviews that recur weekly, monthly, quarterly, or annually, and suggests them for privileged roles and for guest accounts that no longer need access.¹³ Tools like these help, but they do not know which permissions inside a LIMS or chromatography data system are GxP critical. That knowledge has to come from the system owner and quality, and it has to be written into the review.

Review What a Role Can Do, Not Just Who Has It

This is the part of the review most organizations skip, and it is the part that would have caught most of the conditions in the warning letters. In each letter, the problem was not only who had access. It was what that access allowed. Quality unit users shared a generic account that could change and delete files. Every user was an administrator. Nobody had separated the people who generate results from the people who control the system.^{1, 2, 3}

The draft Annex 11 addresses this directly: if accounts are managed through roles, the roles themselves should be reviewed and their access confirmed, in the same way individual accounts are.⁹ NIST SP 800-53 makes the same point in its least-privilege control, which calls for periodic review of the privileges assigned to roles to check that each privilege is still needed, and for removing privileges that no longer are.¹²

Start With an Approved Role Matrix

You cannot review role content without something to compare it to. The foundation is a role and permission matrix, approved by the system owner and quality, that lists every role in the system and every permission each role holds. It should be a controlled document, tied to the validated configuration, and updated through change control.

For each role, the matrix should answer a few plain questions:

• Can this role create, change, or delete GxP data? Which data?
• Can this role change system settings, methods, specifications, or limits?
• Can this role approve or sign records? Which ones?
• Can this role see or change audit trail settings?
• Can this role manage other users?
• Can this role see unblinded or restricted data?

Compare the Live Configuration to the Matrix

The review should then compare the permissions configured in the live system with the approved matrix. This is a technical step. It needs an extract of the role configuration from the system itself, not a copy of the design document. Differences come from several places: a vendor upgrade that added new permissions to existing roles by default, a local administrator who added a permission to fix an urgent problem and never removed it, or a new role created outside change control. Any difference is either an approved change that the matrix has not caught up with, or an unapproved change that needs a deviation.

For most high-impact systems, a full role content review once a year is reasonable, with a targeted check after every upgrade. The draft Annex 11 lists configuration auditing as one way to find undocumented changes during periodic review, which is exactly what this comparison is.⁹

Check for Conflicting Permissions

Some combinations of permissions should never be held by one person, even if each permission alone is appropriate. Common examples in GxP systems:

• Acquiring or processing data and administering the system that holds it.
• Entering results and approving the same results.
• Changing a method or specification and approving that change.
• Managing user accounts and reviewing the audit trail of user management.
• Holding an unblinded role and a blinded role in the same trial.

FDA’s data integrity guidance recommends that the administrator role be held by people independent of the record content.⁷ EMA’s clinical guideline makes the same point for privileged users in trial systems.¹¹ NIST’s separation of duties control adds that people who administer access controls should not also administer audit functions.¹² The review should list any person who holds a conflicting combination, and each case should be removed or justified in writing with a compensating control.

Orphan, Shared, and Generic Accounts

The second thing a working review looks for is accounts that do not trace to exactly one current, named person. These are the accounts that break attributability, the “A” in ALCOA+. ALCOA+ is the set of data integrity principles that says records should be attributable, legible, contemporaneous, original, and accurate, plus complete, consistent, enduring, and available. An action taken under an account that is shared, or that belongs to nobody, cannot be attributed.

Shared Accounts

Both FDA and European regulators are clear that shared accounts that can change data are not acceptable. FDA’s guidance says shared read-only accounts are acceptable for viewing data but do not meet requirements for actions such as second-person review, which must be attributable to one person.⁷ The draft Annex 11 says shared accounts, except read-only ones, are a violation of data integrity.⁹ EMA’s clinical guideline calls shared group accounts unacceptable.¹¹

The place where shared accounts survive longest is the standalone instrument PC. The laboratory software may have individual accounts, but the Windows login on the PC is a single local account whose password is taped to the monitor or known to the whole lab. The September 2025 letter describes this exact situation: a common password for both Windows and the analytical software.² A Windows-level account on an instrument PC can often reach the data files directly, outside the application and its audit trail. Your review scope has to include operating system accounts on every computer that holds GxP data, not only the application user list.

Orphan and Dormant Accounts

Orphan accounts are found by reconciliation, not by recognition. A manager scanning names will not notice that a contractor’s engagement ended in June. The review needs a line-by-line comparison of the system’s account list against current HR records and the current contractor roster. Every account that does not match a current person is an exception to resolve.

Dormant accounts need a rule. NIST SP 800-53 includes an account management control for disabling accounts that have expired, are no longer tied to a person, or have been inactive for an organization-defined period.¹² Pick a period that fits the system, for example 90 days for high-impact systems, and disable accounts automatically where the system allows it. The review then confirms the rule worked and looks at anything the rule could not handle.

Service and System Accounts

Service accounts are easy to leave off a review because no person logs in with them. They still need an owner, a documented purpose, the smallest set of rights that purpose requires, and a check that nobody is using them interactively. EMA’s clinical guideline says accounts for human users should be readily distinguishable from machine accounts.¹¹ A clear naming convention for service accounts makes this possible, and the review should confirm that every service account on the list is still needed.

Privileged and Vendor Access

Privileged accounts deserve the most attention in any GxP user access review, because they are the accounts that can undo every other control. An administrator can change system time, create and disable users, turn off audit trails, and in some systems change data in the database directly, outside the application. EMA’s clinical guideline lists these exact powers when it explains why privileged users need to be independent from trial conduct and data.¹¹

What to Check for Every Privileged Account

For each account with administrator or equivalent rights, at the application, database, and operating system levels, the review should confirm:

• A named owner. One person, not a team mailbox.
• A documented reason. Why this person needs this level of access, tied to their job.
• Independence. The person does not generate, process, or approve GxP data in the same system. FDA’s data integrity guidance and the draft Annex 11 both set this expectation.^{7, 9}
• Separate accounts. Administrators use a separate account for administrative work and a normal account for everything else. CISA’s Cross-Sector Cybersecurity Performance Goals include this practice.¹⁵
• Activity checked. Someone independent has looked at what the account did since the last review, using the system’s access log or audit trail.

The number of privileged accounts is itself a useful measure. Track it per system over time. If it grows every quarter, the review is approving additions without asking whether older ones can be removed.

Vendor and Service Provider Access

Many GxP systems are now supported, hosted, or run by vendors. Software-as-a-service providers, instrument vendors, managed service providers, and validation contractors may all hold accounts, sometimes with administrator rights. These accounts are often invisible to the business owner who signs the access review, because they are created by the vendor or by IT under a support contract.

The security data on third-party access is sobering. Verizon’s 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled to 30 percent, and that credential abuse was the leading way attackers first got in, at 22 percent.¹⁴ A joint guide from CISA, the NSA, the FBI, and partner agencies on remote access software notes that remote monitoring and management tools used by service providers are a common target, and it tells customers of managed service providers and software-as-a-service providers: “Customers should ensure that MSP accounts are properly monitored and audited.”¹⁶

For a GxP access review, that translates into a few specific checks:

• Every vendor account is listed in the review, with the vendor, the named individual where possible, and the contract it falls under.
• Vendor accounts are individual, not a single support login shared across the vendor’s staff.
• Standing vendor access is avoided where possible. Access is enabled for a specific support ticket and disabled afterward, and the review confirms that this happened.
• The quality agreement or contract requires the vendor to tell you when its staff with access to your system leave or change roles.
• Remote sessions are logged, and someone at your company can see those logs.

The draft Annex 11 also calls for multifactor authentication for remote access to critical systems from outside controlled networks.⁹ Where vendors connect remotely, the review should confirm that this control is in place for their accounts too.

Emergency Accounts

Most organizations keep an emergency, or “break-glass,” administrator account for situations where normal administrators are unavailable. These accounts are necessary, and they are also a common gap. The review should confirm that each emergency account is disabled or its password sealed when not in use, that every use since the last review was recorded, approved, and followed by a password change, and that the account is disabled again. NIST SP 800-53 includes a control for automatically removing or disabling temporary and emergency accounts after a defined period, so that this does not depend on someone remembering.¹²

Removing Access When People Leave or Move

An access review is a check after the fact. The main control is the day-to-day process that gives, changes, and removes access as people join, move, and leave. When that process works, the review finds very little in this area. When it does not, the review is where the gaps show up. The draft Annex 11 describes the review in exactly those terms: its purpose is to find access that should have been changed or revoked during daily operation but was forgotten.⁹

Leavers

How fast is fast enough? The regulations say “timely” without a number.^{9, 11} Security guidance is more specific. CISA’s Cross-Sector Cybersecurity Performance Goals call for a defined and enforced process that disables all user accounts and access for departing employees “by the day of their departure.”¹⁵ NIST SP 800-53 requires disabling system access within an organization-defined period on termination, and revoking credentials associated with the person.¹²

For GxP systems, we recommend a target of the last working day for all leavers, and immediate removal for anyone who leaves on bad terms or is dismissed. Then measure it. The single most useful metric in an access program is the time between the termination date in the HR system and the date each GxP account was disabled. If you cannot produce that number, you do not know whether your leaver process works.

Watch for three common gaps:

• Local accounts behind single sign-on. Disabling a person’s directory account blocks sign-in through single sign-on, but many applications keep their own local account table. If those local accounts stay active, a person may still reach the system through a local login or an application interface. The review should check the application’s own user list, not only the directory.
• Contractors and temporary staff. They are often not in the HR system that drives the leaver process. Their end dates live in a purchase order or a manager’s calendar.
• Standalone systems. Instruments and systems not connected to the corporate directory need a manual step. Manual steps get missed.

Movers

People who change jobs inside the company are harder to catch than people who leave. When an analyst becomes a reviewer, or a clinical data manager moves to a different study, the new access is usually granted promptly because the person asks for it. The old access is rarely removed, because nobody asks for that. Over several moves, a long-serving employee can end up holding a set of rights that no single job needs, a pattern security teams often call privilege creep. NIST’s least-privilege control describes this: assigned privileges may need to change as business functions change, and a periodic review is needed to confirm the reason for each privilege is still valid.¹²

The fix has two parts. First, make role changes a trigger in the access process, so that a transfer creates a task to review and remove old access, not only to add new access. Second, in the periodic review, show each reviewer the person’s current job title next to their system roles, so that a mismatch is visible.

Evidence That Holds Up in an Inspection

An inspector reviewing your access controls will usually ask for three things: the procedure, the most recent completed review for a system they pick, and the list of current users and roles pulled from the system while they watch. The third request is the one that exposes a weak review, because any difference between the live list and the reviewed list needs an explanation.

What the Review Record Should Contain

• The source extract. A list of accounts, roles, and last login dates generated by the system, with the date, time, and the person who ran it. Not a spreadsheet maintained by hand.
• Scope. Which accounts were included: application users, administrators, service accounts, vendor accounts, and operating system accounts on computers that hold GxP data. If something was excluded, the reason.
• The role matrix version the review compared against.
• A decision for every line. Keep, change, or remove, by a named reviewer, with the date. Blanket approval of a whole list is weak evidence.
• Independence. Evidence that the person confirming access is the manager or data owner, not the administrator who created the accounts.
• Actions and closure. A ticket or change reference for each change and removal, and proof that it was done, such as a second extract after the changes.
• Exceptions. Written justification and a compensating control for any conflicting permission or shared read-only account that remains.
• A summary. Numbers reviewed, changed, and removed; orphan and dormant accounts found; privileged account count; and any deviations raised.

The 2011 Annex 11 already requires that creation, change, and cancellation of access authorizations be recorded.⁸ Your access request and approval records, together with the review, are how you show that. They do not need to be on paper, and they do not need Part 11 signatures unless a predicate rule requires a signature. An ISPE Pharmaceutical Engineering article on GAMP practice for IT process records argues that it is incorrect to insist that Part 11 requires a data audit trail for the maintenance of user access privileges, and that standard IT tools with access control, logging, and enforced roles can manage these records well.¹⁷ A well-controlled ticketing or identity management system is usually better evidence than a signed printout.

Connect the Review to Periodic Review

The access review should not stand alone. The draft Annex 11 lists the conduct of access reviews, and the actions from them, among the inputs to each system’s periodic review.⁹ That link matters for two reasons. It makes sure access findings are weighed alongside changes, deviations, and audit trail review when deciding whether a system is still in a validated state. And it gives the periodic reviewer a chance to notice when access reviews are late or have found nothing for several cycles in a row.

Know What FDA Asks For After a Finding

The warning letters in this article are also useful as a checklist, because they show what FDA asks a firm to produce once access controls have failed. In the August 2025 letter to the manufacturer, FDA asked for an independent assessment of laboratory computer systems that would, among other things, specify user roles and privileges for all staff levels, identify every person with administrator privileges, describe how staff who perform testing will be kept separate from those with administrator rights, and determine whether unique usernames and passwords are used on each system.³ In the August 2025 letter to the contract laboratory, FDA asked for the specific permissions of anyone with administrative rights, an explanation of how staff will be kept from holding administrative rights or other permissions that could compromise data, and confirmation that unique usernames and passwords are always used and kept confidential.⁴ If your access review already produces those answers for every high-impact system, you are in a strong position. If it would take weeks to assemble them, that gap is worth closing now.

A Seven-Step Review Cycle

Metrics Worth Tracking

A small set of measures, tracked across cycles and systems, tells leaders whether access control is working:

• Days from HR termination date to account disabled, by system.
• Number of orphan accounts found per review. This should fall over time as the leaver process improves.
• Number of privileged accounts per system, and the trend.
• Percentage of reviews completed on schedule.
• Percentage of review actions closed within the target time.
• Number of role configuration differences found in role content reviews.

A falling orphan count and a short, stable time-to-disable are signs of a healthy process. A review that finds nothing, year after year, while the privileged account count grows, is a sign that the review needs redesign.

Conclusion

A GxP user access review that catches problems is not a longer list or a more senior signature. It is a different set of questions. Who has access, and does each account belong to exactly one current person? What can each role do, and does the live configuration still match what was approved? Who holds administrator and vendor access, and are they independent of the data? How fast does access end when someone leaves or moves? The FDA findings in this article, from shared generic logins to uncontrolled administrator rights over data files, are all answers to those questions that a names-only review never asked. The regulatory texts are converging on the same expectation, and the draft Annex 11 states it more plainly than any GMP text has before.

Sakara Digital works with pharma and biotech organizations on the quality and validation controls that support trustworthy data, including access management for laboratory, manufacturing, and clinical systems. If you want an independent look at whether your access reviews would hold up to an inspector pulling the user list while you watch, we are happy to have that conversation.

For Further Reading