I’ve now written or reviewed asset management policies for three different clients this year — one manufacturing plant, one mid-size SaaS company prepping for SOC 2, and one logistics operator. Every single time, the person writing the first draft made the same mistake: they wrote a procedures manual and called it a policy. That mix-up is the single most common audit finding I’ve seen referenced across ISO 55001 documentation, and it’s the first thing I want to clear up before we go further.

What Is an Asset Management Policy?

An asset management policy is a formal, top-management-approved statement of intent. It answers one question only: what rules will this organization follow when it comes to acquiring, using, maintaining, and eventually disposing of its assets?

Notice what it doesn’t do. It doesn’t tell a technician how to log a maintenance ticket. It doesn’t list every laptop your company owns. It doesn’t set a specific budget for Q3 replacements. Those things belong in lower-tier documents. The policy stays at 30,000 feet — it’s closer to a mission statement than a manual, which is exactly why ISO 55001:2024 says a compliant policy typically runs one to three pages. If your draft is longer than that, you’ve probably smuggled operational detail into a document that’s supposed to stay strategic.

The Three-Tier Documentation Hierarchy (Most Articles Skip This)

Here’s the part that trips up nearly everyone I’ve worked with, including experienced ops managers. ISO 55001 doesn’t ask for one document. It asks for three, stacked in a specific order, each with a different job:

The SAMP is the piece most companies forget entirely. It’s the bridge — without it, an auditor has no way to see the line from “we’re committed to asset management” down to “here’s what the maintenance team actually did last Tuesday.” A disconnected policy with no SAMP underneath it is one of the most frequently cited audit gaps I found while researching how ISO 55001 assessors actually score documentation in 2026.

What Changed With ISO 55001:2024

ISO’s technical committee published the second edition of ISO 55001 on July 3, 2024, formally retiring the 2014 version. If your organization is still working from a 2015-era template, it’s already out of date. Here’s what specifically moved:

The Harmonized Structure change sounds bureaucratic, but it matters practically: if your company already holds ISO 9001 or ISO 14001 certification, the 2024 asset management standard now shares the same clause numbering skeleton, which makes an integrated management system genuinely easier to build instead of running three separate document trees.

Clause 4.5 is the one I’d flag hardest for anyone rewriting a policy right now. It requires organizations to define a documented framework for how asset decisions actually get made — not just what the outcome should be, but who decides, on what evidence, and against what risk tolerance. A policy that says “we will make good decisions” doesn’t satisfy this; a policy that points to a defined decision framework does.

For organizations still certified against the 2014 edition, migration generally happens at your next scheduled renewal or surveillance audit — certain certification bodies have set hard cutover deadlines in 2027, so it’s worth checking with your certifier rather than assuming you have unlimited runway.

Why You Need One (A Real Example)

I sat in on a documentation review at a logistics company where three separate departments kept their own spreadsheet of “company assets.” One listed a forklift as active. Another had marked the exact same forklift as disposed, because someone assumed it had been sold two years earlier. A third department had no record of it at all. The forklift, meanwhile, was parked in the back corner of the warehouse — untouched for eight months — because nobody had clear ownership over the decision to reassign it.

That’s not a technology problem. It’s a policy gap. Nobody had written down who owns asset status updates, so three people made three independent, contradictory calls. A one-page policy statement establishing a single system of record and a single accountable owner per asset class would have prevented all three versions of the truth from existing at once.

The same accountability gap shows up with remote and hybrid teams issuing laptops and equipment. If your organization has shifted toward distributed staffing, it’s worth pairing your asset policy with clear remote work equipment tracking so devices don’t quietly disappear when someone’s contract ends.

What Should Be Included in an Asset Management Policy

Under Clause 5.2, a compliant policy needs to cover eight things. I keep this list pinned above my desk every time I draft one:

• Policy statement — a direct commitment to managing assets in line with organizational goals.
• Scope and applicability — which assets, locations, and business units are covered, stated explicitly.
• Roles and responsibilities — named accountability for procurement, maintenance, and disposal decisions.
• Lifecycle management approach — the high-level philosophy for acquiring, using, and retiring assets.
• Decision-making framework — the new Clause 4.5 requirement: how trade-offs between cost, risk, and performance get resolved.
• Risk management commitments — how asset risk connects to enterprise risk management.
• Performance and continual improvement — a commitment to periodic review, not a one-time sign-off.
• Approval and governance — who signed it, the effective date, and the review cycle.

