Asset Management Policy Template

You cannot patch, monitor, back up or retire what you do not know you own, yet many organisations have no single policy that says which assets must be recorded, by whom, and what happens to an asset nobody claims. This template sets out policy statements for identifying, recording, classifying, owning, using, tracking and disposing of technology assets: hardware, software, cloud resources, SaaS services, data stores and the non-human identities that operate them. It is aligned with CIS Controls v8.1 Controls 1 and 2, NIST CSF 2.0 Identify (ID.AM) outcomes and ISO/IEC 27001:2022 Annex A 5.9 to 5.12. It is written for security, IT asset management and GRC teams who need a policy they can adapt and adopt; have it reviewed by your legal, risk and procurement teams before approval.

How to use this template

• Replace text in square brackets, such as [Organisation], [IT Asset Manager] and [X days], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where documented exceptions may be justified.
• Keep the policy short and stable. Put tool names, field lists and procedures in the supporting standard so they can change without re-approving the policy.
• Agree the system of record before publishing: a CMDB, an IT asset management tool or, for a small organisation, a controlled register.
• Review the policy at least annually and after major changes such as an acquisition or a cloud migration.

1. Purpose

This policy sets the requirements for managing technology assets at [Organisation] throughout their life cycle, from request and acquisition to disposal. It ensures that every asset that stores, processes or transmits [Organisation] information is known, owned, classified, protected in proportion to its importance and securely retired, so that security controls, licensing, support and incident response can rely on an accurate inventory.

2. Scope

This policy applies to all assets that store, process or transmit [Organisation] information or connect to [Organisation] networks, wherever they are located, including:

• Hardware: end-user devices including laptops, desktops, tablets and mobile phones; servers; network and security devices; storage; IoT and operational technology devices; removable media.
• Virtual and cloud assets: virtual machines, containers and clusters, serverless functions, cloud accounts, subscriptions and projects, storage buckets and databases.
• Software: installed applications, operating systems, libraries and components in software [Organisation] builds, and licences.
• Services: SaaS applications and services provided by suppliers that hold [Organisation] data.
• Information assets: designated data stores and repositories, recorded with their classification.
• Non-human identities: service accounts, API keys, certificates, OAuth integrations and workload identities that assets use to authenticate.
• Assets not owned by [Organisation]: personally owned and contractor devices that regularly connect to [Organisation] networks or data, subject to the [BYOD Policy].

It applies to all employees, contractors and third parties who request, buy, build, operate, use or dispose of these assets.

3. Definitions

• Asset: any item in scope under section 2 that has value to [Organisation] and requires protection.
• Asset owner: the named individual accountable for an asset's purpose, classification, protection, access and disposal. The owner may delegate tasks but not accountability.
• Asset custodian: the team that operates the asset day to day, for example IT operations, a platform team or a supplier.
• System of record: [CMDB or asset management tool], the authoritative inventory for this policy.
• Unauthorised asset: an asset discovered on [Organisation] networks, cloud accounts or data that is not recorded and approved in the system of record.
• Criticality: the rating of an asset's importance to [Organisation] operations, set according to section 5.3.
• Unsupported software or hardware: an asset for which the supplier no longer provides security updates.

4. Roles and responsibilities

• [Chief Information Security Officer]: owns this policy and its supporting standards, and reports compliance to [risk committee].
• [IT Asset Manager]: operates the system of record, runs reconciliation and reports inventory quality.
• Asset owners: register, classify and review their assets; approve access; request secure disposal.
• Asset custodians: keep records accurate when assets are built, changed or moved; apply required controls.
• [Cloud platform team]: enforces tagging and ensures cloud resources are discoverable and recorded.
• [Procurement]: ensures purchases and SaaS subscriptions are approved and recorded before use.
• [HR]: notifies [IT Asset Manager] of joiners, movers and leavers so assets are issued, transferred and returned.
• All users: use assets in line with the [Acceptable Use Policy], report loss or theft immediately and return assets when they leave.

5. Policy statements

5.1 Inventory

1. [Organisation] must maintain an accurate, detailed and up-to-date inventory of all in-scope assets in the system of record, including cloud, remote and regularly connected assets not under [Organisation] control.
2. Each asset record must contain at least the fields set in the [Asset Management Standard], summarised in the table below.
3. Assets must be recorded before they are connected to production networks, receive production data or go live.
4. The inventory must be reviewed and updated at least [every six months], and reconciled against automated discovery at least [weekly].

5.2 Ownership

1. Every asset must have a named owner who is a current employee. Team or shared mailboxes must not be recorded as owners.
2. When an owner leaves or changes role, ownership must be transferred within [30 days]; otherwise the asset must be escalated to the owner's line manager.
3. Assets with no valid owner for more than [60 days] must be reviewed for decommissioning.

