IT Infrastructure Asset Inventory Template

Standard Operating Procedure: IT Infrastructure Asset Inventory Management

Document ID: SOP-INFRA-INV-042
Effective Date: October 24, 2023
Version: 3.2.1
Review Cadence: Semi-Annual (Every 6 Months)
Author: Julian Vance, Chief Architect, Template Registry

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional requirements for discovering, cataloging, classifying, and maintaining the lifecycle state of all IT infrastructure assets within the enterprise boundary.

The primary objective is to maintain a 99.9% accurate Configuration Management Database (CMDB) to mitigate cybersecurity vulnerabilities, ensure regulatory compliance (SOC 2, ISO 27001, HIPAA), streamline capacity planning, and eliminate shadow IT. Adherence to this protocol is mandatory for all Systems Engineering, DevOps, and IT Operations personnel.

---

2. Scope & Prerequisites

Scope

• In-Scope: All physical hardware (servers, networking gear, firewalls, end-user compute), virtualized environments (VMs, containers), cloud resources (AWS, Azure, GCP instances/storage), and enterprise software licenses owned, leased, or managed by Template Registry.
• Out-Scope: Personal Bring-Your-Own-Device (BYOD) hardware not connected to core corporate VLANs (handled via MDM isolation policy).

Prerequisites & Required Tools

• Discovery Tooling: Enterprise Network Discovery Agent (e.g., Lansweeper, Device42, or AWS Systems Manager / Azure Resource Graph).
• CMDB / Inventory Repository: Template Registry Enterprise Asset Management System (EAMS v4.2).
• Access Credentials: Privileged Access Management (PAM) vault access with read/write permissions to the target network segments and CMDB API endpoints.
• Safety / PPE: N/A for software/logical workflows; standard ANSI/ISEA Z87.1 eye protection and ESD wrist strap/mat required for physical datacenter racking/auditing operations.

---

3. Roles & Responsibilities (RACI Matrix)

• Responsible (R): Executes the asset discovery and inventory update tasks.
• Accountable (A): Ultimate ownership of data integrity and SOP compliance.
• Consulted (C): Provides security parameters, schema requirements, and architectural boundaries.
• Informed (I): Receives audit reports and operational status updates.

---

4. Step-by-Step Procedure

Phase 1: Automated Discovery & Scope Verification

• 1.1 Log into the Enterprise Network Discovery Agent via the secure PAM portal.
• 1.2 Verify that network scanning ranges (CIDR blocks) match the current enterprise topology map in Confluence.
• 1.3 Execute a read-only discovery sweep across all target VLANs (Datacenter, Corporate, Cloud VPCs) using ICMP, SNMPv3, and WMI/SSH protocols.
• 1.4 Export raw discovery payloads to the staging environment (/var/log/inventory/staging/raw_scan_[YYYYMMDD].json).

Phase 2: Reconciliation & Data Enrichment

• 2.1 Run the automated reconciliation script (python3 reconcile_assets.py --input raw_scan_[YYYYMMDD].json) to compare discovered assets against the active CMDB.
• 2.2 Identify discrepancies: Unmatched assets (New/Rogue), missing assets (Offline/Decommissioned), and modified configurations (IP changes, RAM upgrades).
• 2.3 Manually investigate unmatched assets via MAC address lookup and Active Directory/LDAP bindings to assign ownership and department tags.
• 2.4 Apply standardized naming conventions to all newly provisioned assets ([Site]-[Type]-[Serial/ID]).

Phase 3: Classification & Tagging

• 3.1 Assign a Criticality Tier to each verified asset:
  • Tier 1 (Mission Critical): Core routers, production DBs, hypervisors.
  • Tier 2 (Business Operational): Internal file servers, staging clusters.
  • Tier 3 (Non-Critical): Developer sandboxes, test workstations.
• 3.2 Update compliance metadata fields (PII presence, PCI-DSS scope, Backup Policy ID).
• 3.3 Validate that hardware serial numbers, MAC addresses, and physical rack locations (if applicable) are immutable and correctly indexed.

Phase 4: CMDB Commit & Audit Sign-Off

• 4.1 Push the reconciled dataset from the staging environment to the production EAMS instance via API batch commit.
• 4.2 Generate the automated Inventory Discrepancy Report and submit it to the Chief Architect for review.
• 4.3 Archive the discovery logs and audit trails to cold storage with a 7-year retention policy for regulatory compliance.

---

5. Quality Assurance & Pro-Tips

Best Practices

• Continuous Integration of Inventory: Integrate asset registration hooks into Terraform and Kubernetes deployment pipelines to ensure zero-day resource tracking.
• Immutable Tagging: Never rely solely on IP addresses for asset identification; always index by hardware UUID, MAC address, or Cloud Resource ARN.

Common Pitfalls to Avoid

• Orphaned Records: Failing to purge decommissioned assets leads to skewed metrics and false-positive vulnerability scans. Always execute a formal retirement workflow.
• Blind Spots: Forgetting to scan cloud provider accounts outside the primary tenant (e.g., shadow AWS accounts created via corporate credit cards).

Metric Thresholds

• Discovery Accuracy: $\ge 99.9%$ match rate between physical infrastructure and CMDB records.
• Reconciliation Latency: Maximum of 24 hours from asset provisioning/deprecation to CMDB state update.

---

6. Frequently Asked Questions (FAQ)

Q1: What is the protocol if an automated network discovery sweep misses an air-gapped or offline asset?
A: Air-gapped or strictly isolated hardware must undergo a manual physical or local-console audit. The Systems Engineer must ingest the asset details (Serial, Model, Owner, Purpose) via the offline CSV ingestion template and upload it directly to the EAMS staging bucket with explicit approval from the Information Security Officer.

Q2: How are cloud-native, ephemeral resources (e.g., AWS Lambda, Auto-Scaling EC2 instances) handled to prevent database bloat?
A: Ephemeral cloud resources must not be added as individual static records unless they persist past 72 hours. Instead, they must be tracked via dynamic cloud resource tags and aggregated under parent cluster or service-level logical entities within the CMDB.