# Sustainability Architecture Assessment: [Workload or system name]

> Assessment of the environmental impact of a software system and of the architecture decisions that reduce it: boundary and functional unit, data sources, a Software Carbon Intensity (SCI) score with its operational and embodied parts, hotspots, levers (region and time shifting, demand shaping, efficiency, hardware lifetime, data), scenarios with recomputed scores, trade-offs with other qualities, targets, monitoring and decisions. The score follows the SCI method of ISO/IEC 21031:2024 (published from the Green Software Foundation SCI specification); levers are mapped to the AWS Well-Architected Sustainability pillar, the Azure Well-Architected sustainable workloads guidance and the Google Cloud Well-Architected Framework sustainability pillar; corporate reporting terms follow the GHG Protocol scopes. Replace every `[bracketed]` value and every row marked *Example*. The examples follow an order API running on eight dedicated servers.

<!--
Guidance: How to use this template
- Use it for one workload or product, at design time (to choose between options) and then periodically (to show progress). It is an architecture decision tool, not a corporate emissions report.
- Fix the boundary and the functional unit first (section 1). An SCI score is only comparable with another score that uses the same boundary and the same functional unit.
- Write down every factor you use (energy, carbon intensity, embodied emissions, lifetime) with its source and date (section 2). Most disagreements about results are disagreements about factors.
- Recompute the score for every option you propose (section 8). A lever without a recomputed number is an opinion.
- SCI does not allow offsets or market-based instruments to lower the score; report those separately if your organisation uses them.
- Related documents: FinOps Cost Review (`ops/finops-cost-review`), Cloud Adoption Strategy (`architecture/cloud-adoption-strategy`), Landing Zone Design (`architecture/landing-zone-design`), AWS Well-Architected Review (`architecture/aws-well-architected-review`), Azure Well-Architected Review (`architecture/azure-well-architected-review`), Google Well-Architected Review (`architecture/google-well-architected-review`), ISO 50001 Energy Review (`compliance/iso-50001-energy-review`), ISO 14001 Environmental Aspects (`compliance/iso-14001-environmental-aspects`).
-->

## Document control

<!-- Guidance: Identify the workload, the assessment period and who owns the result. A change of boundary, functional unit or factor source is a new major version, because earlier scores are then no longer comparable. -->

