Computerized System Inventory: Building One You Can Defend

The Request That Opens the Inspection

Inspection document requests vary, but a short list of items shows up almost every time: the site organization chart, the quality manual, the deviation and change control logs for the review period, the validation master plan, and a list of computerized systems. The last item is not there because inspectors are curious about your technology estate. It is there because it is the index to everything else they plan to look at.

An inspector who has the list can do three things in the first hour. They can pick systems to sample rather than accepting the ones you offer. They can compare the systems on the list against the equipment and screens they will see when they walk the floor. And they can check whether the validation status recorded on the list is supported by a document that exists, is approved, and is current. None of those three tests require deep technical knowledge. All three are quick, and all three are hard to pass with a document that has not been maintained.

The two ways it goes wrong

The first way is the empty chair. There is no inventory, or there are several partial ones: an IT asset register that lists servers and laptops, a validation team spreadsheet that lists the systems they validated, a quality assurance list of systems with periodic reviews scheduled, and a procurement record of software purchases. Each of the four is accurate about its own slice. None of them is the list Annex 11 asks for, because none of them is scoped by GMP functionality. When the inspector asks for the inventory, someone spends the first afternoon of the inspection stitching those four together, and the stitching itself becomes visible.

The second way is more common and more damaging. The inventory exists, it looks well maintained, and it is out of date in ways the site cannot see. A system was upgraded eleven months ago and the version column still shows the old release. An interface between the laboratory information management system and the manufacturing execution system was replaced during a middleware migration and the system description still describes the old data flow. A system owner left the company in March and the name is still in the owner column. A departmental database that started as a tracking sheet has been feeding a quality metric for two years and was never assessed.

The difference between those two failures matters for how you respond, but not for how the inspector reads them. Both say the same thing about the quality system: the process that is supposed to keep this document accurate is not running.

Why this is a leadership problem, not a documentation problem

It is tempting to treat the inventory as a records exercise that a quality analyst can clean up in a week. That framing is why it keeps degrading. An inventory is the output of several other processes working correctly. It is current only if change control captures system changes, if procurement routes software purchases through a GxP assessment, if someone updates ownership when people move, and if retirement is a controlled activity rather than an unplugged server. When the inventory is wrong, one of those upstream processes is not working, and the inventory is the only place that failure becomes visible before an inspector finds it.

That is the useful way to think about it. The inventory is not a deliverable. It is a detector.

What the Rules Actually Require

Four bodies of regulation touch this, and they ask for different things. Knowing which one is driving a given field on your template keeps arguments short.

EU GMP Annex 11

Annex 11 section 4.3 is the clearest statement anywhere in GxP regulation: “An up to date listing of all relevant systems and their GMP functionality (inventory) should be available.” The same clause continues: “For critical systems an up to date system description detailing the physical and logical arrangements, data flows and interfaces with other systems or processes, any hardware and software pre-requisites, and security measures should be available.”¹

Two things in that sentence get missed. The first is the word relevant. Annex 11 does not ask for every computer at the site. It asks for the systems that are relevant to GMP, which puts the burden on you to define relevance and to defend the definition. The second is that Annex 11 sets a two-tier expectation: a listing for everything relevant, and a fuller system description only for the systems you have classified as critical. Sites that try to write a full system description for every entry stall out and end up with neither.

The official questions and answers on Annex 11 make the two tiers explicit. On how much detail belongs in the inventory itself, the answer given is that a description of the general functions is sufficient, with the detailed information held in the system description.⁸ The inventory is an index. It is not the documentation.

PIC/S PI 041-1

PI 041-1, the PIC/S guidance on good practices for data management and integrity, is written for inspectors and is therefore the most direct statement of what they will look for. Section 9.3 sets the expectation: regulated users should have an inventory of all computerized systems in use, and the list should include reference to the name, location and primary function of each system; assessments of the function and criticality of the system and associated data, for example direct GMP or GDP impact, indirect impact, or none; and the current validation status of each system with reference to existing validation documents.²

