\1**\1**.
Capture the identity
Record the system name, version, supplier, deployment model, environment, owner, support contact, and unique identifier. Include spreadsheets, scripts, instruments, and interfaces when they perform a regulated function.
Avoid duplicate names. A platform with separate production, test, and reporting instances may need separate entries or a clear relationship between them.
Describe intended use
State the process, records, decisions, and outputs supported. Note whether the system creates, modifies, calculates, transfers, approves, stores, or reports regulated information.
This description is the foundation for deciding what assurance evidence is necessary. It should be specific enough to distinguish a critical calculation service from a reference-only tool.
Map ownership and suppliers
Identify process, system, data, quality, and security responsibilities. Record supplier agreements, support, release notifications, and access arrangements. Responsibility should be explicit where the service is hosted or shared.
Assess criticality and lifecycle
Use documented criteria to classify impact and required controls. Consider data integrity, patient or product decisions, release or disposition activities, business continuity, and the ability to detect a failure.
Link the inventory to validation status, approved configuration, incidents, changes, training, and periodic review. A status field without evidence links quickly becomes decoration.
Keep the inventory alive
Update the record when systems are introduced, changed, retired, or transferred. Reconcile it with procurement, identity, infrastructure, and quality records so unlisted tools do not become invisible process dependencies.
| Inventory field | Why it matters |
|---|---|
| Intended use | Explains the regulated process and boundaries |
| Data type | Shows which records and attributes need protection |
| Owner | Provides accountable decisions and review |
| Criticality | Focuses assurance and continuity controls |
| Lifecycle status | Shows whether the system is approved, restricted, or retired |
FAQ
Does every software tool belong in the inventory?
Include tools that support regulated processes or records, including relevant spreadsheets, scripts, instruments, and interfaces.
Who maintains the inventory?
The organisation should name an owner and define contributions from process, IT, quality, and system teams.
Can criticality be based on supplier marketing?
No. Base it on your intended use, process impact, data, and controls.
When should an inventory entry be created?
Before the tool is adopted for regulated work, then update it through the lifecycle.
Decision rule: choose evidence from the consequence of failure, the control being relied on, and the ability to detect a problem. A larger document set is not automatically stronger. Clear scope, reproducible evidence, and an approved conclusion are what make the decision defensible.
Keep the rationale with the controlled record. Future reviewers should be able to see what was considered, what was tested or reviewed, what remains uncertain, and who accepted the residual risk.
During review, compare the approved requirement with observed use, current configuration, and retained evidence. That simple comparison often finds drift before an auditor does.
For related work, read our validation traceability matrix guide.
Primary sources
Bring validation work under control
VLMS Software helps healthcare teams organise validation, evidence, and audit readiness around the work that matters.
Talk to VLMS Software