[Paper] Mapping of the system of software-related emissions and shared responsibilities

Source: arXiv - 2512.13474v1

Overview

The paper presents a system‑wide map of where software‑related carbon emissions originate and who is responsible for them across the entire software lifecycle. By visualising the flow of energy use—from code creation to execution on hardware—the authors give ICT companies, developers, and policymakers a concrete tool for tracking and reducing their climate impact, aligning with emerging EU regulations such as the CSRD and CSDD.

Key Contributions

• Comprehensive emission taxonomy that categorises carbon sources at each stage of the software value chain (design, development, deployment, operation, maintenance, and end‑of‑life).
• Stakeholder responsibility matrix linking specific emission sources to the actors best positioned to act (e.g., developers, cloud providers, product owners, procurement teams).
• System‑mapping methodology that integrates existing life‑cycle assessment (LCA) data, energy‑intensity benchmarks, and regulatory requirements into a single, reusable diagram.
• Practical guidance for aligning software engineering processes with EU sustainability reporting obligations (CSRD, CSDD).
• Open‑source artefacts (the mapping diagram and accompanying metadata) released for community use and further refinement.

Methodology

1. Literature & Standards Review – Surveyed academic LCA studies, industry reports, and EU sustainability directives to identify known emission hotspots in ICT.
2. Lifecycle Decomposition – Broke the software lifecycle into eight granular activities (e.g., requirements engineering, CI/CD pipelines, runtime provisioning).
3. Data Aggregation – Collected energy‑intensity figures (kWh per compute unit, per storage byte, per network transfer) from public datasets (e.g., EPA, European Platform for Energy Efficiency) and vendor‑specific sustainability reports.
4. Mapping Construction – Using a systems‑thinking approach, plotted each activity’s energy demand, associated carbon factor (gCO₂e/kWh), and the primary stakeholder(s) responsible for decision‑making.
5. Validation – Reviewed the draft map with a panel of industry experts (cloud architects, product managers, sustainability officers) and refined it based on their feedback.

The result is a visual “emission‑responsibility matrix” that can be overlaid on existing software development workflows.

Results & Findings

*Based on aggregated industry averages; actual numbers vary by workload and provider.

Key take‑aways

• Runtime consumption dominates—optimising code efficiency and right‑sizing cloud resources yields the biggest carbon cuts.
• Development tooling is non‑trivial; inefficient CI pipelines can add a measurable carbon footprint.
• Shared responsibility is evident: no single actor can address emissions alone; coordinated governance is required.

Practical Implications

1. Carbon‑aware CI/CD pipelines – Integrate energy‑usage metrics into build dashboards; trigger alerts when builds exceed predefined carbon budgets.
2. Right‑sizing as a development practice – Adopt “performance‑first” coding guidelines (e.g., algorithmic efficiency, lazy loading) and use profiling tools that expose energy consumption.
3. Sustainable cloud contracts – Negotiate Service Level Agreements (SLAs) that include renewable‑energy sourcing percentages and provide visibility into per‑service carbon metrics.
4. Automated reporting for CSRD/CSDD – Feed the mapping directly into sustainability reporting tools, reducing manual effort and ensuring compliance.
5. Cross‑functional governance boards – Establish “green‑software” committees that bring together developers, product managers, procurement, and sustainability officers to act on the matrix’s recommendations.

Embedding these practices can lower operational costs (less compute = less spend) while meeting regulatory expectations and supporting sustainability claims.

Limitations & Future Work

• Data granularity – Relies on publicly available energy‑intensity figures, which may not reflect the latest hardware efficiencies or provider‑specific renewable mixes.
• Scope of software types – Focuses on typical cloud‑native applications; embedded or edge‑computing software may have different emission profiles.
• Dynamic workloads – Real‑time scaling behaviours (autoscaling, serverless bursts) are only approximated; finer‑grained telemetry would improve accuracy.

Future research directions

• Extending the matrix to edge/IoT ecosystems.
• Developing automated tooling that extracts per‑service carbon footprints directly from orchestration platforms (Kubernetes, Terraform).
• Conducting longitudinal case studies to quantify carbon savings after implementing the recommended governance processes.

Authors

• Laura Partanen
• Antti Sipila
• Md Sanaul Haque
• Jari Porras

Paper Information

• arXiv ID: 2512.13474v1
• Categories: cs.SE
• Published: December 15, 2025
• PDF: Download PDF