5.3 Classification and criticality

1. Each asset must be assigned the highest classification of the information it stores or processes, in line with the [Data Classification Policy].
2. Each asset must be rated for criticality using the scale below, and the rating must drive patching, backup, monitoring and recovery requirements.

5.4 Acquisition and onboarding

1. Hardware, software, cloud accounts and SaaS services must be obtained through [approved procurement and request routes].
2. New assets must be configured to the [secure configuration baseline] before use.
3. Cloud resources must carry mandatory tags for owner, cost centre, environment and classification; untagged resources must be flagged automatically.
4. Only currently supported software may be designated authorised. Unsupported software that is still required must have a documented exception with mitigating controls.

5.5 Discovery and unauthorised assets

1. [Organisation] must use automated discovery to identify assets on its networks, cloud accounts and identity platforms at least [daily].
2. Discovered assets not in the system of record must be investigated within [7 days] and then registered and approved, removed, denied remote access or quarantined.
3. Unauthorised software must be removed or given a documented exception within [30 days].
4. Unsanctioned SaaS services discovered through network, identity or expense data must be reviewed by [Security] and either approved, replaced or blocked.

5.6 Non-human identities linked to assets

1. Service accounts, API keys, certificates and OAuth integrations used by an asset must be recorded against that asset with the same owner.
2. When an asset is decommissioned, its non-human identities must be disabled, keys revoked and grants removed in the same change.

5.7 Use, movement and return

1. Assets must be used in line with the [Acceptable Use Policy].
2. Assets taken off premises must be protected as set out in the [Remote Working Policy], including full-disk encryption on portable devices.
3. Loss or theft must be reported to [Service Desk] within [24 hours] so access can be revoked and the device wiped where possible.
4. All [Organisation] assets must be returned when employment or contract ends; HR and line managers must confirm return before final sign-off.

5.8 Disposal and re-use

1. Assets must be sanitised before re-use or disposal using methods appropriate to their classification, in line with the [Media Sanitisation Standard].
2. Disposal must be carried out by [approved disposal provider] with certificates of sanitisation or destruction retained for [X years].
3. The system of record must be updated to show the asset as disposed, with the date and evidence reference.

6. Exceptions

Exceptions must be requested by the asset owner, risk assessed by [Security], approved by [approver], recorded with compensating controls and an expiry date of no more than [12 months], and reviewed before expiry.

7. Compliance and monitoring

[IT Asset Manager] will report inventory quality monthly to [CISO], including: the share of discovered assets present in the inventory, the share of records with all mandatory fields, the share of assets with a valid owner, unauthorised assets older than [7 days], and unsupported software without exceptions. Internal audit may review compliance at any time. Breaches of this policy may be handled under [disciplinary procedure].

8. Related documents

• [Asset Management Standard], [Data Classification Policy], [Acceptable Use Policy], [BYOD Policy], [Media Sanitisation Standard], [Secure Configuration Baseline], [Third-Party Risk Procedure].

Implementation guidance

Framework alignment

Rollout

1. Choose the system of record and the minimum fields before approval, and import from existing sources: endpoint management, cloud provider inventories, network scans, procurement and finance data.
2. Measure the baseline: compare discovery output with the inventory to get a first accuracy figure. Expect it to be low; publish it anyway.
3. Fix ownership first: pull owners from the identity provider and HR data, and flag assets whose owner has left.
4. Turn on the weekly unauthorised asset review in report-only mode for a month, then start enforcing quarantine and removal.
5. Enforce cloud tagging with provider policy in audit mode first, then deny untagged resources in production accounts.
6. Link non-human identities to assets, starting with Tier 1 systems. See the Service Account Inventory Template.

Common pitfalls

• Several competing inventories: security, IT and finance each keep their own list. Name one system of record and feed the others into it.
• Treating a scan as the inventory: discovery shows what is present; the inventory shows what is approved and owned. Both are needed.
• Cloud and SaaS left out: policies written for hardware miss short-lived cloud resources and services bought on a credit card. See the Shadow SaaS and Unsanctioned App Discovery Guide.
• Disposal without identity clean-up: decommissioned servers leave behind service accounts and keys that still work.

For implementation depth, see the CIS Control 1 Inventory and Control of Enterprise Assets Guide, the CIS Control 2 Inventory and Control of Software Assets Guide and the Asset Inventory and CMDB Security Guide.

References

• CIS: Control 1 Inventory and Control of Enterprise Assets
• CIS: Control 2 Inventory and Control of Software Assets
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Asset Inventory and CMDB Security Guide · Data Classification Policy Template · BYOD Policy Template · Media Sanitisation Guide · Service Account Security Guide