The guidance then states the risk in language worth reading twice: companies that do not have adequate visibility of all computerized systems in place may overlook the criticality of systems and may create vulnerabilities within the data lifecycle, and an inventory list serves to clearly communicate all systems in place and their criticality, ensuring that any changes or modifications to these systems are controlled.² That is the inspector’s theory of the document. It exists so that change control has a defined population to act on. An inventory that misses systems is not just an incomplete record. It is evidence that some systems are outside change control entirely.

PI 041-1 also names examples of systems inspectors should treat as critical and review: systems controlling purchasing and the status of products and materials, systems for control and data acquisition on critical manufacturing processes, systems that generate, store or process data used to determine batch quality, systems that generate data included in batch processing or packaging records, and systems used in the decision process for product release.² If your inventory contains no entries in one of those five groups, that is a gap to investigate before someone else does.

21 CFR Part 11

Part 11 works differently and this catches people out. It contains no requirement to maintain an inventory of systems. Its scope provision applies to electronic records created, modified, maintained, archived, retrieved or transmitted under records requirements set out in agency regulations, and to electronic records submitted to the agency.⁹ The definitions that follow are equally record-centered.¹⁰

So Part 11 does not ask what systems you have. It asks, for each regulated record, whether that record is being kept electronically and whether the controls around it are adequate. In practice this means your inventory needs a Part 11 applicability field, and the answer in that field is a conclusion about records, not about software. A system can hold electronic records that are not predicate rule records, in which case Part 11 does not attach. A system can also hold a single Part 11 record among thousands of records that are not, and the whole system inherits the obligation for that one record type. The inventory is the only practical place to record that reasoning so it does not get re-litigated at every audit.

Beyond manufacturing: laboratories and clinical work

The expectation is not confined to production areas. Answering written questions from delegates at its 2016 laboratories symposium, the MHRA Inspectorate was direct about the list of computerized systems: there is an expectation that it is readily available and complete.⁶ The same set of answers treats scope broadly. Systems which support regulatory testing are within the scope of an inspection and may be assessed. And where a computerized system is responsible for data capture or monitoring, an assessment would be expected. That last answer was given to a question about refrigerators.⁶

Two things follow. Storage and environmental monitoring belongs in the assessment population even though nobody at the bench thinks of a refrigerator as a computerized system. And the standard is readily available and complete, which is a higher bar than available after a day of assembly.

The MHRA has made a related point about clinical work. Writing on computer system validation in the GCP context, a GCP inspector noted that validation applies not only to specialist electronic system vendors but also to clinical trials units and contract research organizations, to specialist analytical software developers, and to sponsors developing their own software solutions.¹² Software your own people wrote is the category most often missing from an inventory, and it is the category regulators have named directly.

Where the inventory connects to validation planning

Annex 15 sets out the qualification and validation lifecycle and the role of the validation master plan.¹¹ The WHO guidance on validation describes the validation master plan as a high-level document summarizing the manufacturer’s approach and providing information on the qualification and validation work program, including a plan for maintaining a validated state and reviewing validation status.¹⁴ PIC/S makes the same connection in its recommendations on qualification and validation, which set out what a validation master plan should contain and take effect on 1 October 2026.⁷ That plan cannot be complete unless the population it plans for is known. The inventory is the population. When the two documents disagree about how many systems exist, the validation master plan is the one that loses credibility.

Scope Is Where Inventories Fail

Ask ten quality and IT people at the same site whether a specific borderline item belongs on the inventory and you will usually get a split. The split is not a sign of a weak team. It is a sign that nobody has written down the rule, so each person is applying a private one. Here are the cases that produce the split most reliably.

The spreadsheet with macros

A spreadsheet that a chemist uses to calculate a result that goes on a certificate of analysis is doing regulated work. The usual argument against listing it is that it is not a system, it is a file. That argument does not survive contact with the definition: Annex 11 describes a computerized system as a set of software and hardware components that together fulfill certain functionalities.¹ A workbook with formulas, macros and a template is software performing a function.

