Auditing IT infrastructure in a GxP environment means checking whether the technical foundation behind regulated systems is controlled, supportable, and appropriate for its intended use. The audit should not stop at servers or network diagrams. It should test whether access, changes, backups, monitoring, and supporting services are managed in a way that protects system reliability and data integrity.
That is what makes a GxP infrastructure audit different from a general IT review.
In regulated environments, infrastructure is part of the control model. If identity management is weak, if backup recovery is untested, or if changes are made without understanding impact to regulated systems, the application may still be difficult to defend during inspection.
Why infrastructure matters in GxP
Teams often focus first on the application layer: the LIMS, eQMS, MES, CDS, or other regulated platform. But the application only works within the environment supporting it.
That environment may include:
- servers or virtual machines
- network segments
- domain services
- storage
- backup tools
- monitoring platforms
- remote access methods
- interface services
- cloud or vendor-managed components
If those supporting layers are poorly controlled, the risk is not only technical. It becomes a compliance issue. A regulated system can appear stable in daily use while still having weak infrastructure governance underneath it. That is often where audit findings begin.
What an IT infrastructure audit should cover
A practical infrastructure audit should focus on the controls that directly affect the availability, security, traceability, and recoverability of regulated systems.
1. Network and environment controls
Start by understanding the environment.
The audit should confirm:
- what infrastructure supports each regulated system
- how production and non-production environments are separated
- how data moves between systems
- what network boundaries exist
- how remote access is handled
- where shared services are used
This sounds basic, but it is often where confusion starts. Many organizations have diagrams, but they are outdated, too high-level, or disconnected from the real environment.
A useful audit should make it clear which infrastructure components support which GxP systems.
2. Access controls and user administration
Access control is usually one of the clearest indicators of whether governance is real.
The audit should review:
- how access is requested and approved
- how roles are assigned
- who has administrator privileges
- whether shared or generic accounts exist
- how leavers are removed
- whether role changes are updated on time
- whether periodic access reviews actually happen
Application access matters, but infrastructure access matters too.
A company may have clean user management inside the application while still allowing broad domain-level access, uncontrolled server administration, or poorly governed support accounts in the underlying environment.
That is often a bigger weakness than teams expect.
3. Change management and configuration control
Infrastructure changes should not be treated as low-risk just because they are technical.
Changes such as:
- patching
- firewall rule updates
- virtual server changes
- storage changes
- identity management updates
- backup configuration changes
- certificate renewals
- interface routing changes
can all affect regulated systems.
The audit should check whether infrastructure changes are:
- documented
- reviewed for GxP impact
- approved before implementation
- verified after implementation
- linked to affected systems where relevant
One common problem is that IT tickets describe the technical activity but say nothing useful about regulated impact. When that happens, the organization struggles to explain whether the validated state was considered at all.
4. Backup, recovery, and continuity
Backup is one of the most overstated controls in regulated environments. Saying that backups run every night is not the same as proving that the organization can restore the environment and recover the right data when needed.
The audit should review:
- what is included in backup scope
- whether regulated data and key configurations are covered
- retention expectations
- restore test evidence
- disaster recovery roles and responsibilities
- whether vendor-managed recovery assumptions are clearly understood
A backup control is only meaningful if recovery has been tested in a way that reflects the system’s real use.
5. Monitoring, logging, and incident handling
An audit should also look at how the environment is monitored.
That includes:
- infrastructure alerts
- logging practices
- incident escalation
- review of significant events
- investigation records
- response to recurring technical issues
If the environment is not being watched, small issues can turn into larger compliance concerns before anyone recognizes the pattern. Monitoring also matters because it supports investigations. If a system outage, time sync issue, access anomaly, or interface failure occurs, the organization needs to be able to reconstruct what happened.
A simple way to scope the audit
A useful scoping question is:
Which technical services directly support regulated processes or regulated records?
That usually gives you a more accurate audit scope than asking for “all IT infrastructure.”
Typical in-scope items may include:
- servers hosting GxP applications
- identity and authentication services
- database hosting layers
- network segments used by regulated systems
- interface or middleware components
- backup and restore tooling
- monitoring tools
- shared storage
- remote access pathways
- vendor-managed infrastructure relied on for regulated operations
What gets missed most often is not the application itself. It is the shared service layer underneath it.
Common mistakes during infrastructure audits
Auditing only from documents
A procedure can look good on paper while the live environment tells a different story. If the audit never checks real access groups, actual change tickets, restore evidence, or current architecture, it may miss the most important control gaps.
Treating infrastructure as “just IT”
In GxP environments, infrastructure is not separate from compliance. It supports the systems that create, store, move, and protect regulated records. That means infrastructure controls have to be understood in context, not treated as background utilities.
Looking only at application access
Many teams review application roles carefully but overlook the administrative access around the system. The greater risk may sit in:
- domain administration
- server access
- virtualization tools
- backup consoles
- shared support accounts
- infrastructure service accounts
Accepting vendor-managed controls too easily
If part of the environment is managed by a vendor or cloud provider, the company still needs to understand what the vendor controls and what remains internal. Problems often arise when responsibility is assumed rather than defined.
Assuming backup means recoverability
This is one of the easiest ways to overestimate control. Backup jobs may run successfully for months, but if no meaningful restore has been tested, the organization may not know whether recovery will actually work.
What auditors and inspectors really ask
During inspection, the questions are usually more practical than teams expect.
Which infrastructure components support the regulated system?
If ownership is fragmented across IT, QA, validation, and vendors, this question becomes hard to answer quickly. That usually signals weak control of the environment.
Who can administer the infrastructure?
Auditors typically want to know:
- who has privileged access
- how that access is approved
- whether it is limited by role
- how it is reviewed
- whether inactive or unnecessary accounts are removed
How are infrastructure changes assessed for impact?
This often surfaces in audits when change tickets show technical implementation but no clear thinking around regulated effect. A defensible process should show that changes were reviewed for possible impact to validated systems, interfaces, records, and operations.
Can the company restore the environment and the data?
Policy language is not enough here. Inspectors usually look for evidence that the organization can recover the system, not just claim that backup exists.
Who owns vendor-managed responsibilities?
If hosting, backups, patching, or other technical services are outsourced, auditors often ask how those responsibilities are defined and how the company oversees them. This is especially important in hybrid and cloud-connected environments.
Practical examples
A site has a validated laboratory system hosted on internal virtual infrastructure. The application documentation is complete, and the team is confident the system is under control. During the infrastructure audit, the real gap appears elsewhere: backup jobs exist, but no one can show a recent restore test for that environment. The weakness is not the application itself. The weakness is that recovery has been assumed, not demonstrated.
A biotech company uses centralized identity management for several regulated systems. On paper, privileged access is tightly controlled.During live review, several old admin accounts are still active, and one shared support account is used by multiple people. The issue is not just a process gap. It is a direct weakness in attribution, oversight, and access governance.
What good looks like
A strong GxP infrastructure audit does not try to review everything equally. It focuses on the controls that matter most to regulated operations.
In practice, that usually means the company can clearly show:
- which infrastructure components support each regulated system
- how access is approved, limited, and reviewed
- how infrastructure changes are assessed before implementation
- how backup and recovery are proven
- how monitoring and incident response work
- how vendor-managed responsibilities are defined
- how shared services are understood when they affect regulated systems
It should be clear who is responsible for access, who reviews changes, who verifies recovery, who oversees vendors, and how the environment stays controlled over time.
Final perspective
An IT infrastructure audit in a GxP environment is really a review of whether the technical foundation behind regulated systems can be trusted, explained, and defended. The strongest audits are not the ones with the most paperwork. They are the ones that show the environment is understood, the risks are visible, and the controls match how the systems actually operate.