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 second edition separates them. Clause 7.5 still covers documented information and its control. Clause 7.6, data and information, is now its own requirement and reaches what the earlier placement could not: what data the organisation needs, what attributes it must 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. The separation is an acknowledgement of that.

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. Clause 7.6 sits 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

Quality has to be determined, not assumed

The clause asks the organisation 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 requirement that will cause the most work is the one about traceability 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 not a reconciliation inconvenience. It is that 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 the region is being handed this problem in a useful form

Saudi Arabia's Royal Decree No. 13059 of December 2016 requires government institutions to convert from cash to accrual accounting under IPSAS. Accrual accounting obliges an entity to recognise, value and depreciate what it controls, which requires it first to establish what it controls and where.

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

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

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.

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

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 substantially revised in the second edition. 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. Saudi Arabia's transition to accrual accounting is required by Royal Decree No. 13059 of December 2016. ISO 19650-3 covers information management during the operational phase. Standards published behind a paywall are cited without a link.