ISO/IEC 21031 Software Carbon Intensity

What ISO/IEC 21031 is — and what it is not

ISO/IEC 21031:2024 specifies a methodology for calculating the rate of carbon emissions of a software system — its Software Carbon Intensity, or SCI, score. The standard’s stated purpose is to increase the awareness and transparency of an application’s sustainability credentials and to help software practitioners make evidence-based decisions during design, development and deployment that reduce emissions. It formalises, as an ISO/IEC international standard, the SCI specification originally developed by the Green Software Foundation (GSF).

The defining design choice is that SCI is a rate, not a total. Conventional carbon accounting — a GHG inventory under the GHG Protocol Corporate Standard or ISO 14064-1 — produces an absolute figure in tonnes of CO₂e for a reporting period, and lets an organisation offset or net that figure. SCI deliberately does the opposite: it expresses emissions per functional unit of useful work (per user, per API call, per machine-learning training job), and it excludes offsets and market-based measures entirely. The intent is that the only way to lower an SCI score is to make the software genuinely more efficient.

This is the most common point of confusion, so it is worth stating plainly: an SCI score is not a software carbon footprint. A footprint is a total; SCI is a rate. A software system with a low SCI score that serves billions of requests may emit far more in absolute terms than an inefficient system serving a handful of users. SCI is built to drive efficiency decisions, not to populate the emissions line of a regulatory disclosure.

Provenance, scope and status

The SCI specification began as a Green Software Foundation working-group project, with an initial version piloted in December 2021. After testing and refinement it was submitted through ISO/IEC JTC 1 — the joint technical committee of ISO and IEC responsible for information technology — and published as ISO/IEC 21031:2024, Edition 1, in March 2024 (approved 22 March 2024). It is the first international standard dedicated specifically to software carbon intensity.

The standard is voluntary. There is no jurisdiction in which an SCI score is itself a legal reporting requirement, which is why the banner above records “no mandated adoption date”. Its weight comes from adoption: technology organisations, cloud providers and engineering teams use it as the common language for software efficiency, and it is increasingly referenced alongside ESG reporting and IT-service sustainability programmes.

Where SCI sits in the carbon-accounting stack

SCI does not stand alone. It consumes outputs from the scientific and factor layers below it, and it feeds — with reconciliation — into the disclosure layer above it. Understanding those dependencies prevents the most common category error: treating an SCI score as if it were a disclosure-grade emissions figure.

The arrows run both ways in practice. The factor layer feeds I into the SCI equation; the SCI methodology structures the measurement; and the resulting energy and emissions data, once recast onto an average, market-based basis, flow up into a Scope 2 and Scope 3 inventory for disclosure. The reconciliation step is not optional, and it is where most implementation effort goes.

The SCI equation, variable by variable

The entire standard rests on one equation. Everything else — boundary rules, functional-unit selection, granularity guidance — exists to make the four terms in it well-defined and comparable.

Step 1 — Define the software boundary

The standard sets out a four-step procedure: define the boundary, choose the functional unit, quantify the emissions, and report. The boundary comes first because it determines what energy and embodied emissions are even in scope.

Defining the boundary means deciding which software components and supporting systems to include or exclude. The normative rule is that the calculation shall include all supporting infrastructure and systems that significantly contribute to the software’s operation. The specification does not hand you a fixed list — it requires judgement — but it does require that every major exclusion be documented with a reason.

Step 2 — Choose the functional unit (R)

R is what makes SCI an intensity rather than a total. It is the unit of work by which the software scales, and the standard requires that the same R apply across every term in the equation. Choosing it well is the difference between a score that guides engineering and a score that misleads.

The hard part is comparability. Because R is chosen by the reporting team, two SCI scores are only comparable if they share the same functional unit and the same boundary. A score expressed “per API call” cannot be set against one expressed “per user” without conversion. This is the standard’s most-debated limitation: it standardises the equation but not the choice of R, so cross-vendor comparison demands that both parties agree the functional unit in advance.

Step 3 — Quantify operational (O) and embodied (M) emissions

