Section 1
The estate is a system, not a list of categories.
Each domain in an IT estate has its own dominant driver. End-user devices are dominated by embodied carbon. Data centres by energy and cooling overhead. Cloud by utilisation and region. Software by runtime efficiency and data volume. AI by model selection and inference volume. Hardware by lifecycle and circularity. Networks by data movement patterns.
The interactions are where waste compounds. A badly designed application running on over-provisioned cloud infrastructure in a high-carbon region, accessed through devices replaced on a rigid three-year cycle, generates waste across four domains at once. Single-domain fixes miss those interactions.
Domain fluency means two things: the specific levers in each domain, and how decisions in one domain create or remove waste in another. The explorer below covers both.
The measurement question to carry through every domain
For each domain: what data do you have at Tier 1 (measured), what are you modelling at Tier 2, and what is still Tier 3 (proxy)? The data quality hierarchy from Module 3 applies here, domain by domain. If you cannot answer that question per domain, your baseline has gaps you cannot see.
Section 2
The seven domains of operational impact.
Select each domain to explore the levers, waste patterns, and metrics that matter. Different domains need different governance approaches.
End-User Services
The core insight: The footprint of end-user services is dominated by embodied impact. A laptop's manufacturing footprint (energy, materials, mining, fabrication, logistics) can outweigh its operational electricity across the entire working life. The biggest levers are lifecycle and procurement decisions, not monitor-switching campaigns.
Key waste patterns
Death by a thousand defaults. Extra devices issued by course. Peripheral sprawl: two monitors regardless of need. Docking stations accumulating in storage rooms. Laptops air-freighted because onboarding was planned at the last minute. Each decision is small. Across an estate, they add up to material footprint.
Operational Levers
- Device standards by role: accounting for power draw, repairability, and expected lifespan, not just performance
- Power management defaults enforced centrally rather than left to individuals
- Recovery and redeploy processes that are easier than ordering replacement devices
- Accessory management treating cables, chargers, and docking stations as assets with lifecycle, not consumables
- Device count governance: how many people have both laptop and desktop when one would do?
- Virtual desktop infrastructure for role-based workloads, shifting to well-utilised shared servers
- Explicit AI usage governance with model selection and inference controls
Data Centres
The core insight: Data centre footprint is concentrated and measurable. This is also where poor measurement creates credibility failures. PUE matters, but PUE alone is dangerous. A lightly loaded data centre can show respectable PUE and still be wasteful in absolute terms.
Core metrics and their meaning
Poor ↓ Good
Low ← → High
Metrics Beyond PUE
The measurement maturity chain
- PUE: Total facility power ÷ IT equipment power. Context: ~1.1 is exceptional; most enterprise facilities materially higher.
- Utilisation: Actual server load as percentage of capacity. Follow-up question to any PUE claim: what is IT utilisation and the consolidation plan?
- WUE (Water Usage Effectiveness): In water-stressed regions, non-negotiable. Links cooling approach to water dependency and resilience risk.
- CUE (Carbon Usage Effectiveness): Operational energy to carbon. Bridge metric. Moves with facility change, energy sourcing, or grid intensity.
- REF & ERF: Renewable Energy Factor and Energy Reuse Factor. Only credible with stated definitions, metering coverage, and evidence.
Cloud and Platform Operations
The core insight: Cloud is not inherently more sustainable. Hyperscalers achieve better utilisation than most enterprise data centres, but cloud sustainability is not automatic. The decisions you make about how you use cloud determine whether efficiency benefits are realised or whether waste scales faster.
The biggest waste category
Idle or over-provisioned compute. Instances running continuously with low utilisation. Resources provisioned generously and never right-sized. Non-production environments left running. Storage accumulating without retention policy. Resilience provisioned at most expensive defaults because defaults were never challenged.
The continuous control loop: Five-part discipline
Visibility and Attribution
Baselining Unit Economics
Remediation Hierarchy
Guardrails for Prevention
Verification and Institutionalisation
Region selection as a lever
Cloud providers operate in regions with substantially different grid carbon intensity. Equivalent workloads in renewable-powered regions versus fossil-heavy grids can mean a tenfold difference. For flexible workloads (no strict data residency, no sub-second latency constraint), region selection is a real, practical GreenOps lever.
Software and Data
The core insight: Software behaviour is one of the most underestimated sustainability levers. How software is designed determines computational work, data generation, retention, and unnecessary movement. These decisions compound over a service's lifetime.
The Software Carbon Intensity model
Carbon is driven by energy, which is driven by computational work, multiplied by grid carbon intensity. Reduce compute per transaction; reduce energy per transaction; reduce carbon per transaction. The SCI formula prevents the efficiency-growth trap: a service can emit more in total while improving in intensity. Governance requires understanding which direction is moving.
Dark data and data minimisation
Dark data (stored, protected, backed up, replicated, but never accessed) is common and easily remediable. It accumulates because default retention is permissive, because storage was historically cheap, and because no process questions whether data still serves a purpose. Start with data minimisation: collect only what you have clear use for, define retention at creation, treat storage growth as a performance metric.
Impactful Software Sustainability Decisions
Key considerations
- Computation required to perform the task (optimise algorithms; avoid unnecessary processing)
- Data generation, retention, and replication (dark data is one of the fastest-remediable waste categories)
- Background process frequency (is it needed at that cadence?)
- Data movement between services and regions (intentional or unconsidered architecture?)
- Telemetry and logging intensity (most organisations collect more than they actively use)
Hardware Lifecycle and Circular Economy
The core insight: Embodied carbon in hardware is substantial. For laptops, it typically represents the majority of lifetime footprint. For servers, the balance depends on utilisation and grid intensity, but embodied impact is always material. Procurement and end-of-life decisions matter as much as operational efficiency.
Avoiding trade-off traps
Common mistakes to avoid
- The extension trap: Extending asset life is often right. But if older hardware is dramatically less energy-efficient for the workload, keeping it longer increases operational energy. Decision depends on workload, utilisation, and grid intensity.
- The premature refresh trap: Refreshing early in the name of efficiency without accounting for embodied impact increases e-waste and lifecycle carbon.
- The comparison trap: A server with higher product footprint might be more efficient per unit of delivered compute if it does the same work with fewer machines. Compare on functional basis relevant to workload, not headline numbers.
The full lifecycle chain
Selection
Procurement driven by performance and price with sustainability as afterthought. Wrong approach. Include: full lifecycle footprint, repairability score, spare parts availability and support for expected lifespan, manufacturer take-back programme and evidence of actual refurbishment. Supply chain risk: rare earth minerals, conflict minerals, labour standards (Responsible Business Alliance Code of Conduct).
Deployment
When and how devices reach users. Air-freighted because onboarding was left to the last minute amplifies embodied impact. Logistics planning is a sustainability decision.
Use
Operational energy draw and utilisation. For laptops, typically smaller than embodied impact. For servers, balance depends on grid intensity and usage patterns.
Redeploy
If device is viable, move to lower-demand user tier before retirement. Requires real asset tracking and a process easier than ordering new. Otherwise intention will not survive reality.
Repair
Treat repairability as procurement requirement, not aspiration. Spare parts, repair SLAs, battery replacement, upgrade paths. If device cannot be repaired economically, refresh cycle is forced regardless of policy position.
Refurbish
Extend life through certified refurbishment. Only credible with evidence and standards compliance.
End-of-Life
ITAD is an evidence-generating process, not a disposal contract. Chain-of-custody documentation, verified treatment routes, data sanitisation certificates to recognised standards, reporting supporting audit and ESG disclosure. If you cannot trace what happened, you cannot credibly claim sustainability.
AI as a Cross-Cutting Multiplier
The core insight: AI is not a separate sustainability topic. It is a multiplier across everything else. The main risk for most organisations is not headline-grabbing training runs. It is inference demand scaling silently across hundreds or thousands of users, embedded in products, left ungoverned because it feels like productivity.
Key governance areas
- Model selection: Substantial energy difference between small, fine-tuned model and general-purpose frontier model. Right-size the model to the task. Use the smallest model that reliably achieves the outcome.
- Prompt and interaction design: Every token sent and received drives compute. Longer prompts, longer outputs, extended context windows increase inference load. Intentional use, not habitual.
- Caching and architecture: If same queries are made repeatedly, cache responses. If AI is embedded in a product, minimise unnecessary model calls. Pre-screen whether query genuinely requires inference.
- Unit economics accountability: Product owners accountable for AI unit economics: value per inference, cost per inference, guardrails preventing unnecessary model calls.
Stop-doing and start-doing lists
Stop Doing (Waste Prevention)
Start Doing (Governance)
Networks
The core insight: Networks are invisible infrastructure with frequently omitted sustainability impact. Data is hard to access; control points are indirect. That does not make them unimportant. It makes them easy to avoid. The practical answer is that egress cost and egress footprint move together.
The data movement footprint
Every API call transferring data unnecessarily. Every cross-region synchronisation serving no operational purpose. Every video stream at resolution higher than the connection will display. Every chatty microservice architecture generating constant internal traffic. These aggregate into real network energy consumption at scale.
Practical Levers for Network Sustainability
Key interventions
- Design systems that minimise unnecessary data movement (architecture discipline)
- Reduce cross-region replication to what is operationally justified, not default paranoia
- Cache at appropriate layer to avoid repeated data transfers for static or slowly changing content
- Compress payloads where bandwidth is the constraint
- Review video conferencing policies where high-resolution streaming is default regardless of context
- Monitor egress costs as signal of unintentional data movement patterns
Knowledge Check 1
End-user device footprint
Knowledge Check 2
PUE and utilisation
Knowledge Check 3
Cloud control loop
Knowledge Check 4
AI model selection
⏸ Pause & Reflect
Which domain in your estate has the most obvious governance gap? Where could your organisation pull a single lever that would move multiple metrics at once? That is where GreenOps begins.
Module 4: Key Takeaways
Procurement and lifecycle decisions matter more than switch-off campaigns. Recovery and redeploy processes must be easier than ordering new.
Good facility efficiency with low server utilisation is hidden waste. Follow PUE with the utilisation question and a consolidation plan.
Visibility, baselining, remediation, guardrails, verification. Fix waste once, then prevent recurrence with policy-as-code and platform defaults.
Compute per transaction, data retention, egress patterns, and network movement aggregate into material footprints. Data minimisation and architecture discipline pay off across domains.
Selection, deployment, use, redeploy, repair, refurbish, end-of-life. Circular economy requires governance across all seven, not just the first.
Model tiering, caching, prompt efficiency, and usage accountability prevent inference from becoming the fastest-growing ungoverned cost in the estate.
This completes Track 1: Technical Foundation. You now have the operational reality (Module 1), a clean definition of digital sustainability (Module 2), the measurement vocabulary (Module 3), and domain fluency across the estate (Module 4).
Track 2: Operations starts in Module 5 and turns from understanding to doing. Module 5 covers how reporting translates into operational practice, including the rebound effect, demand management, and the difference between efficiency gains that stick and those that get consumed by growth. Module 6 applies these ideas to software. Module 7 to AI. Module 8 to supply chain and procurement.
The foundation is set. From here, the course builds operational discipline on top of it.