The real reason teams resist listing spreadsheets is different. They believe listing means validating, and validating a hundred spreadsheets is more work than anyone has capacity for. That belief is the single biggest driver of under-scoped inventories, and it is wrong. More on that in the next section. It is worth noting how the MHRA framed the point: if a spreadsheet is subject to a formal validation process then user requirement specifications are required.⁶ The condition is on the front of that sentence. Deciding that a spreadsheet needs formal validation brings obligations with it. Deciding that it does not still requires you to have made and recorded the decision.

The lab instrument with embedded firmware

A balance, a pH meter, a dissolution bath, a particle counter. Each has firmware. Some hold no data at all and simply display a reading that a person transcribes. Some hold a rolling buffer of the last hundred readings. Some are attached to a workstation running chromatography data system software. The instrument and the software attached to it are frequently listed as one entry when they should be two, or as two when they behave as one.

The useful question is where the GxP record is created and where it first becomes durable. If the instrument produces a reading that a person writes on a form, the instrument is equipment under calibration control and the record is the paper form. If the instrument writes a file, the thing that writes the file is a computerized system holding a GxP record and belongs on the inventory in its own right.

The Power BI report and the analytics layer

Reporting and visualization tools get skipped because they are read-only. That reasoning is incomplete. A report is in scope when a GxP decision is made from what it shows: a trend review that concludes a process is in control, an environmental monitoring dashboard used to decide whether to release a batch, a quality metric reported to management review. The risk in a reporting layer is not that it changes the source data. It is that a filter, a join or a date boundary written into the report changes what the data appears to say, and nothing about the source system will reveal that.

The practical rule: the report is in scope if a decision recorded in a GxP record cites it. If it is management information that informs discussion but no regulated decision, it is not.

The departmental database

Usually an Access database, a SharePoint list, or a low-code application a supervisor built to track something the enterprise system does not track well: training waivers, sample logistics, deviation triage, equipment loans. These are the classic gap. They are not on any IT asset register because IT did not deploy them. They are not on the validation list because nobody asked for validation. And they have often become the only place a particular piece of information lives.

The tool a scientist built with an AI assistant

This is the newest boundary case and it is the same problem in a new form. A scientist writes a script, or configures a language model to summarize deviation text, or builds a small classifier that flags out-of-trend results for review. Whether that belongs on the inventory is a scope question, and it is answered by the same rule as everything else: does it create, change or present a GxP record, or does a GxP decision depend on its output? If yes, list it. What validation it then needs, how you handle model updates, and what evidence you keep about training data are separate questions with their own answers, and they are not reasons to leave the tool off the list.

The vendor-hosted portal

A supplier gives you a login to their quality portal to retrieve certificates of analysis. A contract laboratory posts results to a web application. A logistics provider exposes temperature data through their own dashboard. Nobody at your site installed anything, so nobody thinks of it as a system. But GxP records are being created, held and presented there, and Annex 11 is explicit that where third parties provide, install, configure, integrate, validate, maintain or modify a system or related service, formal agreements must exist with clear statements of the third party’s responsibilities.¹ You cannot demonstrate that agreement is in place for a system you have not listed.

Writing a Scope Rule People Can Apply

A scope rule earns its keep when two people who have never spoken can apply it to the same item and reach the same answer. That is a testable property, and testing it is the step almost everyone skips.

The three questions

A rule that works in practice reduces to three questions, applied in order.

Separate scope from effort, in writing

The rule needs one more sentence that most do not have, stated plainly at the top: being on the inventory does not mean a system requires full validation. Scope determines whether an item is listed and assessed. Risk determines what evidence is then required. GAMP 5 second edition categorization exists to right-size that effort, not to decide membership, and the GAMP good practice guidance on operating GxP computerized systems is built around applying proportionate controls across the operational life of a system rather than a single level of rigor for everything.¹⁵

