Nothing tells you when a record stopped being true

An asset record is created once, accurately, by somebody who was looking at the thing.

Then a pump is replaced with a different model during a shutdown. A valve is relocated two metres. A circuit is reconfigured. A building is partitioned. None of those events sends a message to the register. Nothing anywhere announces that a record has stopped matching the world.

So the register ages, and confidence in it rises while its accuracy falls, because the people using it have been using it for years without anything going obviously wrong. The two curves cross at some point nobody can identify afterwards.

Why the clause was separated

In the 2014 edition, data lived inside documented information. That placement carried an assumption, and the assumption was that the problem with information is control: which version is current, who approved it, where it is held, how long it is retained.

Those are real problems and they are document problems. They are almost entirely unrelated to whether the content is true.

The 2024 edition keeps them apart. Clause 7.5 covers documented information. Clause 7.6 is titled data and information, and ISO/TC 251 lists it among the revised subclauses. The questions that matter for a register sit on the 7.6 side of that line, in this publication's reading: what data the organisation needs, what attributes it has to carry, what quality it has to meet, where it comes from, and how financial and non-financial data relate to each other.

A register can be perfectly controlled under 7.5, with version history, approvals and retention, and be substantially wrong.

That is this publication's reading of what the distinction achieves, and it is not what the committee said the revision was for. The two are worth setting beside each other, because the committee's stated reason is narrower than ours and a reader is entitled to know which one carries ISO's authority.

Requirements come from decisions, not from fields

There is a specific and very common inversion here, and it is expensive because it is usually locked in by a procurement.

The correct order is that the organisation determines what decisions it makes about its assets, then determines what data those decisions require, then acquires or configures a system that holds it. This publication reads Clause 7.6 as downstream of Clause 4.5 for that reason: until the decision criteria exist, there is no basis for saying which data matters.

What happens instead is that a system is selected, often for good reasons unrelated to asset management, and its data model becomes the organisation's data requirement by default. The fields that exist get populated. The fields that do not exist describe things the organisation will now not know.

A data requirement derived from a system tells you what the vendor thought was important. A data requirement derived from a decision tells you what you cannot afford to be wrong about.

The test is simple to run and mildly uncomfortable. Take one recurring asset decision, a renewal, a maintenance interval, a capacity change. Ask what data would be needed to make it well. Then ask whether the organisation holds that data, at what quality, and when it was last checked.

Where the decisions that define the data come from

, read: ISO 55001 now requires you to write down how you decideISO 55001 now requires you to write down how you decide

Quality has to be determined, not assumed

The reading here is that the organisation has to determine the quality its data needs to meet. That word matters, because most organisations have never stated one.

Data quality is usually discussed as if it were a single property that data either has or lacks. It is not. It has dimensions that trade against each other and against cost: completeness, accuracy, currency, consistency, and the resolution at which it is held. An organisation that has determined its quality requirement has said, for each significant data set, how good it needs to be and how often it must be reverified.

Absent that, there is no threshold, so there is no such thing as a failure, so nobody is accountable for one.

The practical version of this is a question with a date in the answer. For each significant data set: when was it last verified against the physical asset, by whom, and what proportion was checked. On most asset bases the honest answer for most data sets is that it has not been verified since it was created, and nobody has ever been asked.

ISO 55013 was published in the 2024 family specifically as guidance on managing asset data, which is a reasonable signal that the committee considered this the weak point.

The two views of the same asset

The alignment that will cause the most work is between financial and non-financial data.

Finance and engineering both maintain a description of the same physical estate. They were created at different times, by different people, from different sources, at different levels of breakdown, for different purposes. Finance needs an asset that can be capitalised, componentised for depreciation and derecognised on disposal. Engineering needs an asset that can be located, isolated, maintained and replaced.

Neither is wrong. They simply do not correspond, and nothing has ever obliged them to.

The consequence is a decision problem rather than a reconciliation inconvenience. Capital allocation happens in the financial view while deterioration happens in the technical one, and no reliable translation exists between them. A renewal case that is obvious to an engineer cannot be expressed in the terms the money is held in without manual work by whichever individual understands both systems.

That person exists in most organisations. There is usually one of them, and they are a single point of failure that no risk register records.

ISO/TS 55010 exists for exactly this, offering guidance on aligning the financial and non-financial functions. Its existence as a separate technical specification is the tell: this is common enough to need its own document.

Why Saudi entities are being handed this problem in a useful form

Decay is easiest to arrest at the moment a record is first assembled, and Saudi government entities are being made to assemble one. The Saudi Ministry of Finance describes High Order No. 13059 of December 2016 as approving the move of all government entities to accrual accounting, under Saudi public sector accounting standards that the Ministry bases on IPSAS. That conversion cannot be completed without establishing what is controlled and where it is.

That is an accounting reform whose by-product is the core dataset of an asset management system, produced under external audit.

It is a genuine opportunity and it is being half taken in a lot of places. A register built to satisfy the accounts will be complete, valued, and componentised on a depreciation logic. Whether it is also located, conditioned, and structured so an engineer can use it is a separate decision, taken quietly, usually by whoever is running the conversion, and usually without anyone framing it as a choice.

What the conversion does and does not deliver

, read: Accrual conversion gave three years. It did not give anyone a register.Accrual conversion gave three years. It did not give anyone a register.

The framework for this stage sets out how to examine data quality and the financial alignment alongside it.

The organisations that treat the conversion as a data exercise rather than an accounting one will finish with something that answers both questions. The rest will finish with a defensible balance sheet and the same operational blindness they started with, having paid for the fieldwork either way.

---

Sources. ISO 55001:2024, second edition, July 2024, ISO standard 83054, Clause 7.5 on documented information and Clause 7.6 on data and information, the latter listed by ISO/TC 251 as revised in the second edition; the clause titles and their positions are taken from the 2024 and 2014 contents in ISO's published preview pages. ISO/TC 251, Updated Guidance on Asset Management System Requirements, 2024, for the committee's account of the 7.6 revision: that it clarifies how data and information differ, that the requirements were made clearer and more concise, and that configuration is a key capability and a basis for decision-making. The reading that the distinction catches a controlled record which is false, and the list of what a data requirement covers, are this publication's inference and are not in the committee's note. ISO 55013, guidance on the management of asset data, and ISO/TS 55010, guidance on the alignment of the financial and non-financial functions, both identified by ISO 55001 as additional guidance. ISO 55000:2024, ISO standard 83053, which gives alignment among the three principles of asset management. IPSAS 33, first-time adoption of accrual basis IPSAS. The Saudi Ministry of Finance's accounting standards page describes the transition to accrual accounting as approved by High Order No. 13059 of December 2016. ISO 19650-3 covers information management during the operational phase.