Carbon-Aware SaaS Architecture: What CSRD and Green Procurement Questions Actually Require
Something shifted in enterprise procurement in 2025. Alongside the usual questions about uptime SLAs, SOC 2 status, and GDPR data processing agreements, vendor questionnaires started including a new section: environmental impact. Scope-3 emissions. Software Carbon Intensity scores. Annual GWh consumption estimates.
For most SaaS vendors, this came as a surprise. Carbon-aware SaaS architecture was a niche topic discussed at green computing conferences — not something that blocked a deal with a German manufacturing company or a UK financial services firm. That changed when CSRD reporting obligations started hitting mid-market European companies and the first wave of supply chain emissions data requests landed in inboxes.
This post covers what's actually required, how the engineering side works, and what enterprise buyers realistically accept as evidence when they ask these questions.
Why Procurement Teams Are Asking About Your Carbon Footprint
The Corporate Sustainability Reporting Directive (CSRD) requires large EU companies — and, from 2026, many medium-sized ones — to disclose scope-3 emissions in their sustainability reports. Scope 3, category 1 covers purchased goods and services. That includes SaaS subscriptions.
For a procurement manager at a 5,000-person German manufacturer trying to complete their ESRS E1 disclosures, your software is a line item in their supply chain emissions inventory. If you can't provide any data, they either exclude you from their supplier list, assign a conservative default estimate (which may be worse for their disclosures than your actual footprint), or simply choose a vendor who can answer the question.
The business pressure is real and growing. It is not limited to large enterprises — as CSRD cascades through supply chains, mid-market buyers are getting the same questions from their customers and passing them downstream.
Green procurement policies add a parallel pressure. Many public sector organisations across the EU — including German federal agencies, Scandinavian municipalities, and UK central government departments — have adopted sustainable procurement frameworks that include digital and software purchasing. The UK Government's Technology Code of Practice explicitly references sustainability, and Germany's KGSt guidance recommends environmental criteria in software procurement decisions.
None of this requires your SaaS to run on zero-carbon energy tomorrow. But it does require you to have a credible answer.
The Software Carbon Intensity Specification
The practical starting point is the Software Carbon Intensity (SCI) specification, maintained by the Green Software Foundation. It gives you a standardised, auditable formula:
SCI = (E × I) + M per R
Where:
- E = energy consumed by the software system (kWh)
- I = carbon intensity of the electricity grid (gCO₂eq/kWh)
- M = embodied carbon from hardware
- R = functional unit (per API call, per active user, per transaction — you choose and document it)
The SCI score tells you how carbon-intensive your software is relative to the work it does. Unlike a raw emissions number, it is independent of scale, which makes it suitable for vendor comparison.
For most SaaS applications running on major cloud providers, calculating E starts with your cloud billing data and the provider's published power usage effectiveness (PUE) and energy data. AWS publishes region-level carbon intensity data. Google Cloud has had carbon-free energy percentages by region for years. Azure's Emissions Impact Dashboard provides this programmatically via API.
The embodied carbon component (M) covers the carbon emitted manufacturing and eventually disposing of the physical hardware your workloads run on. For cloud-hosted software, you can use published cloud provider figures or the open-source Cloud Carbon Footprint tool, which pulls billing data from AWS, GCP, and Azure and calculates emissions estimates including embodied carbon.
What enterprise procurement teams typically accept as evidence: an SCI score calculated using documented methodology, the data sources used, and ideally a year-on-year comparison. They are not expecting a third-party audit on day one. A credible self-assessment with visible methodology is enough to unblock most deals.
Region Selection for Lower Carbon Workloads
The carbon intensity of electricity varies dramatically by geography, and cloud providers expose this at the region level. At time of writing, the greenest major cloud regions are typically those with access to significant hydroelectric or nuclear capacity: Stockholm, Oslo, Zurich, Oregon, and parts of Canada.
For a European SaaS application, choosing the right primary region matters. If your data residency requirements allow it — and many GDPR-compliant applications can host in eu-west-2 (London), eu-north-1 (Stockholm), or eu-central-1 (Frankfurt) — there is a meaningful difference in grid carbon intensity between these options.
Some teams go further and implement dynamic region selection for workloads that do not have strict latency requirements. Background processing jobs, report generation, ML inference, and data exports are all candidates for carbon-aware scheduling.
The Electricity Maps API (and the free-tier carbon intensity data it provides) lets you query current and 24-hour forecast carbon intensity by region. A simple implementation looks like this:
- Define a set of candidate regions where your workload is permitted to run.
- Query carbon intensity for each region at job dispatch time.
- Route the job to the lowest-carbon available region, subject to a maximum acceptable latency threshold.
- Log the region chosen and the carbon intensity at dispatch time — this feeds your SCI calculation.
This is not complex to implement in a background job system. If you are using Symfony Messenger, you can add a middleware that enriches messages with a target-region hint before dispatching to a remote queue consumer. The logic lives in one place and the application code is unaffected.
Carbon-Aware Scheduling for Background Jobs
Region routing is one lever. Time shifting is another. Grid carbon intensity follows predictable daily and weekly patterns in most markets. Solar-heavy grids like Germany's are cleanest at midday on weekdays and dirtiest in the early morning before solar ramps up. Wind-heavy grids like the UK's are more variable.
For workloads that have flexible timing — nightly ETL jobs, weekly report generation, cache warming, ML retraining — you can schedule them to run during low-carbon windows rather than at a fixed time.
The Green Software Foundation's carbon-aware SDK provides libraries for this pattern. You pass a time window and a desired execution duration, and the SDK queries the Electricity Maps forecast to suggest the lowest-carbon slot within your window. Integrating this with a cron scheduler or job queue dispatcher requires modest engineering effort.
The business case is twofold: it reduces your actual emissions, and it gives you a genuine engineering story to tell in procurement questionnaires. "We schedule non-time-sensitive batch jobs during low-carbon grid windows" is specific, credible, and distinguishes you from vendors who have simply reworded their cloud provider's data centre sustainability page.
What Goes Into a Vendor Sustainability Response
When an enterprise procurement team sends you a sustainability questionnaire, they are usually working from one of a small number of standard frameworks: EcoVadis, CDP (formerly Carbon Disclosure Project), or an internally developed template modelled on ISO 14001 principles. The questions are more consistent than they appear.
Here is what they are actually trying to establish, and how to answer each category:
Scope-3 upstream emissions methodology. They want to know how you estimate your software's contribution to their scope-3 inventory. Your SCI score, the methodology document, and the tool used (e.g. Cloud Carbon Footprint) is a complete answer.
Energy consumption. Total kWh consumed by your infrastructure per year, broken down by region if possible. Pull this from your cloud billing data. AWS Cost Explorer has an energy data export; GCP and Azure have equivalent APIs.
Renewable energy certificates or matched clean energy. Do you purchase RECs, EU GOs (Guarantees of Origin), or benefit from your cloud provider's Power Purchase Agreements? AWS, Google, and Azure all publish the percentage of renewable energy in each region. Note that RECs are market-based and do not guarantee your workloads ran on clean electrons — sophisticated buyers know this distinction. Location-based figures (grid average) and market-based figures (with RECs) should both be reported.
Carbon reduction targets. Have you set a Science Based Target (SBT) or made a similar commitment? If not, a documented internal target with a baseline year is a reasonable substitute at the SME level.
Infrastructure efficiency. Questions about virtualisation, serverless or container usage, auto-scaling (idle resource reduction), and CDN usage all feed into this. Most modern SaaS architectures already do these things — the question is whether you have documented them.
If you are working on a custom software development engagement or a legacy code modernization project that involves infrastructure redesign, this is the right time to build these practices in rather than retrofit them later.
Practical Implementation Priorities
If you are starting from zero, here is a sensible sequence:
First: measure. Run Cloud Carbon Footprint against your billing data and get a baseline number. This takes a few hours and costs nothing. You now have a number to report and a starting point for reduction.
Second: document your methodology. Write a one-page document describing how you calculated your SCI score, what data sources you used, and what your functional unit is. This is what procurement teams actually want to see.
Third: pick the lowest-carbon region your data residency requirements allow. For EU customers with GDPR requirements, eu-north-1 (Stockholm) and eu-west-1 (Ireland) are often meaningfully cleaner than eu-central-1 (Frankfurt) depending on the season. Check current figures before assuming.
Fourth: implement carbon-aware scheduling for your most intensive background jobs. Start with the highest-energy workloads — ML jobs, large batch exports, full-table analytics queries. Even shifting these to low-carbon windows moves your numbers.
Fifth: add monitoring. Export carbon metrics to your observability stack alongside CPU, memory, and latency. This keeps the data fresh for annual reporting and lets you track the impact of optimisations.
The Honest Limits of Current Practice
A few things worth being clear about:
Carbon-aware scheduling reduces emissions but does not eliminate them. For applications with strict latency requirements — interactive APIs, real-time features, anything user-facing — you cannot time-shift the work. Carbon awareness primarily helps background and batch workloads.
RECs and carbon offsets are genuinely contested. The Science Based Targets initiative no longer allows offsets to count toward near-term targets. Sophisticated buyers know this. If your sustainability position relies primarily on purchased offsets, that is likely to draw scrutiny.
The data quality for embodied carbon is still poor. Cloud providers publish estimates but the methodologies vary and the figures change as hardware generations turn over. Report what you have and be honest about its precision.
Sustainability reporting frameworks are evolving quickly. What counts as adequate evidence in a 2026 procurement questionnaire may not be sufficient in 2028 as CSRD enforcement matures and auditor expectations rise. Treat your current implementation as a foundation, not a permanent answer.
Getting Started
If you have a SaaS product and are starting to see these questions in procurement, the priority is measurement and documentation. A credible, methodologically sound SCI calculation that you can reference in a vendor questionnaire is worth more than aspirational commitments you cannot support with data.
For teams building carbon-awareness into a new architecture or a code modernization project, the engineering patterns — carbon-aware scheduling, low-carbon region routing, infrastructure efficiency — are well-established and increasingly supported by cloud provider tooling. The implementation effort is modest relative to the procurement and reputational benefit.
If you want to talk through what a carbon-aware architecture assessment would look like for your system, reach us at hello@wolf-tech.io or through wolf-tech.io. We are happy to review your current infrastructure and identify where the highest-impact changes are.
Frequently Asked Questions
Do I need a third-party audit to answer CSRD-related procurement questions? Not at the vendor level, at least not yet. Buyers are asking for your self-reported data and methodology. Third-party verification is required for the buying company's own CSRD disclosures, but for vendor questionnaires, a documented self-assessment is generally sufficient. This may tighten as CSRD matures.
Which cloud regions are the lowest carbon for EU-based SaaS? This changes with grid conditions, but eu-north-1 (Stockholm) consistently ranks among the cleanest due to Sweden's hydro and nuclear mix. eu-west-1 (Ireland) benefits from significant wind generation. eu-central-1 (Frankfurt) and eu-west-3 (Paris) vary more seasonally. Check Electricity Maps or your cloud provider's sustainability dashboards for current figures.
Is the SCI specification mandatory for CSRD compliance? No. CSRD does not mandate the SCI specification specifically. It requires scope-3 emissions reporting, and SCI is a useful methodology for calculating your software's contribution to that. You could use other methodologies, but SCI is increasingly the industry standard for software-specific emissions calculation.
What is the difference between location-based and market-based emissions accounting? Location-based accounting uses the average carbon intensity of the grid where your servers are located. Market-based accounting adjusts for renewable energy certificates or power purchase agreements you or your cloud provider has contracted. Both should be reported. Sophisticated buyers — particularly those working from GHG Protocol scope-3 guidelines — will ask for both figures.
Can carbon-aware scheduling break our SLA commitments? Only if it is applied to latency-sensitive workloads, which it should not be. Carbon-aware scheduling is appropriate for background jobs, batch processing, and non-urgent compute tasks where you have flexibility on timing. User-facing requests should not be routed based on carbon intensity.