Once teams believe that sentence, under-reporting stops. A locked spreadsheet with three formulas gets listed, assessed as low risk, and controlled with a verified calculation check and access restriction. It does not get an installation qualification, an operational qualification and a performance qualification. The MHRA has made a similar point from the inspector’s side, observing that simple system design can have a significant effect on the success of data governance.¹³ Simple things can be controlled simply. They still have to be known.

Four tiers that keep the argument short

Test the rule before you publish it

Take twenty items you already argue about. Give the list and the draft rule to two people who did not write it, working independently. Compare their answers. Anywhere they disagree, the rule is ambiguous and needs a worked example added, not a stern reminder. Repeat until agreement is high. This takes an afternoon and it is the difference between a rule and a wish.

Keep the worked examples in the procedure. A scope rule with fifteen worked examples attached will hold up under staff turnover far better than an elegant one-paragraph definition, because new people reason by analogy to examples long before they internalize a principle.

The Fields Every Entry Needs

Below is a full field list you can copy. It is deliberately longer than what you should start with. Build the first version with the ten fields marked as core, get to a complete population, and then deepen. An inventory that is complete and shallow is defensible. One that is deep and missing a third of the estate is not.

Identification and ownership

1. System ID (core). A stable identifier that never changes, even when the system is renamed or upgraded. Every other document should cite this ID.
2. System name (core). The name people at the site actually use, with the vendor product name in parentheses if they differ. Inventories become unusable when the row says the product name and the floor says the nickname.
3. Version (core). Application version or release in production today. This is the single field most often stale, and the easiest for an inspector to check against a screen.
4. Business or process owner (core). The person accountable for the business process the system supports. Annex 11 names the process owner as a distinct role.¹
5. System owner (core). The person responsible for availability, maintenance and the security of the data on the system. Also named in Annex 11. A name, not a department.
6. Quality owner. The named quality representative who approves changes and reviews periodic evaluations for this system.
7. Site and physical location (core). Where the system is used. PI 041-1 asks for location explicitly.²

Regulatory assessment

8. Primary function (core). One sentence describing what the system does in the process. Not a marketing description.
9. GxP assessment (core). Direct GxP impact, indirect impact, or none, following the PI 041-1 wording so the terms match what an inspector expects.
10. Basis for the assessment (core). Which records, which decisions, which predicate rule. This is the field that turns a claim into an argument.
11. Regulatory scope flags. GMP, GCP, GLP, GDP, pharmacovigilance. A system can carry more than one and the controls differ.
12. Part 11 applicability. Whether the system holds electronic records subject to Part 11, which record types, and whether electronic signatures are used.⁹
13. Risk classification (core). Your tier from the scope rule. Drives validation depth, periodic review interval and audit trail review frequency.
14. GAMP category. Useful for planning the work. Not a substitute for the risk classification.
15. Assessment date and approver. When the GxP determination was made and by whom. An assessment with no date cannot be shown to be current.

Validation and control status

16. Validation status (core). Validated, in validation, assessed as not requiring validation, or legacy under remediation. Use a fixed vocabulary, not free text.
17. Validation document reference (core). The report number and approval date. PI 041-1 asks for the reference, not just the status.²
18. System description reference. Required for critical systems under Annex 11 4.3, covering physical and logical arrangements, data flows, interfaces, prerequisites and security measures.
19. Audit trail status. Whether a system-generated audit trail exists, whether it is enabled, and what it captures. If it does not exist, the compensating control and its reference.
20. Electronic signature use. Whether signatures are applied in the system and for which record types.
21. Access management approach. How accounts are provisioned and reviewed, and whether the system is integrated with central identity management or has local accounts.

Architecture and dependencies

22. Hosting model (core). On-premises, private cloud, vendor-hosted software as a service, or hybrid. Determines who holds the qualification evidence.
23. Data location. The country or region where regulated data is stored and where backups are held. Ask the vendor and record the answer with a date.
24. Interfaces (core). For each connection: the other system, direction, transport method, what record types move, and whether the transfer is verified. This is the field that catches the most drift, because interfaces change without either endpoint changing.
25. Upstream and downstream dependencies. Which systems this one needs to function and which depend on it. Useful for business continuity classification and for scoping the impact of any change.
26. Infrastructure qualification reference. The qualification evidence for the platform the application runs on. Annex 11 states the principle directly: the application should be validated and the IT infrastructure should be qualified.¹

