ITAM vs. OTAM in operations

What distinguishes ITAM and OTAM in operations?

The distinction below is a working model for security and operations, not a normative definition. ITAM consolidates the technical and organisational context of IT assets. OTAM extends that context into the physical process. For OT, CISA therefore calls for an inventory plus a taxonomy based on function or criticality, with documented communication paths and dependencies.

Which data belongs in a dependable OT asset inventory?

CISA prioritises 14 attributes for each OT asset, including criticality, role or type, manufacturer, model, operating system, hostname, IP and MAC address, physical location, protocols, ports and services, user accounts, and logging. These fields form the technical core. Operations also need provenance, relationships, and accountability.

• Identity: unique asset number, manufacturer, model, hostname, IP address, and MAC address
• Technical state: operating system, firmware or software, active protocols, ports, and services
• Operating context: role or type, physical location, zone, communication paths, and process dependencies
• Security context: criticality, logging, user accounts, and existing technical controls
• Accountability: responsible person, technical operator, maintenance, and participating service providers
• Evidence: data source, collection time, change history, and validation status

For relevant critical infrastructure assets, the BSI catalogue adds clear accountability throughout the lifecycle and a uniform, risk-based classification. A shared IT/OT model should therefore treat these organisational fields as rigorously as technical attributes.

How is an OT asset inventory built according to CISA?

CISA describes a five-stage process from defined scope through lifecycle management. The outcome is not a one-off scan but a maintained inventory with a validated taxonomy.

1. Define scope and objectives

   Set governance, roles, and programme boundaries. Zones, facilities, and systems belong in scope, together with a clear definition of what counts as an asset.

2. Identify assets and collect attributes

   Combine physical inspection and logical survey with digital and network-based information. Include documented assets and infrastructure dependencies.

3. Build the taxonomy and relationships

   Classify assets by function or criticality. Document communication paths, zones, process dependencies, naming conventions, and the roles of operators and service providers.

4. Validate and manage the data

   Check inventory data for accuracy and completeness, visualise relationships, and add vendor documentation, maintenance data, configurations, and operational records.

5. Integrate lifecycle management

   Link acquisition, deployment, commissioning, maintenance, and decommissioning to the inventory. The introduction or removal of devices must trigger an inventory update, including under emergency change authority.

What does the BSI catalogue add for critical infrastructure?

The BSI catalogue specifies criteria under Section 8a(1) and (1a) BSIG for German critical infrastructure operators and provides orientation for selecting suitable audit criteria. BSI also states that individual criteria are not automatically binding. Their appropriateness must be assessed in the operator's specific context.

• Inventory quality (AM-01): keep records complete, accurate, current, and consistent, maintain traceable change history and use regular manual reviews where effective automation is absent
• Accountability (AM-02): assign every relevant asset to a responsible person on the operator side and maintain correct inventory and classification throughout its lifecycle
• Classification (AM-05): classify information and assets consistently on the basis of risk analysis and impact assessment
• Network topology (KOS-06): maintain current and traceable architecture documentation, including different environments, network segments, and data flows
• Change management (BEI-03 to BEI-10): assess risk, categorise and prioritise change, document testing and approval, provide rollback, and maintain evidence for emergency changes

How are ITAM and OTAM combined in practice?

A shared model standardises identity, evidence, and quality rules. IT and OT still retain their own collection paths, approvals, and operational boundaries.

1. Start with a dependable scope

   Select one critical service, site, zone, or production line, define what counts as an asset, and name accountable people.

2. Collect sources separately

   IT system sources, physical surveys, network data, engineering records, and maintenance data provide observations with provenance and timestamps.

3. Reconcile identities and relationships

   Resolve duplicates and conflicts while preserving zones, communication paths, services, and process dependencies as relationships.

4. Add accountability and classification

   Assign each relevant asset a responsible person, an operating role, and a traceable criticality or risk classification.

5. Turn change into inventory events

   Commissioning, maintenance, replacement, and decommissioning update the inventory. Regular validation checks completeness, accuracy, currency, and consistency.