One inventory, two masters: merging the Annex 11 system list with the OT asset inventory

The periodic review of the filling line’s supervisory system was going well until someone from OT security joined the meeting with a laptop. The quality file listed the system as one line: name, good manufacturing practice (GMP) function, system owner, validated, next review due. The passive monitoring tool listed fourteen devices on the same network segment, two of which nobody in the room could name. We see this meeting, in one form or another, on most of the sites we assess.

Neither list was wrong. They answer different questions, at a different grain, for different owners, on different clocks. The fix is a shared key between the two lists, a named owner for every column, and a change process that updates both in the same step. How devices are discovered, and how the network is watched for intruders, are other subjects.

Two lists, two questions

The quality list answers a regulator’s question: which computerised systems does the site rely on for GMP, and are they in a validated state? EU GMP Annex 11, in its 2011 text, asks in §4.3 for “an up to date listing of all relevant systems and their GMP functionality (inventory)”, plus, for critical systems, a description of their physical and logical arrangement, data flows, interfaces and security measures.

Annex 11 itself does not name the other fields sites usually keep. They come from the Pharmaceutical Inspection Co-operation Scheme (PIC/S). Its guide PI 011-3 of 25 September 2007 says in §6.3 that regulated users should have an inventory of their computerised systems with “ownership, supplier/developer, functionality, links and validation status”. PI 041-1 of 1 July 2021, on data integrity, adds in §9.3 the name, location and primary function of each system, its criticality, and its validation status with a reference to the validation documents.

The OT security list answers an attacker’s question: what is on the wire, what does it run, and what does it expose? The joint guidance published on 13 August 2025 by the Cybersecurity and Infrastructure Security Agency (CISA) with eight partner agencies, Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators, names fourteen attributes to collect first. Among them are the IP address, the media access control (MAC) address, manufacturer, model, operating system, ports and services, protocols, user accounts, logging, location and criticality.

The GMP list is about systems and their validated state; the security list is about components and their exposure.

Why they never match

Four causes come back on every site, and none of them is carelessness.

• Grain. One GMP entry, “packaging line 3 supervisory system”, is a server, two clients, a historian collector, four controllers and the switches between them. The monitoring tool sees the components, the validation file sees the system.
• Names. Quality names systems by function, OT by hostname and IP address. A hostname copied from the vendor’s template, or an address assigned automatically, changes without anyone touching the GMP record.
• Reach. A passive tool lists what talks on the segments it watches. A serial instrument, a stand-alone weighing terminal or a laptop that visits once a quarter is missing. The CISA guidance asks for physical inspection and documentation alongside the logical survey for that reason.
• Clock. The GMP list moves when a validation or a change closes. The tool’s list moves every time a device appears. Each one is right on its own clock.

A third list often sits in the maintenance system, on finance’s depreciation clock; Bill Lydon noted in InTech in 2019 that automation systems reach the end of their useful life long before the machines they drive. That list carries the tag numbers, which matters for the key.

What the texts ask of the list

Three rows deserve a second look. The Annex 11 revision was put to consultation from 7 July to 7 October 2025; until the Commission adopts a final text, the 2011 version applies. The second edition of IEC 62443-2-1, published on 7 August 2024, puts the inventory baseline and change control in the same element: a security inventory without change control is half a requirement.

The Network and Information Security directive (NIS2) groups asset management with access control under one point; NIS2 Article 21, measure by measure lists the evidence an auditor tends to ask for under it.

The method: five steps, read for a GMP site

The CISA guidance lays out five steps, and each has a GMP reading.

Scope and governance. The guidance asks who requires the inventory and who collects and validates the data. A pharmaceutical site has two authorities, quality and the security programme: write both into one procedure, saying which signs which column.

Assets and attributes. Start from the GMP list, not from the tool. Every GMP system is broken down into its components; every component the tool sees is attached to a system. The fourteen high-priority fields are the security side’s minimum. The CISA appendix rates the department or owner field only medium priority, which is where a GMP site differs: for us the owner is a regulatory field.

Taxonomy. CISA classifies assets by function or criticality, and groups them into zones and conduits after the IEC 62443 series. A GMP site already has a criticality scale in its validation risk assessments: map the two scales once, in writing, rather than inventing a third. The zone becomes a field of the merged record, and zones and conduits start from the risk, not from the switch.

Data management. The guidance recommends a central store with its own security controls. If the security platform becomes the master for GMP fields, it is a computerised system holding GMP records, with all that follows. Most sites keep the GMP columns in the quality system and link them by key.