Supplier and lifecycle

27. Supplier (core). The legal entity, not the reseller or the account manager.
28. Supplier assessment status and date. Whether an assessment or audit was performed, the outcome, and when it is due again.
29. Agreement reference. The quality agreement or contract clause that defines the third party’s GxP responsibilities, as Annex 11 section 3.1 requires.
30. Support status. Whether the version in use is still supported by the supplier. An unsupported version in a critical system is a finding waiting to be written.
31. Periodic review interval and next due date (core). Driven by risk classification. Annex 11 section 11 requires periodic evaluation to confirm systems remain in a valid state and compliant with GMP.
32. Last periodic review date and outcome reference.
33. Business continuity classification. The recovery expectation and whether the alternative arrangement has been documented and tested, per Annex 11 section 16.
34. Records retention and archiving approach. What is retained, for how long, and where. Annex 11 section 17 requires archived data to be checked for accessibility, readability and integrity, and the ability to retrieve it to be ensured and tested when the system changes.¹
35. Decommissioning status (core). Active, planned for retirement, in decommissioning, or retired. Retired entries stay on the inventory with the retirement date and the disposition of the data.
36. Data disposition on retirement. Migrated, archived in readable form, or retained in a read-only instance, with the reference to the plan.

Maintenance metadata

37. Last updated date and by whom (core in effect). Every row, not just the file.
38. Last verified date. Distinct from last updated. A row can be unchanged for two years and still be correct, but only if somebody confirmed it.
39. Open actions. Any known gap with a reference to the CAPA, change record or remediation plan addressing it.

Keeping It Current When Nobody Owns It

Every inventory is accurate on the day it is approved. The interesting question is what happens in month seven. There are three mechanisms that keep it accurate and you need all three: triggers that fire on events, a periodic reconciliation that catches what the triggers missed, and a single named owner who is accountable for the document itself.

The events that must trigger an update

The trigger that fails most often is the ownership one, because it is the only one that lives outside the quality and IT processes. A departing system owner is handled by a manager and HR, and the inventory is not in their checklist. Adding one line to the leaver checklist that asks whether the person appears as an owner on the computerized system inventory removes an entire category of drift for almost no effort.

The trigger that fails most damagingly is the interface one. Interfaces change during projects that are scoped as changes to a different system, so the change record names system A and the inventory row for system B goes stale. The fix is a required field in change control: does this change add, remove or modify a data flow between systems, and if so, which rows on the inventory are affected. Make it a question the change owner must answer, not a box quality assurance is expected to notice.

Where to attach the trigger so it actually fires

A trigger attached to a procedure that people read once a year does not fire. A trigger attached to a form field that blocks progress does. Three places work:

• Change control. Add a mandatory field: “Inventory rows affected by this change.” Blank is not an acceptable value; “none, and here is why” is. Closure of the change is conditional on the inventory update being made, with the row’s last updated date as evidence.
• Procurement. Any purchase requisition for software, a subscription, or a service that processes data routes through a two-question GxP screen before approval. This catches the vendor-hosted portal, which is the category no technical discovery method will find, because there is nothing on your network to discover.
• Onboarding and offboarding. Ownership fields are refreshed when people join, move or leave. Also the moment to confirm that access reviews for that person’s systems were completed.

The reconciliation that catches what slipped

Triggers catch changes that go through a process. Nothing catches the systems that never entered a process in the first place, and those are the ones that generate findings. A periodic reconciliation compares the inventory against independent sources that were built for another purpose.

The last one is the highest yield and the one most often skipped because it takes time. Walking a laboratory or a production area with the supervisor and asking, at each workstation, what runs here and where the output goes, surfaces more missing entries than every automated method combined. Budget half a day per area and do the areas on a rotation.

