The carbon footprint of IT infrastructure is the sum of greenhouse gas emissions generated by producing, powering and cooling equipment — in-house servers, cloud provider data centres and network hardware — expressed in tonnes of CO2 equivalent. Before a company can reduce it, it first needs to measure it in a way that is repeatable and comparable year over year.
Quick Overview
What you’ll learn from this article:
- How the GHG Protocol splits IT emissions into scopes 1, 2 and 3, and why this split is the starting point of any measurement
- How to calculate a first, approximate estimate of your own infrastructure’s carbon footprint
- Which data is essential and which can be added in a later iteration
- The most common mistakes in a first measurement and how to avoid them
Who this article is for: IT directors and people responsible for ESG reporting, infrastructure managers planning a first emissions audit, teams preparing for CSRD requirements.
Reading time: 6 minutes
Measuring the carbon footprint of IT infrastructure
The GHG Protocol, the most widely used emissions accounting standard, splits an organisation’s carbon footprint into three scopes. Scope 1 covers direct emissions — in an IT context practically absent, since companies rarely burn fuel for infrastructure purposes. Scope 2 covers emissions from purchased electricity powering in-house servers and office network hardware — this is where most of the measurable footprint sits for companies running their own server rooms. Scope 3 covers indirect emissions across the whole value chain: hardware manufacturing, cloud provider emissions, transport and disposal. For companies running mainly on public cloud, scope 3 is what accounts for most of the footprint — and it’s the hardest to calculate without data from the provider.
How to calculate a first estimate
- Gather energy consumption data — electricity bills for an in-house server room, or resource usage reports (CPU hours, storage) from a cloud provider if infrastructure runs entirely in the cloud.
- Apply an energy emission factor for the country or region where the servers are physically located — the same 1 kWh produces a different amount of CO2 in Poland (a grid mix with a large coal share) than in a country whose power comes mostly from renewables, so a data centre’s location directly affects the result.
- Multiply energy consumption by the emission factor to get scope 2 emissions in tonnes of CO2e — the simplest and most reliable component of a first measurement.
- Add a scope 3 estimate using open-source tools (e.g. Cloud Carbon Footprint for AWS, Azure and GCP), which translate cloud resource-usage metrics into emissions without needing access to the provider’s internal data.
- Document the methodology and assumptions, so next year’s measurement is comparable — a result without a documented method isn’t fit for ESG reporting.
One of the more common mistakes in a first measurement is limiting the scope to scope 2 only and skipping scope 3 — for companies running on public cloud, this can understate the real carbon footprint by several times over, because hardware manufacturing and a cloud provider’s physical infrastructure generate emissions that don’t disappear just because they don’t show up directly on an invoice.
| GHG Protocol scope | What it covers in IT | Ease of measurement |
|---|---|---|
| Scope 1 | Direct emissions (fuel, backup generators) | High — own data |
| Scope 2 | Purchased electricity for servers and network | High — utility bills |
| Scope 3 (upstream) | Hardware manufacturing, cloud provider emissions | Low — estimated data |
| Scope 3 (downstream) | Transport, hardware disposal at end of life | Low — no standard data |
The International Energy Agency (IEA) estimates that data centres and data transmission networks together account for a significant and growing share of global electricity consumption, driven mainly by growing AI-related workloads. For a company planning its first measurement, this means one thing: the more AI and machine learning infrastructure in the technology stack, the more significant the scope 3 footprint tied to the cloud provider becomes — and the harder it is to leave out of ESG reporting.
The Software Carbon Intensity (SCI) methodology from the Green Software Foundation takes a different approach than a classic total-emissions measurement: it counts emissions per functional unit (e.g. per user, per transaction, per API request). This approach is especially useful for engineering teams that want to compare the carbon footprint of two versions of the same application, rather than only reporting a single aggregate number once a year.
Read Also
- GreenOps and Sustainable IT - ESG Training for Tech Teams
- Cloud FinOps and Cost Control: A Practical Comparison of Approaches
Develop Your Skills
Want to learn how to report ESG in line with CSRD, using IT data and tools? Check out our training led by experienced EITT instructors.
➡️ CSRD & ESG Reporting with IT Tools: Compliance Automation — EITT training ➡️ ESG & CSRD: Sustainability Reporting — EITT training
Frequently Asked Questions (FAQ)
What’s the difference between scope 2 and scope 3 IT emissions?
Scope 2 covers emissions from electricity a company buys directly to power its own servers and network — easy to calculate from utility bills. Scope 3 covers indirect emissions across the whole value chain, including hardware manufacturing and emissions generated by a cloud provider’s data centres — harder to calculate, since it requires data a company usually doesn’t hold directly.
Does a company running entirely on public cloud still have an IT carbon footprint?
Yes, and most of that footprint usually falls under scope 3 — it covers emissions generated by the cloud provider’s (AWS, Azure, GCP) data centres and the manufacturing of the hardware the virtual infrastructure runs on. Major cloud providers publish sustainability reports and tools (e.g. the AWS Customer Carbon Footprint Tool) that make estimating this share easier.
How accurate does a first IT carbon footprint measurement need to be?
A first measurement doesn’t need to be precise down to the tonne of CO2 — what matters more is that the methodology is documented and repeatable in following years, so a trend can actually be compared. It’s worth increasing accuracy iteratively, starting from data the company already has (utility bills, cloud reports), rather than waiting for complete data from every source.
Does a data centre’s location affect the measurement result?
Yes, significantly — the same level of energy consumption produces a different amount of emissions depending on the energy mix of the country where the server room is physically located. Moving workloads to a cloud region with a higher share of renewable energy is one of the fastest ways to reduce a carbon footprint without changing the application itself.