A data point such as scope 1 emissions or absenteeism appears in a reporting framework with a name and a definition. What is not included: who in the organization determines what that definition means in practice, who supplies the source value, and who is responsible when the value does not align between entities. With a single entity, this can often still be reconstructed from habit. With multiple entities, each with its own bookkeeping, its own systems and sometimes its own interpretation of what an employee or a metric ton of CO2 is, ownership becomes a question that someone must actively answer.
Ownership of a data point is not the same question as ownership of a process or a control. This specifically concerns: who records what the data point means, which source systems count, and which calculation rule applies when two entities have used a different approach. That distinction is relevant, because the process around it and the control over it can lie with someone other than the person who owns the definition itself. What that difference means in practice is described on who owns the process underneath in a group with multiple entities and on who owns the control in a group with multiple entities.
A data point without a designated owner ends up, in practice, with an owner by chance: whoever last supplied the figure, or whoever received the question from consolidation. That person is usually not the one who can assess whether the definition holds for all entities, and often also not the one authorized to correct a deviating approach at a subsidiary.
In a group with multiple entities, the problem usually does not arise with the definition at group level, but with its translation into local sources. Entity A measures energy consumption via invoices from the energy supplier, entity B via a building management system, entity C estimates it based on square meters. All three call the result "energy consumption" under the same data point, but the origin, the accuracy and the assumptions differ. Without a designated owner who can see and assess these differences, that information disappears at the moment of consolidation: the figures are added up and the origin is lost.
The question of which value for a data point is actually valid — which source, which unit, which range — belongs with the owner of the data point, not with whoever happens to be compiling the report. What a valid value involves and how you record this per data point is explained on what is a valid value.
If no one owns a data point, a few things happen that only become apparent later. Questions about the definition are answered by whoever is reachable at that moment, not by whoever has the best answer. Discrepancies between entities go unnoticed, because no one has been tasked with comparing them. And during a review or audit, there is no point of contact who can explain why a value is what it is — only a collection of spreadsheets and the memory of whoever filled them in.
This pattern often repeats itself not with one data point but with a large part of the data point register at once, simply because ownership was never assigned as a separate topic when the reporting framework was introduced. The approach to solving this in a structured way — before it is solved at the level of an individual data point — is described on what do you do when no one is the owner in a group with multiple entities.
Assigning a name to a data point is a first step, not a solution. Ownership only has value if the owner also receives a signal when the value deviates from what may be expected — a jump between two periods, a value outside the usual range for that entity, a missing entry at a deadline. Without such a signal, ownership remains an administrative fact that no one actively uses. How you define a deviation that actually warrants a notification is explained on how do you set up a signal deviation.
Designating the owner of a data point is an organizational choice, not a technical one. It requires clarity about who within each entity knows the source value, who manages the definition at group level, and who is authorized to correct a deviation before it reaches the report. That is precisely the domain of the Data Readiness Scan: the data point register with ownership, origin and quality rules per data point, separate from the question of what the report will eventually look like. The scan is in development; anyone who wants to get started with this can sign up for the waiting list.
Assigning ownership, aligning definitions between entities and flagging deviations is work that is often still done manually, by email and spreadsheet. Part of these tasks — comparing source values, tracking down differences in definitions, monitoring signal deviations — lends itself to support by AI, another part does not. FTE TO AI's work scan calculates per task which part of that work can be taken over, so it becomes clear where automation helps and where the assessment remains with a human.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.