Controls per data point: value, signal, owner

A data point without a control is a number that happens to sit somewhere. It might be correct, it might be a typo, it might be an old version of a figure that has since been updated in another file. Without a control, you don't see the difference. The question of which controls belong to a data point is therefore not a technical detail but one of the core questions of data management for sustainability reporting.

Three layers, not one

A control on a data point consists of more than a limit value in a spreadsheet. At its core there are three things that must be established, and they should be defined separately from one another.

First: what is a valid value. Energy consumption cannot be negative. A percentage should lie between 0 and 100. A number of employees is a whole number. This sounds obvious, but in practice this is rarely made explicit per data point — it sits in the head of whoever once set up the spreadsheet, and disappears as soon as that person changes roles. What exactly a valid value is and what you do when a value falls outside it is worked out on the page about valid values and who notices when it goes wrong.

Second: what is a signal. A valid value is not the same as a plausible value. A consumption figure that falls within the permitted limits but is three times as high as last year is valid and at the same time a signal that someone should look at. A signal is therefore not a hard rejection but an indication: this deviates from the pattern, look at it before it flows on into the report. How you set up such a deviation and, just as importantly, who gets to see it, is worked out on the page about setting up a signal deviation and who notices it.

Third: who sees it. A control that reaches no one does not exist in practice, even if it exists on paper. If a value falls outside the limit or a signal fires, it must be established who receives the notification, within what time frame, and what happens if that person does not respond. This is usually the part that is missing: the rule exists, but ownership of the follow-up does not.

Why this is usually not established

In most organisations, sustainability data runs on spreadsheets that grew out of a first reporting obligation. There was pressure, there was a deadline, and there was someone who created a tab. Controls are often informal there: someone who knows the figure notices a strange outlier. That works until that person is on holiday, changes jobs, or the data point grows from ten to a hundred lines.

The result is that organisations often only discover that there was no control after an error has already made it into the report. At that point, the question is no longer which controls should have been in place, but how the report needs to be corrected — a more expensive and more visible question than necessary.

The pitfall: a tool on top of an empty process

There are systems that automatically detect limit values and deviations. Those systems are useful, but only if the underlying questions have already been answered: what is a valid value for this specific data point, what counts as a signal here, and who is the owner who receives the notification. A tool placed on top of an unorganised process mainly produces notifications that no one picks up, or limits that are set arbitrarily because no one had time to think them through properly. The control then looks automated, but is not so in substance. That is the same pitfall as false precision: a figure with many decimal places that suggests a precision the underlying data does not have. How you prevent that and who should be involved in keeping watch is explained on the page about preventing false precision and who notices it.

Controls belong to the data point, not to the report

A control that only exists at the moment of reporting comes too late. If a value is only checked when the report is being assembled, there is little chance that there is still time to correct the source — the pressure then lies on meeting the deadline, not on fixing the data. A control should therefore belong to the data point itself, at the moment it is entered or updated, with an owner who sees it before the figure moves further along the chain.

This is precisely what the data point register of the Data Readiness Scan is about: not setting up the report, but establishing per data point what a valid value is, what a signal is, and who the owner is who sees it. A complete overview of which controls belong to which data point and how ownership is arranged for this is summarised on the page that combines controls and ownership per data point. Anyone who is also struggling with definitions that are filled in slightly differently per country, brand or division will find the approach for that on the page about dealing with definitions that differ per division.

And then the question of who does the work

Working out valid values, signals and ownership per data point is exactly the kind of work that is partly regular in nature and partly requires judgement. Which part of that can be taken over by AI and which part a human must keep doing is not an estimate but a calculation. FTE TO AI offers the work scan for that: it calculates per task which part of the work can be taken over by AI, so that you don't guess but count.