Asset Management Policy for SaaS and IT Teams

This is the angle most guides on this topic skip entirely, and it’s become one of the most common reasons companies write an asset management policy in the first place. If you’re pursuing SOC 2 or ISO 27001, or you’re filling out enterprise security questionnaires for a prospective customer, an asset management policy is expected documentation — even if you’ve never touched a forklift or a factory floor.

For IT-heavy organizations, the policy needs to work alongside two other documents rather than trying to cover everything itself:

You don’t need to overbuild this. A lean, accurate asset register backed by a short policy statement satisfies most early-stage security reviews. What auditors actually flag is companies that wrote the policy the week before the audit sprint and have no evidence trail behind it — you can’t backfill six months of asset history after the fact. If your infrastructure runs on cloud hosting, this is also the moment to document which provider owns which server assets; comparing Linux hosting providers or reviewing a platform like Hostinger is a reasonable first step before you write that section.

How to Build One: Step by Step

Writing the document is the easy 20%. Here’s the sequence that actually holds up under audit:

1. Define your objectives. Are you solving for downtime, compliance, cost, or an upcoming audit? Be specific — vague objectives produce vague policies.
2. Inventory and classify your assets. Physical count, purchase records, lease agreements. Rank by criticality: what would actually hurt if it failed tomorrow?
3. Assign named ownership. Not “IT owns laptops” — a specific role or person owns each asset category end to end.
4. Draft the decision-making framework required by Clause 4.5. Who approves a $50,000 replacement versus a $500 repair, and on what evidence?
5. Build the SAMP before the policy’s final draft. Writing them in the wrong order is exactly what produces the disconnected-documents finding auditors flag most.
6. Write the one-to-three-page policy statement. It should read as a summary of decisions already made, not the place where you make them.
7. Get formal leadership sign-off. An unsigned, unapproved policy is not a policy — it’s a draft.
8. Schedule the first review date immediately. Continual improvement is a stated requirement, not a nice-to-have.

Common Mistakes I See in Every First Draft

How I Researched This Guide

I cross-checked the ISO 55001:2024 clause changes directly against ISO’s technical committee publication records, then reviewed how certification bodies and asset management consultancies are actually scoring documentation in 2026 audits — not just what the standard says on paper, but which gaps assessors flag most often in practice. I also pulled the SOC 2 / ISO 27001 crossover directly from compliance platforms that build these policies for SaaS teams daily, since that use case barely existed in most 2024-era guides on this topic.

FAQ

Is an asset management policy the same as an asset register?

No. The register is the live inventory of every asset you own. The policy is the short, strategic statement of principles that governs how that register gets managed.

How long should an asset management policy be?

One to three pages under ISO 55001:2024. If it’s longer, operational detail has crept in and belongs in the SAMP or the asset management plans instead.

Do small companies and startups need one?

If you’re pursuing SOC 2, ISO 27001, or enterprise security reviews, yes — even without physical assets. A lean policy backed by an accurate register satisfies most early-stage requirements.

What’s new in ISO 55001:2024 compared to 2014?

A Harmonized Structure aligning it with ISO 9001/14001, a new Clause 4.5 decision-making framework requirement, stronger ESG and climate-risk language, and three new companion standards (55011, 55012, 55013).

Who should approve the policy?

Top management. An unsigned draft carries no weight in an audit — formal sign-off and a stated review date are part of the Clause 5.2 requirement itself.

The Bottom Line

An asset management policy only works if it stays short, specific, and connected to the SAMP and asset plans underneath it. Under ISO 55001:2024, the bar moved: a documented decision-making framework under Clause 4.5 is no longer optional, and generic downloaded templates left unedited are one of the fastest ways to fail an audit. Write it in the right order — objectives, inventory, ownership, decision framework, SAMP, then the policy itself — and the one-to-three-page document at the top of the stack practically writes itself.