The ICT sector differs from sectors with factories, vehicle fleets or buildings. A software company has no blast furnaces and usually no significant property of its own. At first glance, this makes the sector light on emissions, but the sustainability data hasn't disappeared — it has moved. It's not held in the company's own assets, but in the supplier chain, in contracts with cloud service providers, and in the equipment employees use. Anyone in ICT who only looks at their own office is missing most of the story.
For many ICT companies, the center of gravity of climate impact has shifted to the computing capacity they purchase. Anyone using AWS, Azure, Google Cloud or a local hosting provider is effectively buying energy consumption that is generated and accounted for elsewhere. The data on this usually isn't held in an internal system, but in invoices, service agreements and the sustainability reports cloud providers publish themselves. Some providers supply emissions figures per customer or per workload, others only a general average. The difference between the two determines how precisely a company can substantiate its own cloud-related emissions — and that difference is often unknown to whoever is putting the report together.
The second place where sustainability data accumulates is equipment: laptops, servers, network equipment, phones. This data arises at multiple points in the lifecycle. At procurement, information about material use and manufacturing emissions sits with the supplier, often in a product passport or environmental declaration that isn't requested by default. During use, IT management generates data on energy consumption of data centers and server rooms, sometimes in facilities systems, sometimes in IT asset management tools that don't communicate with finance. At disposal, new data arises again: reuse percentages, recycling certificates, contracts with electronic waste processors. Three phases, three types of sources, and rarely one place where they come together.
Companies that primarily deliver software or digital services face an additional complication: their product itself has no physical footprint, but it does run on infrastructure that does. The question of which part of the cloud emissions should be attributed to which product or which customer calls for allocation methods that are often not yet established. Anyone reporting on this must first determine which data point forms the basis — computing power, storage, data traffic — before there is anything to measure. That is a methodological choice that is separate from the report, but precedes it.
Because the sector is labor-intensive and has relatively few physical assets, staff-related items often carry more weight than in industrial sectors: commuting, working from home, business travel, the energy of office premises that are sometimes shared with other tenants. This data is spread across HR systems, travel booking platforms, facilities service providers and sometimes spreadsheets kept by an individual employee. The volume per item is small, but the number of sources is large, and that makes consolidation more time-consuming than the size would suggest.
In sectors such as construction or the real estate sector, the data is often concentrated around a limited number of physical locations or projects. In the ICT sector, the opposite is true: the data is thinly spread across many small, digital and contractual sources. That calls for a different approach when setting up a data point register — not starting with buildings or machines, but with contracts, systems, and the question of who within the organization manages which part of the chain.
Within an ICT company with multiple business units — for example a separate cloud, consultancy and software division — the same question keeps coming back: which data points do you actually need across multiple business units and where in the organization that data point already exists. Before asking again about cloud usage or hardware inventory, it's worth checking whether that data is already being kept somewhere, for example via where a data point already exists across multiple business units. That prevents each unit from building its own, slightly different version of the same figure.
The temptation with fragmented data is to first purchase a tool that makes everything look organized. However, a tool placed on top of an unorganized process mainly produces a neater-looking report about figures that are still not correct underneath. Getting clear first where each data point comes from, who is responsible for it and which quality rules apply to it, is the step that precedes system choices, not one that follows them.
Once it's clear which data points exist, where they come from and who manages them, it also becomes clear how much manual work still surrounds them: retyping, checking, tracking down with a colleague. That is exactly the kind of work for which FTE TO AI calculates, with a work scan per task, which part can be taken over by AI, as a complement to the insight a data point register already provides.
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.