With the boundary and functional unit fixed, the third step quantifies the two halves of the numerator. They behave very differently and are measured in different ways.

Operational emissions — O = E × I

Operational emissions are the variable, demand-driven half. You measure the energy E that the in-boundary hardware draws to perform one functional unit of work, then multiply by the marginal carbon intensity I of the grid powering it. Where a data centre is in scope, E must reflect facility efficiency, which is why PUE belongs in the operational calculation: the IT load is scaled up by the data centre’s PUE to capture cooling and distribution losses. The standard pushes for the highest-granularity data available for both E and I — ideally real measured energy and time-resolved grid intensity rather than annual averages.

Embodied emissions — M = TE × TS × RS

Embodied emissions are the fixed, manufacturing half, amortised down to the software’s fair share. The total embodied emissions of a device (TE) — ideally drawn from the device’s own life-cycle assessment under ISO 14040/14044 — are multiplied by a time-share (TS, the fraction of the device’s useful life the software occupies) and a resource-share (RS, the fraction of the device’s capacity the software uses). The result allocates a slice of the hardware’s birth emissions to each functional unit of work.

Worked example — a web application’s SCI score

The figures below are illustrative — chosen to show the mechanics, not to represent any real system. They follow the SCI specification’s four steps end to end for a web application running on cloud infrastructure.

The score, 0.1782 gCO₂eq per request, is the deliverable. Its value is not in the absolute number but in its movement: shift the workload to a cleaner region and I falls; right-size the virtual machines and E falls; consolidate onto fewer, longer-lived instances and M per request falls. Each is an engineering decision the score makes visible. Note too that operational emissions dominate here — a common pattern for always-on cloud services, and the reason carbon-aware scheduling tends to deliver the largest reductions.

Marginal versus average carbon intensity

The single most technically important — and most contested — choice in the SCI specification is its use of marginal rather than average carbon intensity for the I term. The distinction matters because it is exactly where SCI and a GHG Protocol inventory part company.

SCI versus GHG Protocol and ISO 14067

SCI is often compared to the GHG Protocol and to product carbon footprinting under ISO 14067. All three quantify carbon, but they answer different questions and obey different rules. The matrix below sets them side by side.

The practical relationship is layered, not competitive. A GHG inventory tells the organisation that cloud and software emissions are material within Scope 2 and Scope 3 but offers little granularity to act on them. SCI supplies that granularity — per service, per request, in near-real time — and gives engineering teams a number they can move. The inventory remains the system of record for disclosure; SCI becomes the system of optimisation beneath it.

SCI and disclosure regimes — CSRD and IFRS S2

As software and cloud emissions grow as a share of corporate footprints, organisations subject to CSRD / ESRS E1 and IFRS S2 increasingly need a defensible methodology for the software portion of their inventory. SCI is the natural source of that engineering data — but it does not, on its own, produce a compliant disclosure.

Edge cases, exclusions and aggregation

Several rules in the specification only matter at the edges, but they are where SCI scores most often go wrong.

Implementation workflow and governance

Operationalising SCI is less about the one-off calculation than about wiring it into the engineering lifecycle so the score updates as the system changes. A workable governance pattern has four stages.

The standard’s third normative reporting requirement — disclose the SCI score, the software boundary, and the calculation methodology together — is what makes a published score trustworthy. A bare number with no boundary and no method is not an SCI score in any meaningful sense; the three travel together or not at all.

Tracking an SCI score over time

Because SCI is a rate, the value of measuring it compounds when it is tracked release over release. A falling SCI score against flat or growing traffic is the clearest possible evidence that efficiency work is paying off — the metric isolates efficiency from scale in a way an absolute footprint never can.

The trajectory above is illustrative, but the pattern it shows is the goal of the whole exercise: a score that bends downward as carbon-aware scheduling, region selection, right-sizing and hardware-lifetime extension take effect — each a lever the SCI equation makes legible.

SCI readiness checklist

This checklist covers the gaps between an intuition that “our software uses energy” and a defensible, reportable SCI score. Tick what is already true; the result panel summarises where the measurement stands.

Common measurement errors

Frequently asked questions