Data maturity is a term often used to place an organization on a scale: from level 1 to level 5, from ad hoc to optimized. Those scales are not without value, but they suggest a precision that usually isn't there for sustainability data. An organization is not mature or immature. Some data points are well substantiated, others hang on a single spreadsheet that one person understands. Measuring data maturity means, in practice: determining per data point where it comes from, who signs off on it, and what happens if that person is unavailable.
A maturity score from an external party gives an impression, but no action list. If the answer is "level 2 out of 5," you still don't know which data point is unreliable, which source is missing, or which employee is the only one who knows how a figure is built up. Data maturity is only useful as a measurement tool when it breaks down to the level of individual data points. Not: "the organization scores moderately," but: "this data point has no documented source, that data point has three that contradict each other."
There are three questions that deserve an answer per data point, and that together give a more realistic picture than an overall score.
The first is provenance: where does this figure come from, through which systems and processes, and is that path documented or only known to whoever has been doing it for years. This is precisely where the lineage of a data point changes what an organization can demonstrate: not the figure itself, but the path leading to it.
The second is ownership: who is responsible for this data point, and is that documented independently of the person who happens to be doing it now. Without that documentation, the question of who reads your data point register if the current owner is no longer there is not meant rhetorically, but is a real continuity risk.
The third is quality: are there rules that flag an error before the figure reaches the report, or is a deviation only discovered when an external party asks about it. That third question directly touches on the extent to which data is auditable for assurance: an auditor does not test whether the figure sounds plausible, but whether the substantiation holds up.
This way of measuring does not produce a figure with which you can compare yourself to another organization. It says nothing about what percentage of your data is "mature," because that threshold is arbitrary and differs by sector, by data point, and by assessor. Nor does it predict how long it takes to get from the current situation to a better one; that depends on how many data points there are, how many systems are involved, and how many people currently hold the knowledge only in their heads.
What the measurement does do is deliver a concrete overview: this data point is in order, that one is not, and this is exactly why. That overview is less impressive than a score on a scale of five, but it is the only thing that offers a basis for action.
The assumption that spreadsheets are the problem often leads to the conclusion that a new tool automatically raises maturity. That is not the case. As described in the analysis of why spreadsheets are not the core of the problem, the vulnerability often lies not in the file format but in the absence of documented provenance and ownership. A tool placed on top of a disorganized process produces neater overviews of the same unreliable figures. The order is: first determine what exists and where it comes from, only then choose which system supports that.
Measuring maturity does not begin with all the data an organization could ever conceivably report, but with the question of which data points are actually needed for the reporting obligations that apply. That delineation prevents a measurement from turning into an inventory of everything that has been documented somewhere, while the distinction between data points you actually need and data points you happen to already collect determines precisely what the measurement should focus on. Anyone who would rather work through this approach in a joint session than just read about it can find the setup described in what a data bootcamp involves and delivers.
This way of measuring is the first step, not the endpoint. Once it is clear which data points are weakly substantiated, who is missing as owner, and which quality rules do not yet exist, the question arises of how that is documented structurally: in a register, with lineage per data point and with rules that flag deviations before a report goes out the door. That is the work the Data Readiness Scan from csrdready.net is intended for. The scan is under construction; anyone who wants to get started with this already can sign up for the waiting list.
Once you know which data points need attention and who is responsible for them, the next question follows naturally: how much of the work around it — the retyping, the checking, the merging of sources — is work a machine can take over, and how much requires human judgment. The work scan from FTE TO AI calculates, per task, what portion of it can be taken over by AI, so that you don't guess but count.
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.