How to Write an Asset Management Policy (With Structure and Examples)

Asset management policies fail in one of two directions, and I've reviewed plenty of both.

Either it's three sentences that commit to nothing anyone could be held to, or it's fourteen pages that nobody has opened since the approval meeting. Neither changes what happens on a Tuesday.

A policy has one job: make it unambiguous who is responsible for what, and what has to happen at each stage. Everything else is procedure, and procedure belongs somewhere it can change without a governance cycle.

Structure

The clauses that actually matter

Scope, including the threshold

State the value threshold for capitalisation and, separately, the threshold for operational tracking. Conflating them is the most common policy error, because it leaves low-value portable equipment untracked — which is precisely what goes missing.

A single named owner of the register

Not a committee and not a department. One role, named, accountable for the register's accuracy. Registers without a named owner drift by default, and every subsequent clause depends on somebody being answerable.

Custody rules with a signature requirement

State that assets above a defined value are issued to a named individual and that acceptance is recorded. Include what happens on internal transfer and on departure — departures are the single most concentrated source of loss, and the policy should be explicit that recovery is initiated by the leaver process.

Disposal authorisation

State who can authorise disposal, what evidence is required, and — the part usually omitted — that the register record must be closed with a disposal date and method. Unclosed disposals create phantom assets that inflate every count afterwards.

Verification frequency

Commit to a frequency and a coverage target. "Periodically" commits to nothing. "Every asset verified at least annually, achieved through rolling quarterly counts by department" is a policy somebody can be held to.

Roles, in the only form that works

Most policies write this as a paragraph of prose and it settles nothing. A table settles it.

The first row is the one that decides whether any of this happens. A register owned by "the operations team" is owned by nobody, and it will drift by default.

Thresholds, stated separately

Two numbers, and conflating them is the most common policy error I see.

• Capitalisation threshold — the value above which an item goes on the fixed asset register. A finance decision.
• Tracking threshold — the value above which an item is individually tracked, tagged and issued to a named holder. An operational decision, and usually much lower.

State both. A policy with one number leaves everything below it untracked, and everything below it's where equipment quietly goes.

The disposal clause people forget

Disposal clauses usually cover authorisation and data destruction and stop there. The missing sentence is that the register record must be closed with a disposal date and method.

Unclosed disposals are the largest single source of phantom assets. They make every subsequent count look worse than reality, they waste time being searched for, and after a few years they make the register untrustworthy in a way that's very hard to unpick.

A review clause that will actually fire

"Reviewed periodically" means never. Name a date, name the owner, and tie the review to something that already happens — the end of the financial year, or the annual verification — so it isn't a standalone task competing with real work.

What to leave out

• Software names. Tools change; policies should outlive them.
• Screen-by-screen procedure. That is a work instruction, and it will be wrong within a release.
• Unenforceable liability clauses. Wage deductions for lost equipment are restricted in many jurisdictions; an unenforceable clause weakens the document.
• Aspirations. "Best-in-class asset stewardship" is not a rule anyone can follow or breach.

A structure you can copy

If you want somewhere to start, this is the skeleton I would use. Each section is a short paragraph or a list — the whole thing should fit on two pages.

Getting it approved without it being watered down

Policies get softened in review, usually by replacing anything measurable with something unfalsifiable. "Assets will be verified annually" becomes "assets will be verified periodically", and the policy stops meaning anything.

• Bring the baseline. A measured accuracy figure makes the case for a specific commitment far better than an argument does.
• Separate what is required from what is good practice, explicitly. Reviewers soften things because they cannot tell which is which.
• Name the owner before the meeting, ideally with their agreement. An unowned policy invites the vaguest possible wording.
• Accept a lower commitment rather than a vaguer one. Quarterly counts on high-value categories is a real policy; 'regular counts' is not.

Making it real

A policy takes effect through three things, none of which are the document.

1. A named owner who is actually asked about register accuracy at intervals.
2. A system that makes the policy the path of least resistance. If policy-compliant behaviour is slower than the alternative, the policy loses.
3. A measurement. Register accuracy, verification coverage and overdue inspections, reported somewhere visible.

Without those, the policy is a document that exists so somebody can point at it. With them, it's the description of how the organisation already behaves — which is what a good policy actually is.