Life cycle. The guidance asks for inventory updates on every introduction or removal of a device, “in all cases, even under emergency change authority”. That sentence is the bridge to Annex 11 §10, and it is where most merged lists fail.

The shared key, and who owns each column

A merge needs a key that neither side changes behind the other’s back. IP addresses, hostnames and MAC addresses fail that test: they change on a network card swap or a re-addressing. The CISA list includes an asset number, “unique identifier assigned to the asset by the organization”. Use that, printed on a label on the device, and tie it to the system identifier of the GMP list: one system, many asset numbers.

Shared infrastructure is the awkward case. A core switch serving several GMP systems gets its own infrastructure entry, with the systems that depend on it listed, rather than hanging off whichever system was validated first.

The principle behind the last column: the tool writes observations, people approve records. An observed firmware version that differs from the approved one is not a correction to the inventory; it is a question about an unapproved change.

The backup columns are the ones least often filled. A backup is a hypothesis, a restore is evidence: the field should hold the date of the last tested restore, not only the backup schedule.

Reconciling the two lists

The first comparison sorts every entry into one of three groups, and each group has its own owner and its own action.

Devices seen but not listed frighten people, and most turn out to be ordinary: a vendor’s laptop, a spare controller left powered, a printer. They still go through the deviation process, because an unexplained device on a validated network is an unapproved change until shown otherwise. The Annex 11 draft says in §14.2 that undocumented changes “should be effectively identified”.

Systems listed but not seen are a monitoring question first: the device is off, serial or on a segment the tool does not watch, or it has gone. A physical check and a dated note close it. Old programmable logic controllers (PLCs) on unsupported firmware stay in the list with a compensating-measure field, as legacy PLCs that are shielded rather than replaced need to be documented.

Change control keeps it true

A merged list drifts from the morning after its reconciliation, unless the change process carries it. The usual pattern we find: the change form asks whether the validation documents are affected, and nobody asks whether the inventory is.

Three additions to the change procedure are enough. The request names the asset numbers it touches. The owners update their fields before the record is signed. After closure, the tool’s observed values are compared with the approved ones; a mismatch reopens the change.

Emergency changes follow the same route, completed afterwards within a deadline the procedure fixes; the CISA wording leaves no exception for them. The periodic review then checks the reconciliation itself: unexplained devices, mismatched versions, age of the oldest open item.

Where to start

1. Pick one line and agree the key. Take one GMP system with its components and assign asset numbers, labelled on the devices. It is done when every device the tool sees on that segment carries a number linked to a system ID, or sits in a deviation.
2. Write the owners into the procedure. One table, like the one above, approved by quality and by the OT security lead. It is done when each column has a named role.
3. Add one line to the change form. “Asset numbers affected, inventory updated (yes / not applicable)”. It is done when the next three changes on that line closed with the field filled.

Five common mistakes

1. Making the tool the master. An observation becomes a record without anyone approving it, and a GMP field ends up in an unvalidated database.
2. Keying on the IP address. The first re-addressing breaks every link between the two lists.
3. Merging once, as a project. Without the change-control step, the merged list is out of date within weeks.
4. Orphaning shared infrastructure. The core switch belongs to no system, so nobody updates its firmware.
5. Treating unknown devices as noise. An unexplained device on a validated network is a deviation to close, not a line to delete.

The two lists were never meant to be the same. They are meant to point at each other, through a key both sides respect.

References

• CISA, EPA, NSA, FBI and partner agencies, Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators, 13 August 2025: cisa.gov
• European Commission, EudraLex Volume 4, Annex 11: Computerised Systems (2011), §4.3, §10, §11: health.ec.europa.eu
• European Commission, revised Annex 11, draft for consultation, July 2025, §14.2 and §15: health.ec.europa.eu
• PIC/S, PI 011-3, Good Practices for Computerised Systems in Regulated GxP Environments, 25 September 2007, §6.3: picscheme.org
• PIC/S, PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments, 1 July 2021, §9.3: picscheme.org
• IEC, IEC 62443-2-1:2024, Security program requirements for IACS asset owners, edition 2.0, 7 August 2024: webstore.iec.ch
• Directive (EU) 2022/2555 (NIS2), Article 21(2)(i): eur-lex.europa.eu
• A Mouse, a Cookie, and OT/ICS Asset Inventories, InTech, April 2022, p. 7; Bill Lydon, Is your automation asset management out of sync?, InTech, September/October 2019, p. 50; Five Best Practices to Reduce OT/ICS Cybersecurity Risk, AUTOMATION 2022 Vol 4, October 2022: isa.org