An asset register that records only hostnames and serial numbers cannot answer the questions security needs answered: who owns this, what data does it hold, is it supported, and should it be on the network at all? This template defines the fields for a security-grade IT asset inventory covering hardware, software, cloud resources, SaaS applications and information assets, with ownership, criticality and lifecycle status for each. It is aligned to CIS Controls v8.1 Control 1 (Inventory and Control of Enterprise Assets) and Control 2 (Inventory and Control of Software Assets) and to ISO/IEC 27001:2022 Annex A control 5.9 (Inventory of information and other associated assets). It is written for IT asset managers, security teams and ISO 27001 implementers building or fixing a register in a spreadsheet, CMDB or asset management tool. How to run asset inventory and CMDB as a security programme is covered in the Asset Inventory and CMDB Security Guide; this page gives you the register itself.
How to use this template
- Replace text in square brackets, such as [Organisation], [Asset manager] and [CMDB], with your own values. Fields marked Required are the minimum for CIS Controls and ISO/IEC 27001 evidence; fields marked Recommended make the register useful for incident response and vulnerability management.
- Use Section 4 (common fields) for every record, then add the class-specific fields from Sections 5 to 8. In a spreadsheet, use one tab per asset class with the common fields repeated; in a CMDB, map each field to an attribute.
- Use drop-down values for every field with a fixed list (status, criticality, classification) so records can be filtered and counted.
- Do not record passwords, keys or other secrets in the register. Record where the credential is held, not the credential.
- Pair this register with a policy that makes keeping it current mandatory. See the Asset Management Policy Template.
1. Purpose
1.1 This register records every asset [Organisation] relies on to store, process or transmit information, so that each asset has an accountable owner, a known criticality and a lifecycle status.
1.2 The register is the authoritative list used for vulnerability management, patching, access reviews, incident response, business continuity, licence management and audit evidence. Discovery tools feed the register; they do not replace it.
2. Scope and asset classes
2.1 The register covers all assets owned, leased or used by [Organisation], on premises, remote and in the cloud, including devices that regularly connect to [Organisation] networks without being under its control (for example contractor or personal devices), as CIS Safeguard 1.1 requires.
| Asset class | Includes | Primary source of records | Framework reference |
|---|---|---|---|
| Hardware (end-user) | Laptops, desktops, mobile phones, tablets | [Endpoint management tool] | CIS Control 1; ISO A.5.9 |
| Hardware (infrastructure) | Servers, network devices, firewalls, storage, IoT and OT devices, printers | [Network discovery, DHCP logs, IPAM] | CIS Control 1 (1.3 to 1.5) |
| Software | Installed applications, operating systems, libraries on servers | [Endpoint management, EDR, vulnerability scanner] | CIS Control 2 |
| Cloud resources | Accounts, subscriptions, projects, virtual machines, containers, serverless functions, storage, databases | [Cloud provider inventory APIs] | CIS Control 1; ISO A.5.23 |
| SaaS applications | Sanctioned and discovered SaaS services | [Identity provider, CASB, finance records] | CIS Control 2; ISO A.5.23 |
| Information assets | Databases, file shares, document libraries, data sets | [Data owners, data discovery tool] | ISO A.5.9, A.5.12 |
2.2 Out of scope: [list, for example consumables and peripherals without storage]. Record the reason for each exclusion.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [Asset manager] | Owns the register, its fields and data quality; runs reconciliation and reports metrics |
| Asset owner | Named individual accountable for each asset: its classification, criticality, access and disposal. ISO/IEC 27001 A.5.9 expects owners to be identified for information and other associated assets |
| Technical custodian | Team that operates the asset day to day (patching, backup, configuration) |
| [Security team] | Reviews unauthorised assets, uses the register for vulnerability and incident work, audits completeness |
| Procurement and finance | Notify the asset manager of purchases, leases and SaaS subscriptions so they are registered at acquisition |
4. Common fields for every asset
| Field | Status | Format or allowed values | Why it matters |
|---|---|---|---|
| Asset ID | Required | Unique, never reused, for example [ORG]-HW-000123 | Joins the register to tickets, scans and logs |
| Asset name | Required | Hostname, application name or data set name | Human identification |
| Asset class and type | Required | From Section 2, then type (laptop, firewall, VM, SaaS) | Drives which class fields apply |
| Asset owner | Required | Named person, taken from the identity provider | Accountability; CIS 1.1 asks for a data asset owner |
| Business unit or department | Required | From the HR or organisation directory | CIS 1.1 field; routing of issues |
| Technical custodian | Recommended | Team name and queue | Who fixes it |
| Business service supported | Recommended | Service name from the service catalogue | Impact during incidents and outages |
| Criticality | Required | 1 to 4, see Section 9 | Prioritises patching, monitoring and recovery |
| Highest data classification | Required | [Public, Internal, Confidential, Restricted] | Sets handling controls (ISO A.5.12) |
| Location | Required | Site, room, cloud region or "remote" | Physical security and data residency |
| Lifecycle status | Required | Planned, In stock, Active, Under repair, Retiring, Disposed | Separates live from historical assets |
| Approved to connect | Required | Yes, No, Pending | CIS 1.1 field; basis for the unauthorised asset process in 1.2 |
| Discovery sources and last seen | Recommended | Tool names and date last observed | Finds stale and ghost records |
| Date registered and last reviewed | Required | ISO 8601 dates | Evidence of maintenance |
5. Hardware fields
5.1 CIS Safeguard 1.1 lists network address (if static), hardware address, machine name, data asset owner, department and whether the asset has been approved to connect to the network. Add these to the common fields:
- Required: manufacturer, model, serial number; hardware (MAC) address of each interface; static IP address where assigned; operating system and version; management agent installed (Yes or No); encryption status.
- Recommended: firmware version; purchase or lease date and supplier; warranty and vendor support end date; assigned user (for end-user devices); network segment or VLAN; EDR status; last patch date.
- Disposal: disposal date, method (wipe, destruction) and certificate reference, so disposed assets are traceable (ISO A.7.14).
6. Software fields
6.1 CIS Safeguard 2.1 asks the software inventory to record title, publisher, initial install or use date and business purpose, reviewed at least every six months. Add:
- Required: software title; publisher; version; initial install or use date; business purpose; supported status (Yes, No, Exception), which feeds Safeguard 2.2; authorised status (Approved, Unauthorised, Under review), which feeds Safeguard 2.3.
- Recommended: deployment mechanism (endpoint management, package manager, manual); number of installations and the hosts they are on; licence type, count and renewal date; vendor end-of-support date; decommission date; SBOM available (Yes or No). See the SBOM Guide.
- Service identity: for server applications, the service account, managed identity or system context the software runs as, and where its credentials are stored. When software is removed, this field tells you which identity to disable.
- Exceptions: for unsupported software kept in use, the exception reference, risk owner, compensating control and expiry date.
7. Cloud and SaaS fields
- Cloud resources, Required: provider; account, subscription or project ID; region; resource type; resource ID or ARN; environment (production, staging, development); owner tag; internet exposed (Yes or No).
- Cloud resources, Recommended: creation date and creator; tags for cost centre and data classification; infrastructure-as-code repository; backup policy; logging enabled.
- SaaS, Required: service name and vendor; business owner; sanctioned status (Sanctioned, Tolerated, Unsanctioned); authentication method (single sign-on, local accounts); data classification stored; contract and renewal date.
- SaaS, Recommended: number of users; admin accounts; OAuth applications and API integrations connected to it; vendor security assessment date and reference; data location. See the SaaS Security Guide.
8. Information asset fields
8.1 ISO/IEC 27001:2022 A.5.9 covers information as well as the systems that hold it. For each significant data set, database or repository record:
- Required: information asset name and description; information owner; classification; systems that store or process it (by Asset ID); contains personal data (Yes or No).
- Recommended: categories of personal data and data subjects (link to the record of processing activities); legal basis and retention period; backup and recovery objective; who has access (groups or roles); encryption at rest.
8.2 Where personal data is involved, keep this section consistent with the Record of Processing Activities (ROPA) Template rather than maintaining two different descriptions.
9. Criticality rating
| Rating | Name | Criteria | Example handling |
|---|---|---|---|
| 1 | Critical | Failure or compromise stops a critical business service, or the asset holds Restricted data or controls access to many systems (identity providers, domain controllers, backup systems) | Critical patches within [7 days]; full logging; tested recovery; quarterly owner review |
| 2 | High | Supports a key service or holds Confidential data | Patches within [14 days]; logging; annual recovery test |
| 3 | Medium | Supports internal operations with workarounds available | Patches within [30 days] |
| 4 | Low | Little business impact, no sensitive data | Standard build and patch cycle |
9.1 Criticality is set by the asset owner and reviewed by [Security team]. An asset inherits at least the criticality of the most critical service or data it supports.
10. Maintenance and review
10.1 New assets are registered at acquisition or creation, before they are connected or put into production.
10.2 [Asset manager] reconciles the register against discovery sources at least [weekly]: assets seen on the network or in cloud accounts but not registered are treated as unauthorised and handled within [seven days] by registering, removing, denying remote access or quarantining them, in line with CIS Safeguard 1.2.
10.3 Asset owners confirm their records at least every six months, matching the minimum review frequency in CIS Safeguards 1.1 and 2.1. Records for owners who have left are reassigned within [10 working days].
10.4 Changes to Required fields are logged with who changed them and when.
10.5 [Asset manager] reports these measures [monthly]:
| Measure | Calculation | Target |
|---|---|---|
| Inventory accuracy | Discovered assets present in the register divided by all discovered assets | [98%] |
| Record completeness | Records with all Required fields divided by all records | [95%] |
| Ownership currency | Records whose owner is an active employee | 100% |
| Unauthorised assets resolved in time | Unauthorised assets handled within the timeframe divided by all found | 100% |
| Unsupported software without exception | Count of unsupported titles with no approved exception | 0 |
Implementation guidance
- Start with what you can see: export from endpoint management, cloud provider inventories, the identity provider's application list and DHCP or IPAM, then de-duplicate by serial number, MAC address and cloud resource ID. Owners and criticality are the slow part; fill them for Critical and High assets first.
- Spreadsheet or tool: a controlled spreadsheet with locked drop-downs is enough for a small organisation working towards CIS Implementation Group 1. Larger estates need a CMDB or cyber asset attack surface management (CAASM) tool that pulls from discovery sources automatically. See the Asset Inventory and CAASM Buyers Guide.
- Take owners from the identity provider: link the owner field to directory accounts so leavers are flagged automatically. An asset owned by a disabled account is effectively unowned.
- Cloud tags at creation: enforce owner, environment and classification tags with cloud policy so cloud records arrive complete.
- Do not forget identities: service accounts, API keys and other non-human identities are not hardware or software, but every one of them belongs to an asset. Keep them in a linked identity inventory and reference the Asset ID. See the NHI Inventory Reconciliation Guide.
- Audit evidence: for ISO/IEC 27001 certification, auditors typically ask for the register, evidence that owners are assigned and that it is reviewed. For CIS assessments, keep the date of last update, the unauthorised asset log and the reconciliation reports.
- Framework alignment: NIST CSF 2.0 ID.AM-01 (hardware inventories), ID.AM-02 (software, services and systems inventories) and ID.AM-07 (inventories of data); NIST SP 800-53 Rev. 5 CM-8 System Component Inventory; CIS Controls v8.1 Safeguards 1.1, 1.2, 2.1, 2.2 and 2.3; ISO/IEC 27001:2022 A.5.9 and A.5.12.
Related NHI Mgmt Group resources: Asset Inventory and CMDB Security Guide · CIS Control 1 Inventory and Control of Enterprise Assets Guide · CIS Control 2 Inventory and Control of Software Assets Guide · Asset Management Policy Template