| Field | Value |
|---|---|
| Document ID | [SAA-001] |
| Workload or system | [Name and ID in the application inventory] |
| Assessment type | [Design-time option comparison / Baseline / Periodic re-assessment] |
| Assessment period | [YYYY-MM-DD to YYYY-MM-DD] |
| Functional unit (R) | [Per API call / per user per month / per transaction / per GB processed] |
| Hosting | [Provider and regions / On-premises data centre] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@sustainability-lead], [@finops-lead], [@platform-lead], [@product-owner] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Architecture description], [FinOps review], [Corporate GHG inventory] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Product owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Sustainability lead | [@name] | [Decision] | YYYY-MM-DD |
| FinOps lead | [@name] | [Decision] | YYYY-MM-DD |
| Architecture board | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Baseline score approved; scenarios B and C accepted for the roadmap |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Re-assessment after right-sizing; carbon intensity factor updated to the latest annual value |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope, boundary and functional unit](#1-scope-boundary-and-functional-unit)
2. [Method and data sources](#2-method-and-data-sources)
3. [Component inventory](#3-component-inventory)
4. [SCI baseline calculation](#4-sci-baseline-calculation)
5. [Hotspot analysis](#5-hotspot-analysis)
6. [Provider framework mapping](#6-provider-framework-mapping)
7. [Levers](#7-levers)
8. [Scenarios and recomputed scores](#8-scenarios-and-recomputed-scores)
9. [Trade-offs with other qualities](#9-trade-offs-with-other-qualities)
10. [Targets and indicators](#10-targets-and-indicators)
11. [Monitoring and reporting](#11-monitoring-and-reporting)
12. [Decisions and action plan](#12-decisions-and-action-plan)
13. [Review checklist and traceability](#13-review-checklist-and-traceability)
14. [Glossary and references](#14-glossary-and-references)

## 1. Scope, boundary and functional unit

<!-- Guidance: The boundary lists every component that contributes significantly to running the software, including infrastructure such as load balancers, storage, logging, CI runners and idle standby capacity. The functional unit (R) is how the system scales, so the score stays meaningful as usage grows. Common pitfall: excluding standby, test and observability environments, which often use as much energy as production. -->

### 1.1 Purpose and questions

[State why this assessment is done and which decisions it will inform.] *Example:* Compare three hosting options for the order API before the 2027 platform renewal, and set a carbon intensity target per order that the product team can track release by release.

Questions this assessment answers:

1. What is the carbon intensity of the workload per functional unit today?
2. Which components and which part (operational or embodied) dominate it?
3. Which architecture options reduce it, by how much, and at what cost to reliability, performance and spend?
4. Which target and which indicators will the team own?

### 1.2 Software boundary

| Component group | In boundary | Reason if excluded |
|---|---|---|
| Production compute *(Example)* | Yes | |
| Production storage and backups *(Example)* | Yes | |
| Networking inside the provider (load balancers, gateways) *(Example)* | Yes | |
| Data transfer to end users over the internet *(Example)* | No | No reliable factor available; noted as a limitation |
| End-user devices *(Example)* | No | Out of the team's control for an API; revisit for the web front end |
| Disaster recovery standby *(Example)* | Yes | Always-on capacity |
| Non-production environments *(Example)* | Yes | Run 24 hours a day today |
| CI/CD runners and build caches *(Example)* | Yes, apportioned | Shared runners; allocation by build minutes |
| Observability (logs, metrics, traces) *(Example)* | Yes | High retention volumes |
| [Group] | [Yes / No / Apportioned] | [Reason] |

### 1.3 Functional unit

| Item | Value |
|---|---|
| Functional unit (R) | *Example:* One successful order API call |
| Reason | *Example:* Calls grow with business volume; the product team already tracks them |
| Volume in period | *Example:* 45,000,000 calls in a 30-day month |
| Source of volume | *Example:* API gateway metrics, successful responses only |

## 2. Method and data sources

<!-- Guidance: Name the method, give the formula and record every factor with its source, date and quality. Prefer measured energy where you can get it and modelled energy where you cannot, and say which you used per component. Common pitfall: mixing a provider's market-based figures with location-based grid factors in one score. -->

### 2.1 SCI method

The SCI score is a rate of carbon emissions per functional unit, not a total. ISO/IEC 21031:2024 and the Green Software Foundation SCI specification express it as:

```text
SCI = ((E x I) + M) per R

E  energy consumed by the software in the boundary (kWh)
I  location-based carbon intensity of that energy (gCO2e per kWh)
M  embodied emissions of the hardware, apportioned to the software (gCO2e)
R  functional unit

M  = TE x (TiR / EL) x (RR / ToR)
TE total embodied emissions of the hardware
TiR time the hardware is reserved for the software in the period
EL expected lifespan of the hardware
RR resources reserved for the software (for example vCPUs)
ToR total resources of the hardware
```

The method has five steps, which this template follows: bound the system (section 1.2), choose the functional unit (section 1.3), choose a quantification method per component (section 3), quantify (section 4), and report the score with its boundary and method (section 11). The score is the sum of the scores of its components. Offsets, renewable energy certificates and other market-based instruments do not reduce an SCI score; the score can only fall by using less energy, using lower-carbon energy or using less hardware.

### 2.2 Relation to corporate reporting

| GHG Protocol scope | What it covers | Where this workload appears |
|---|---|---|
| Scope 1 | Direct emissions from owned sources | *Example:* Diesel generators in the owned data centre |
| Scope 2 | Purchased electricity, heat and cooling | *Example:* Electricity of the owned data centre (location-based and market-based reported separately) |
| Scope 3 | Other indirect emissions in the value chain | *Example:* Cloud services (purchased goods and services); embodied emissions of purchased servers (capital goods) |

Keep the SCI score for engineering decisions and leave the corporate inventory to the sustainability team; agree with them which factors both use. The GHG Protocol is revising its Scope 2 guidance (public consultation 2025 to 2026); check ghgprotocol.org for the current status before relying on market-based rules.

### 2.3 Factors and sources

| Factor | Value | Source and date | Quality |
|---|---|---|---|
| Server average power | *Example:* 0.2 kW per server at observed utilisation | Power metering on PDUs, 30-day average | Measured |
| PUE of the data centre | *Example:* 1.2 | Facility report for the last 12 months | Reported |
| Storage and network energy | *Example:* 150 kWh per month | Model from provider guidance and device datasheets | Modelled |
| Grid carbon intensity (I) | *Example:* 350 gCO2e per kWh | National grid annual average, location-based, [year] | Published |
| Embodied emissions per server (TE) | *Example:* 1,200 kgCO2e | Manufacturer product carbon footprint sheet | Published, model-level |
| Expected lifespan (EL) | *Example:* 4 years (35,040 hours) | Asset refresh policy | Policy |
| Cloud provider emissions data | [Value] | [Provider carbon tool export, method version] | [Provider-calculated] |
| [Factor] | [Value] | [Source, date] | [Measured / Modelled / Reported / Published / Policy] |

## 3. Component inventory

<!-- Guidance: List each component in the boundary with its resources, utilisation and quantification method. Utilisation is the most useful column: low utilisation means energy and embodied emissions spent for no work. Common pitfall: listing only what is in the bill; shared platforms and idle standby rarely appear as line items. -->

| Comp ID | Component | Environment | Resources | Average utilisation | Hours in period | Quantification | Owner |
|---|---|---|---|---|---|---|---|
| CMP-01 *(Example)* | Order API servers | Production | 8 dedicated servers | 22% CPU | 720 | Measured power | Platform |
| CMP-02 *(Example)* | Database cluster | Production | Included in CMP-01 for this example | 35% CPU | 720 | Measured power | Data |
| CMP-03 *(Example)* | Storage and backups | Production | 40 TB | Not applicable | 720 | Modelled | Platform |
| CMP-04 *(Example)* | DR standby | DR site | Included in CMP-01 (2 of 8 servers) | 3% CPU | 720 | Measured power | Platform |
| CMP-05 *(Example)* | Test environments | Non-production | Shared virtual hosts, 16 of 64 vCPUs | 9% CPU | 720 | Apportioned | Engineering |
| CMP-06 *(Example)* | Logs and traces | Production | 30 days hot, 1 year cold | Not applicable | 720 | Modelled | SRE |
| [CMP-nn] | [Component] | [Env] | [Resources] | [%] | [h] | [Method] | [@owner] |

Note: in the worked example below, CMP-02 and CMP-04 run on the eight servers of CMP-01, and CMP-03 and CMP-06 are in the 150 kWh storage and network figure; CMP-05 is shown separately in section 4.3 to illustrate apportioning on shared hardware.

## 4. SCI baseline calculation

<!-- Guidance: Show the arithmetic, not only the result, so that a reviewer can repeat it. Keep units explicit at every step and round only the final score. Common pitfall: forgetting PUE for on-premises or colocation servers, or adding it twice when the provider's figure already includes it. -->

### 4.1 Operational emissions (E x I)

| Step | Calculation | Result |
|---|---|---|
| Server energy | 8 servers x 0.2 kW x 720 h x PUE 1.2 | 1,382.4 kWh *(Example)* |
| Storage and network energy | From section 2.3 | 150.0 kWh *(Example)* |
| E | 1,382.4 + 150.0 | 1,532.4 kWh *(Example)* |
| I | From section 2.3 | 350 gCO2e/kWh *(Example)* |
| E x I | 1,532.4 x 350 | 536,340 gCO2e *(Example)* |

### 4.2 Embodied emissions (M)

| Step | Calculation | Result |
|---|---|---|
| Per server | 1,200,000 g x (720 h / 35,040 h) x (1 / 1) | 24,657.53 gCO2e *(Example)* |
| M for 8 dedicated servers | 8 x 24,657.53 | 197,260.27 gCO2e *(Example)* |

### 4.3 Apportioning on shared hardware

*Example:* The test environments (CMP-05) use 16 of 64 vCPUs on a shared host with TE of 1,500 kgCO2e and EL of 5 years (43,800 hours). For 720 hours: M = 1,500,000 x (720 / 43,800) x (16 / 64) = 6,164.38 gCO2e. Add their energy, apportioned by the same share, to E when they are in the boundary. The worked baseline below covers CMP-01 to CMP-04 and CMP-06 only, so that the arithmetic stays easy to follow.

### 4.4 Score

| Item | Value |
|---|---|
| (E x I) + M | 536,340 + 197,260.27 = 733,600.27 gCO2e *(Example)* |
| R | 45,000,000 calls *(Example)* |
| SCI | 733,600.27 / 45,000,000 = 0.0163 gCO2e per call, that is 16.30 mgCO2e per call *(Example)* |
| Share operational | 536,340 / 733,600.27 = 73.1% *(Example)* |
| Share embodied | 197,260.27 / 733,600.27 = 26.9% *(Example)* |

Consequences: [state what the numbers mean for the design.] *Example:* Operational emissions dominate, so region choice and right-sizing are the first levers; once the grid factor falls, embodied emissions will dominate and hardware lifetime and utilisation become the main levers (section 8).

## 5. Hotspot analysis

<!-- Guidance: Rank components by their contribution and look for waste: idle capacity, over-retention, chatty designs and work done that nobody uses. Common pitfall: optimising the code path that is easiest to change rather than the component that emits the most. -->

| Rank | Component or behaviour | Share of score | Cause | Candidate lever |
|---|---|---|---|---|
| 1 *(Example)* | Order API and database servers (6 of the 8 servers, 22% and 35% utilisation) | About 70% | Sized for an annual peak that lasts two weeks | Right-size and autoscale (LEV-02) |
| 2 *(Example)* | DR standby running hot (2 of the 8 servers, 3% utilisation) | About 23% | Warm standby with full capacity | Smaller pilot-light standby if RTO allows (LEV-05) |
| 3 *(Example)* | Grid carbon intensity of the current region | Multiplies all operational energy | Region chosen for latency in 2019 | Move to a lower-carbon region (LEV-01) |
| 4 *(Example)* | Logs kept hot for 30 days | Part of the 7% storage and network share | Default retention | Sample debug logs; shorten hot retention (LEV-06) |
| 5 *(Example)* | Batch reconciliation at 18:00 | Small, but at peak grid intensity | Historical schedule | Shift to low-intensity hours (LEV-03) |
| [Rank] | [Component] | [%] | [Cause] | [LEV-nn] |

Working for the shares *(Example)*: the eight servers emit 1,382.4 x 350 = 483,840 g operational plus 197,260.27 g embodied, that is 681,100.27 g or 92.8% of 733,600.27 g. Each server carries the same power and embodied factors, so each is 1/8 of that, about 11.6% of the score: the six API and database servers are about 69.6% and the two DR servers about 23.2%. Storage, network and logs together are 150 x 350 = 52,500 g, about 7.2%. Region carbon intensity (rank 3) is not a share: it scales the whole operational 73.1%.

## 6. Provider framework mapping

<!-- Guidance: Use the provider frameworks as checklists of areas to look at, in your own words. Record which area each finding and lever belongs to so that the assessment lines up with a Well-Architected review. Common pitfall: copying provider question text into the report; paraphrase and cite instead. -->

| Area | AWS Sustainability pillar best practice area | Azure Well-Architected sustainability guidance | Google Cloud sustainability pillar principle | Findings and levers |
|---|---|---|---|---|
| Placement | Region selection | Design methodology (region and placement choices) | Use regions that consume low-carbon energy | *Example:* LEV-01 |
| Demand | Alignment to demand | Cost Optimization and Performance Efficiency recommendations | Optimize resource usage for sustainability | *Example:* LEV-02, LEV-03 |
| Software | Software and architecture | Performance Efficiency recommendations | Develop energy-efficient software | *Example:* LEV-04 |
| Data | Data management | Operational Excellence recommendations (telemetry) | Optimize data and storage for sustainability | *Example:* LEV-06 |
| Hardware | Hardware and services | Reliability recommendations (redundancy sizing) | Optimize AI and ML workloads for energy efficiency, where relevant | *Example:* LEV-05, LEV-07 |
| Process | Process and culture | Design methodology and governance | Continuously measure and improve; promote a culture of sustainability; align with industry guidelines | *Example:* Section 11 |

Provider tools to source data, where available: the AWS Customer Carbon Footprint Tool, Carbon optimization in Azure (Microsoft has announced that the Power BI Emissions Impact Dashboard for Azure retires on 31 March 2027, so export its history before then) and Google Cloud Carbon Footprint. Check each tool's current name and method page before use. Each uses its own method and boundary; record the method version and do not mix their outputs with your own factors in one score without saying so.

## 7. Levers

<!-- Guidance: List the levers that apply, with the term of the formula each one changes (E, I, M or R) and a first estimate of effect. A lever that does not change a term does not change the score. Common pitfall: counting the same saving twice, for example right-sizing and autoscaling the same servers. -->

| Lever ID | Lever | Term changed | Description | First estimate | Constraints |
|---|---|---|---|---|---|
| LEV-01 *(Example)* | Region shift | I | Move the workload to a region whose grid intensity is about 50 gCO2e/kWh | Operational part falls by about 86% | Latency to users; data residency (`compliance/data-residency-sovereignty-assessment`) |
| LEV-02 *(Example)* | Right-size and autoscale | E, M | Run 5 servers on average instead of 8 | E and M fall by about 34% and 38% | Peak capacity and scale-out time |
| LEV-03 *(Example)* | Time shifting | I | Schedule deferrable batch when the grid is cleaner | Small; depends on hourly intensity data | Batch deadlines; need for hourly factors |
| LEV-04 *(Example)* | Efficient code paths | E | Cache catalogue lookups; remove a redundant serialisation step | To be measured by load test | Engineering effort |
| LEV-05 *(Example)* | Lighter DR pattern | E, M | Pilot light instead of warm standby | Removes most standby energy | RTO must still be met (`architecture/resilience-tiering-ha-dr-design`) |
| LEV-06 *(Example)* | Telemetry and retention | E | Sample debug traces, shorter hot retention, cold tier for audit logs | A few percent | Audit and incident needs |
| LEV-07 *(Example)* | Extend hardware life | M | Keep servers 6 years instead of 4 | M falls by one third | Support contracts, failure rates, efficiency of newer hardware |
| LEV-08 *(Example)* | Demand shaping | R, E | Batch small client calls into bulk requests | Fewer calls, less overhead per order; note that R changes meaning if the unit changes | Client changes; keep the same functional unit when comparing |
| [LEV-nn] | [Lever] | [Term] | [Description] | [Estimate] | [Constraints] |

## 8. Scenarios and recomputed scores

<!-- Guidance: Combine levers into scenarios and recompute the full score for each, with the same boundary and functional unit as the baseline. Show which part dominates after each step, because that tells you the next lever. Common pitfall: reporting a percentage saving without the absolute scores behind it. -->

| Scenario | Levers | E (kWh) | E x I (g) | M (g) | SCI (mgCO2e per call) | Change from baseline |
|---|---|---|---|---|---|---|
| Baseline *(Example)* | None | 1,532.4 | 536,340 | 197,260.27 | 16.30 | |
| A *(Example)* | LEV-02 (5 servers) | 1,014.0 | 354,900 | 123,287.67 | 10.63 | -34.8% |
| B *(Example)* | LEV-02 and LEV-01 (I = 50) | 1,014.0 | 50,700 | 123,287.67 | 3.87 | -76.3% |
| C *(Example)* | B and LEV-07 (EL = 6 years) | 1,014.0 | 50,700 | 82,191.78 | 2.95 | -81.9% |
| [Scenario] | [Levers] | [E] | [ExI] | [M] | [SCI] | [%] |

Working for scenario A: E = 5 x 0.2 x 720 x 1.2 + 150 = 1,014.0 kWh; E x I = 1,014.0 x 350 = 354,900 g; M = 5 x 24,657.53 = 123,287.67 g; SCI = (354,900 + 123,287.67) / 45,000,000 = 10.63 mg per call. Scenario B keeps E and M and changes I: 1,014.0 x 50 = 50,700 g; SCI = 173,987.67 / 45,000,000 = 3.87 mg. Scenario C changes EL to 52,560 hours: M = 5 x 1,200,000 x 720 / 52,560 = 82,191.78 g; SCI = 132,891.78 / 45,000,000 = 2.95 mg.

Consequences: *Example:* After scenario B, embodied emissions are about 71% of the score (123,287.67 / 173,987.67), so further gains come from utilisation and hardware lifetime, not from more region changes. Moving to a managed or serverless service would transfer M to the provider's shared hardware at a higher utilisation; model it with the provider's data before deciding.

## 9. Trade-offs with other qualities

<!-- Guidance: Sustainability levers interact with reliability, performance, security and cost. Record each interaction and the decision rule you apply. Common pitfall: cutting redundancy to save carbon without the owner of the recovery objectives agreeing. -->

| Lever | Reliability | Performance | Security and compliance | Cost | Decision rule |
|---|---|---|---|---|---|
| LEV-01 Region shift *(Example)* | Neutral if the new region has the same zone count | +25 ms latency for users in the home country | Residency review needed | Region prices differ by about 5% | Accept if p95 latency stays within the SLO and residency allows |
| LEV-02 Right-size *(Example)* | Risk during sudden peaks | Scale-out takes 3 minutes | Neutral | Saves about a third of compute | Accept with pre-scaling for known peaks |
| LEV-05 Lighter DR *(Example)* | RTO rises from 15 to 60 minutes | Neutral | Neutral | Saves standby cost | Accept only if the tier allows a 60-minute RTO |
| LEV-06 Retention *(Example)* | Less data for incident analysis | Neutral | Audit logs must remain complete | Saves storage | Keep audit logs; sample debug data only |
| [Lever] | [Effect] | [Effect] | [Effect] | [Effect] | [Rule] |

Cost and carbon usually move together (removing waste reduces both), but not always: a cheaper region can have a higher grid intensity, and commitments bought for three years can lock in oversized capacity. Review these levers together with FinOps Cost Review (`ops/finops-cost-review`).

## 10. Targets and indicators

<!-- Guidance: Set a target on the intensity (per functional unit) and, separately, watch the absolute total, because a falling intensity with fast growth can still raise total emissions. Assign an owner to each indicator. Common pitfall: a target with no date or no owner. -->

| ID | Indicator | Baseline | Target | Date | Owner |
|---|---|---|---|---|---|
| SUS-KPI-01 *(Example)* | SCI per successful order call | 16.30 mgCO2e | 4.0 mgCO2e | YYYY-MM-DD | Product owner |
| SUS-KPI-02 *(Example)* | Absolute monthly emissions in boundary | 733.6 kgCO2e | Below 250 kgCO2e | YYYY-MM-DD | Platform lead |
| SUS-KPI-03 *(Example)* | Average CPU utilisation of production compute | 22% | Above 45% | YYYY-MM-DD | Platform lead |
| SUS-KPI-04 *(Example)* | Non-production hours running outside working time | 100% | Below 30% | YYYY-MM-DD | Engineering manager |
| SUS-KPI-05 *(Example)* | Hot log volume per million calls | [Value] | [Value] | YYYY-MM-DD | SRE lead |
| [SUS-KPI-nn] | [Indicator] | [Value] | [Value] | YYYY-MM-DD | [@owner] |

## 11. Monitoring and reporting

<!-- Guidance: Decide how the score is recomputed (automatically from metrics where possible), how often, and who sees it. Report the score together with its boundary and method, as the SCI method asks. Common pitfall: a one-off assessment that is never repeated, so no one knows whether the levers worked. -->

| Item | Decision |
|---|---|
| Recalculation frequency | *Example:* Monthly from platform metrics; full review each year or on architecture change |
| Data pipeline | *Example:* Power and utilisation metrics, request counts and factor table feed a scheduled job that writes the score to the engineering dashboard |
| Factor updates | *Example:* Grid intensity updated yearly; embodied factors on hardware change; changes logged in the revision history |
| Release gate | *Example:* A release whose load test shows more than 10% higher energy per call needs a recorded decision |
| Report content | *Example:* Score, boundary, functional unit, factor table, method per component, changes since last report |
| Audience | *Example:* Product team, architecture board, sustainability team (input to their Scope 3 estimate) |
| Disclosure | *Example:* Published internally only; any public claim reviewed by legal and sustainability teams |
| [Item] | [Decision] |

## 12. Decisions and action plan

<!-- Guidance: Turn accepted levers into decisions and actions with owners and dates, and record rejected levers with the reason. Common pitfall: an action list with no link back to the scenario it is meant to deliver. -->

### 12.1 Decisions

| ID | Decision | Scenario | Reason | Date |
|---|---|---|---|---|
| SAA-DEC-01 *(Example)* | Right-size order API to 5 servers with autoscaling | A | Largest saving with low risk; also saves cost | YYYY-MM-DD |
| SAA-DEC-02 *(Example)* | Move to region R2 at the 2027 platform renewal | B | Latency and residency reviews passed | YYYY-MM-DD |
| SAA-DEC-03 *(Example)* | Rejected: lighter DR pattern | Not used | Tier 1 RTO of 15 minutes cannot be met with pilot light | YYYY-MM-DD |
| [SAA-DEC-nn] | [Decision] | [Scenario] | [Reason] | YYYY-MM-DD |

### 12.2 Actions

| ID | Action | Owner | Due | Delivers |
|---|---|---|---|---|
| SAA-ACT-01 *(Example)* | Configure autoscaling and pre-scaling calendar | [@platform-lead] | YYYY-MM-DD | SAA-DEC-01 |
| SAA-ACT-02 *(Example)* | Schedule non-production shutdown outside working hours | [@engineering-manager] | YYYY-MM-DD | SUS-KPI-04 |
| SAA-ACT-03 *(Example)* | Automate monthly score calculation | [@sre-lead] | YYYY-MM-DD | Section 11 |
| [SAA-ACT-nn] | [Action] | [@owner] | YYYY-MM-DD | [Decision or KPI] |

## 13. Review checklist and traceability

<!-- Guidance: Use the checklist before approval, and the trace table to show that each hotspot leads to a lever, a scenario and a decision. -->

### 13.1 Review checklist

- [ ] The boundary includes standby, non-production, CI/CD and observability, or states why not.
- [ ] The functional unit is the same in every scenario and in the baseline.
- [ ] Every factor has a value, a source, a date and a quality class.
- [ ] Location-based carbon intensity is used for I; no offsets or certificates reduce the score.
- [ ] Embodied emissions use the reserved time and reserved share of shared hardware.
- [ ] Every scenario shows absolute values for E x I, M and the score.
- [ ] Each accepted lever has a trade-off row signed off by the owner of the affected quality.
- [ ] Targets cover both intensity and absolute emissions, with owners and dates.
- [ ] Recalculation is scheduled and its data pipeline exists.

### 13.2 Traceability

| Hotspot | Lever | Scenario | Decision | Indicator |
|---|---|---|---|---|
| Rank 1 *(Example)* | LEV-02 | A | SAA-DEC-01 | SUS-KPI-01, SUS-KPI-03 |
| Rank 3 *(Example)* | LEV-01 | B | SAA-DEC-02 | SUS-KPI-01, SUS-KPI-02 |
| Rank 2 *(Example)* | LEV-05 | Not used | SAA-DEC-03 | Not applicable |
| [Hotspot] | [LEV-nn] | [Scenario] | [SAA-DEC-nn] | [SUS-KPI-nn] |

## 14. Glossary and references

<!-- Guidance: Define the terms readers from engineering, finance and sustainability may use differently, and list every source with the version checked. -->

### 14.1 Glossary

| Term | Meaning in this document |
|---|---|
| Carbon intensity (I) | Emissions per unit of electricity for a grid and period, location-based |
| Embodied emissions | Emissions from making, transporting and disposing of hardware |
| Functional unit (R) | The unit by which the software scales and in which the score is expressed |
| Location-based | Using the average emissions of the grid where the energy is consumed |
| Market-based | Using emissions from contracts and certificates an organisation buys |
| PUE | Power usage effectiveness: total facility energy divided by IT equipment energy |
| SCI | Software Carbon Intensity, a rate of emissions per functional unit |
| Time shifting | Running deferrable work when grid intensity is lower |

### 14.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| ISO/IEC 21031:2024, Information technology: Software Carbon Intensity (SCI) specification, iso.org and webstore.iec.ch | Edition 1, March 2024 | Formula terms; method structure only |
| Green Software Foundation, Software Carbon Intensity specification, sci.greensoftware.foundation | Version 1.1.0 web edition | Formula, terms and five-step method |
| AWS Well-Architected Framework, Sustainability pillar, docs.aws.amazon.com | Publication date 2024-11-06 | Best practice area names |
| Microsoft Azure Well-Architected Framework, Sustainable workloads on Azure, learn.microsoft.com | ms.date 2026-06-25 | Pillar relationships |
| Google Cloud Well-Architected Framework, Sustainability pillar, docs.cloud.google.com | Last updated 2026-10-13 | Principle names |
| GHG Protocol Corporate Standard and Scope 3 Standard, ghgprotocol.org | Current editions; Scope 2 revision in progress | Scope terms |
| [Grid intensity data source] | [Year] | Factor I |
| [Hardware carbon footprint sheets] | [Model and date] | Factor TE |

## Standard and licence note

Structure aligned with the Software Carbon Intensity method of ISO/IEC 21031:2024: only the formula, the names of its terms and the order of its steps are used, and no text, tables or definitions of the ISO/IEC publication are reproduced; obtain the standard for normative requirements. Based also on the openly published Green Software Foundation SCI specification (cited, not copied), on the area and principle names of the AWS Well-Architected Sustainability pillar, the Azure Well-Architected sustainable workloads guidance and the Google Cloud Well-Architected Framework sustainability pillar, and on the scope terms of the GHG Protocol. AWS, Microsoft Azure and Google Cloud and their products are trademarks of their owners; this template is not affiliated with or endorsed by them. This template is original text written for this collection; all factors and figures are illustrative examples, not benchmarks. Check the current official versions before use. Template licence: MIT.