IT Asset Naming Conventions

The asset naming conventions of the early 2010s were designed for static, on-premises IT infrastructures. Today, organisations operate in highly dynamic environments with widespread remote work, extensive cloud adoption, and increasingly ephemeral workloads driven by containerisation and automation.

This formal guide presents a modern framework for naming IT assets that addresses these hybrid realities.

Enabling Remote and Hybrid Work

Modern IT infrastructures must support employees working remotely, in the office, or a combination of both. In addition, organisations increasingly rely on a workforce made up of both permanent employees and contractors. Naming conventions should account for both access mode (remote, office, hybrid) and role type (employee or contractor) to enable targeted policy enforcement, security monitoring, and inventory reporting.

• Example: ONP-RMT-EMP-WKS-3421 — An on-premises workstation primarily used by a remote permanent employee.
• Example: ONP-OFF-CTR-WKS-R1-3421 — A workstation assigned to a contractor working on-site in the London office.
• Example: CLD-HYB-EMP-VDI-WEU-8192 — A cloud-hosted virtual desktop accessed in a hybrid pattern by a permanent employee.

Standardising Cloud-Native Resource Names

Cloud resources can span multiple regions, accounts, and platforms. A standardised naming convention ensures consistency and clarity for cost management, security auditing, and operational oversight.

• Example: CLD-HYB-APP-WEU-0132 — A cloud-based application deployed in Western Europe.
• Example: CLD-RMT-DB-USE2-983A — A cloud-hosted database in the US East 2 region.

Accommodating Containers and Ephemeral Resources

Ephemeral workloads—such as containers, serverless functions, and short-lived VMs—require naming practices that support traceability. These names should be designed to remain meaningful even after the asset has been deprovisioned.

• Example: CNT-HYB-API-PAY-V1-X9A3D — A container instance running the payment API.

Reinforcing Policies and Automation

A robust naming convention supports policy enforcement and automation across environments. It can be enforced through IaC tools, CI/CD pipelines, and cloud policy engines to ensure consistent compliance.

Integrating Privacy, Security, and Compliance

Asset names should avoid revealing sensitive or identifiable information. Names should never include usernames, business functions, or cloud provider names. If wishing to tag by provider name (e.g. AWS, Azure), create public obfuscated location codes and map internally.

• Risky Example: AWS-London-Finance-DB-JaneSmith
• Recommended Example: CLD-OFF-DB-R1-FIN-02F8

Obfuscating Location Identifiers: Pros and Cons

While using readable location codes can help operational teams, they can also expose your infrastructure layout. Obfuscation helps reduce risk.

• Pros: Easier troubleshooting and compliance segmentation.
• Cons: Increased external exposure and risk of targeted attacks.

Recommendation: Use codes like R1, R2 and maintain a private mapping internally.

Internal Location Code Mapping Table Example

Appendix: Real-World Asset Name Examples