Somebody has to own the document itself

System owners own systems. Process owners own processes. If nobody owns the inventory as an artifact, it degrades no matter how good the triggers are, because every trigger has an exception path and exceptions accumulate. Name one accountable owner, usually in quality assurance or IT quality, whose job includes running the reconciliation, chasing the rows that failed to update, and reporting inventory completeness as a metric in management review. Completeness and accuracy are measurable: number of rows verified in the last twelve months, number of rows with a blank assessment basis, number of discrepancies found in the last reconciliation and how long they took to close.

Where this connects to periodic review and the site master file

Two adjacent processes depend on this document and are worth keeping distinct from it. Periodic review scheduling draws its population and its intervals from the inventory but is its own process with its own outputs, and it deserves separate design attention. The site master file describes the site to inspectors before they arrive and refers to the computerized systems in use; it is a summary that must agree with the inventory, not a second version of it. Keep one source. Let the others cite it.

What an Inspector Infers From a Mismatch

The reason a stale inventory is worse than it looks is that inspectors do not treat it as a documentation error. They treat it as evidence about processes they cannot observe directly. PI 041-1 states the reasoning: a company without adequate visibility of all computerized systems may overlook the criticality of systems and create vulnerabilities in the data lifecycle, and the inventory is what ensures changes and modifications to systems are controlled.²

Follow that logic through. If a system was upgraded and the inventory still shows the old version, then either the change was not put through change control, or it was and the change did not include the inventory update. The first is a change control failure. The second means the change control procedure has a defect that would have affected every other change in the period. Either way, the finding is no longer about one row.

The difference a documented gap makes

There is an important distinction between a gap you found and a gap the inspector found. A row that reads “identified during Q2 2026 reconciliation; GxP assessment in progress; interim control: results independently verified by a second analyst; CAPA-2026-0142” tells a completely different story from a blank. The first shows a working detection process. The second shows nothing, which the inspector must read as nothing working.

This is the practical reason to run the first reconciliation before you think you are ready. Whatever it finds, you would rather find it yourself and have the remediation record to show. A site that reports thirty newly identified systems with assessments underway is in a stronger position than one that reports a clean inventory an inspector then punctures on the floor.

Building the First One in Ninety Days

If you are starting from four partial lists, the temptation is to design the perfect template and then populate it. That order fails, because populating forty fields for three hundred systems is a project nobody finishes. Reverse it. Get to complete coverage with a small field set, then deepen.

Two notes on sequencing. First, do the assessment basis work for the critical tier before you extend fields anywhere else. Those are the rows an inspector will sample. Second, treat the deeper architecture fields, particularly interfaces and system descriptions, as a second project scoped to the critical tier only. Annex 11 asks for the fuller description for critical systems specifically, and honoring that boundary is what makes the work finite.¹

Conclusion

The computerized system inventory is a small document that reports on the health of several large processes. When it is current, it shows that change control captures system changes, that procurement routes software through an assessment, that ownership survives staff movement, and that retirement is a controlled activity. When it is stale, it shows the opposite, and it shows it to an inspector in the first hour of a visit, before anyone has had a chance to explain.

The work divides cleanly. Scope is the hard part and it is a writing problem, not a technical one: a rule with worked examples that two people apply the same way, and one sentence at the top making clear that listing a system is not the same as validating it. Fields are the easy part, and the discipline is to start with ten and finish the population rather than designing forty and never getting there. Currency is the part that requires organizational design rather than effort: triggers attached to forms people cannot bypass, a reconciliation against sources built for other purposes, and one named person accountable for the document itself. Get those three right and the inventory stops being something you rebuild before every inspection.

Sakara Digital works with pharma and biotech organizations on the data and system governance that regulated operations depend on, including scope rules, inventories and the change processes that keep them accurate. If you are rebuilding an inventory, or you suspect yours would not survive a walk of the floor, we are happy to have that conversation.

For Further Reading