Zero to Green: A Practical Guide to ESG Through TBM

Edited by Jeff Bartelli, Content Director, TBM Council

Article Overview

Organizations are under increasing pressure to understand and report the environmental impact of their technology estate, yet many stall by treating sustainability as a net-new capability requiring separate tools and processes. In reality, most already have what they need.

Technology Business Management (TBM) provides a practical foundation for integrating sustainability into existing cost and consumption models. By extending TBM data to include energy and carbon metrics, organizations can make environmental impact visible across applications, services, and business units—without rebuilding their operating model.

This guide shows how TBM practitioners, FinOps practitioners, and technology finance leaders can take a pragmatic, stepwise approach—starting with available data, extending existing models, and using combined cost and sustainability insights to drive more efficient, accountable technology decisions.

Introduction

Technology leaders are under increasing pressure to measure and reduce the environmental impact of their technology, driven by corporate sustainability commitments such as net zero targets. While expectations have accelerated, many organizations struggle to operationalize ESG (Environmental, Social, Governance), often treating it as a siloed compliance exercise rather than an extension of existing capabilities.

Sustainability is not just an environmental imperative, it is a direct economic lever. Reducing energy consumption lowers operating costs, insulates the organization from volatile power pricing, and decreases the water demand required to cool large-scale infrastructure. Actions such as decommissioning idle assets or optimizing inefficient workloads do more than reduce carbon: they free up capacity, reduce spending, and delay the need for additional data center investment. In this context, environmental efficiency and financial efficiency are fundamentally aligned.

A common assumption is that meeting these requirements demands a new ESG platform built from scratch, creating unnecessary resistance and slowing progress. In reality, most organizations already have the foundation in place. The data used to track cost, consumption, and asset ownership can be extended to support environmental reporting without introducing parallel systems.

This article presents a pragmatic approach to integrating ESG capabilities into an existing Technology Business Management (TBM) model.  Within the TBM Framework, this guide focuses on advancing the Sustainability Value Driver by treating environmental impact as a measurable, operational outcome of technology decisions. By extending TBM models to include energy and carbon metrics, this approach enhances Transparency, generates actionable Insights, and enables Optimization alongside cost, risk, and performance.

These metrics can be incorporated into existing TBM reporting to introduce new efficiency KPIs alongside traditional financial views. This guide focuses on three core areas:

1. The Foundation: How TBM and TBM Taxonomy 5.0 enable ESG integration
2. The Implementation: How to apply proxy data to establish a working model
3. The Action Model: How to use combined cost and carbon insights to drive measurable outcomes

1. The Foundation: Leverage What You Already Own

TBM programs already map infrastructure to business value via application and business service relationships. To do that, you have collected a rigorous inventory of what technology assets you own. You know what is physical and what is virtual. You know which data center a server sits in, which dictates the carbon intensity of the power grid it relies on. Most importantly, you know who owns it and who is consuming its capacity.

In the world of carbon accounting, this is the holy trinity of data. If you have the metadata to answer what it costs and who consumes it, you effectively have the metadata to answer what it emits.

Because TBM is designed to connect resources to consumers, environmental data can “ride the rails” of your existing taxonomy and allocations. You do not need to build new allocation rules or hire external consultants to map the flow of energy. When a server is allocated to an application, and that application is charged to a business unit, the carbon footprint can follow that exact same path automatically.

This inherent capability is now officially codified and supercharged with the release of TBM Taxonomy 5.0. The updated taxonomy moves beyond basic estimates by introducing dedicated ESG Solutions (i.e. Services) and new tagging structures that seamlessly identify sustainability-supporting resources across the entire tech portfolio. Most importantly, the TBM Framework 2.0 formally elevates Sustainability to an official Organizational Value Driver.

In the TBM framework, Value Drivers represent the ultimate strategic business outcomes that technology leaders are expected to deliver. They bridge the critical gap between daily technology execution and overarching business impact. By officially categorizing Sustainability as a Value Driver, sitting right alongside Financial Performance, Risk & Compliance, and Innovation, TBM shifts carbon tracking from a passive compliance exercise into a proactive, strategic enabler.

This formal alignment allows organizations to make carbon-conscious decisions by directly attributing energy use and emissions to specific business services. It empowers practitioners to evaluate both cloud and on-premises environments for simultaneous energy and cost optimization, ultimately linking environmental impact directly to financial and operational performance. By leveraging this framework, you are no longer just managing a technology budget; you are actively optimizing the environmental footprint of the enterprise with credible, decision-ready data.  This ensures your TBM model can support Sustainability as a measurable value driver, not just a reporting exercise.

2. The Implementation: “Lighting Up” Your Existing Model

To begin activating ESG within TBM, you don’t need real-time sensors or telemetry data on every plug. Instead, you apply a “Proxy Data” strategy. This involves using industry-standard “tax tables” to convert your current inventory into your two new metrics: Energy Consumed (kWh) and Carbon Emitted (CO2)

• Energy Consumed: Kilowatt-Hours (kWh) Kilowatt-hours measure the total volume of electricity your technology pulls from the grid, acting as the foundational baseline for your operational efficiency. Just like tracking the gallons of gas a car burns, tracking kWh tells you exactly how much power is required to run your servers and keep your facilities cool. Reducing your kWh through better architecture or decommissioning idle assets can lower both your financial costs and your environmental impact.
• Carbon Emitted: Carbon Dioxide Equivalent (CO2) Carbon Dioxide Equivalent is the universal metric used to measure your actual environmental impact, translating various greenhouse gases into a single, standardized number. While your energy consumption tells you how much power you used, your CO2 reveals how “dirty” or “clean” that power was based on the local energy grid. For example, a server drawing electricity from a coal-heavy region will produce a drastically higher CO2 footprint than the exact same server running on renewable energy.

Just like budget, forecast, cost, etc., these metrics will be included in your TBM model.

The “Proxy Data” Strategy in Practice

But how do we source actual values for these new metrics? Unlike traditional financial data, we don’t have a General Ledger or Forecast file to lean on. Instead, we generate these values by enriching our existing cloud and on-premises infrastructure data with environmental attributes.

Public Cloud is the easiest win. Leverage your existing Cloud Billing Export (CUR). Most major providers now include carbon estimates and energy usage in their data. You simply use these existing columns as unit drivers for your new metrics.  The metrics can follow the same allocation flow as your existing cost allocations.

On-Premises and Private Cloud resources are a bit more challenging.  To do this, we will take advantage of a commonly used “proxy strategy”.  Think of this as a back-of-the-envelope calculation that delivers immediate visibility: Here, you use your asset list and geography as a calculator. If you know the server model and where it sits, you can generate a credible estimate for your new metrics.

Defining Your Variables

To build a credible on-prem proxy model, you must document the “why” behind your multipliers. To create the new kWh and CO2 metrics, you will need:

1. Wattage (Equipment Power Draw)

• What it is: The amount of electricity a specific piece of hardware pulls while operating.
• Why it’s helpful: This is the primary driver for your Energy Consumed (kWh) metric. You don’t need a custom value for every unique server; grouping assets by generation or class (Small/Medium/Large) and applying a manufacturer-based average is sufficient for early-stage work.
• Where to find it: Use manufacturer spec sheets (TDP – Thermal Design Power) or publicly available hardware databases. Internally, a common source for determining total consumption can be the data center power bill, which provides a macro view of energy usage to validate your bottom-up estimates.

2. PUE (Power Usage Effectiveness)

• What it means: The ratio of the total energy used by a data center facility to the energy delivered specifically to the computing equipment.

• Why it’s helpful: A PUE of 1.5 means for every 1 watt used by the server; another 0.5 watts is required for cooling, lighting, and power distribution. This ensures you are accounting for the total energy footprint, not just the hardware itself.

• Where to find it: Consult your data center or facilities team for site-specific ratings. If unavailable, document the Uptime Institute’s annual survey, which currently places the global average at approximately 1.58 as of March 2026.

• When to use it (and when to drop it): You should include PUE when calculating your organization’s total carbon footprint for corporate ESG reporting, regulatory compliance (like Scope 2 emissions), or macro-level capacity planning to evaluate the overall efficiency of your data centers. However, mature FinOps practices often drop PUE when building unit-cost or chargeback models for application owners. As the Mastercard team noted below, PUE is facility overhead that sits entirely outside of an engineering team’s control. If your immediate goal is to drive behavioral change, such as right-sizing compute or decommissioning idle assets, omitting PUE from the application allocations keeps the signal clear, ensuring business units are only held accountable for the raw energy consumption they can influence.

3. The Carbon Factor (Grid Intensity):

• What it is: The amount of carbon dioxide equivalent emitted for every kilowatt-hour of electricity produced. This varies wildly based on whether the local grid relies on coal, natural gas, or renewables.
• Why it’s helpful: This is the multiplier that converts energy usage into carbon impact. It allows you to distinguish between “clean” and “dirty” regions, helping you identify which workloads are contributing most to your environmental footprint.
• Where to find it: For US-based assets, use the EPA’s eGRID tables. For global assets, the International Energy Agency (IEA) provides the gold standard for grid intensity by country.

Example

Imagine you have a Dell PowerEdge R740 sitting in a data center in Northern Virginia. To calculate its baseline carbon footprint, you simply step through the variables:

1. Find the Wattage: A search of the Dell spec sheet shows a Thermal Design Power (TDP) of 750W. Because servers rarely run at maximum capacity 24/7, avoid relying on a generalized “50% load” rule. Instead, integrate actual utilization data from your existing DCIM (Data Center Infrastructure Management) tools to create an environment-specific hardware baseline. For example, if your DCIM telemetry indicates this hardware class operates at an average 40% load in your data center, you can accurately estimate its active draw at 300W.
2. Multiply by the Efficiency Overhead (PUE): We will use the global data center estimate of 1.58 in this case. Multiplying our 300W draw by 1.58 gives us a total facility power requirement of 474W.
   • The inclusion of PUE in your calculations is not always necessary and highly depends on the use cases you are pursuing. For more information on when and when not to use PUE in your calculations, reference the “Defining Your Variables” section above.
3. Calculate Annual kWh: Using that adjusted draw of 474W, multiply by the total hours in a standard year (8,760) and divide by 1,000 to convert to kilowatts. This shows the server consumes roughly 4,152 kWh annually.
4. Apply the Carbon Factor: Finally, multiply the annual kWh by the local grid’s intensity factor. Using the EPA’s recent national average emission rate of roughly 0.767 pounds of CO2 per kWh, we can determine that this single server is responsible for roughly 3,184 pounds (or about 1.45 metric tons) of carbon emissions per year.

Where to Find the “Hidden” Data

TBM practitioners often overlook systems that already contain the variables needed for these formulas. You likely just need access to:

• DCIM (Data Center Infrastructure Management): Systems like Sunbird or Schneider Electric. These tools often track the actual PUE of your specific data centers, allowing you to move from an average to your real efficiency.  Some tools to look in to include:
  • Schneider Electric (EcoStruxure)
  • Sunbird
  • Nlyte
  • Vertiv
  • ABB
  • Modius
• CMDB (Configuration Management Database): Beyond just the “status” of a hardware asset, the CMDB often contains the CPU type and Core Count, allowing for much more granular wattage estimates.  Your TBM program should already be pulling in data from a CMDB, but if you do not, look to see if your company is using:
  • ServiceNow
  • BMC
  • Device42

The “Fleet-Wide” Approximation Strategy

When you look at your CMDB, the sheer diversity of hardware can be daunting. However, you don’t need a custom coefficient for 50 different server models to get started.

Categorize by Generation

Group your hardware into “Small/Medium/Large” buckets or by generation (e.g., Gen9 vs. Gen10). Apply a single wattage proxy to each bucket. In the early stages of sustainability maturity, the delta between a coal-heavy grid and a hydro-powered grid is far more impactful than the 10-watt difference between two similar server models. Directional accuracy allows you to identify the “big rocks” immediately.

The Maturity Path: Transitioning from Proxies to Telemetry

While the proxy strategy is the most effective way to establish an immediate baseline, it is not the end state of a mature ESG practice. As your TBM capabilities scale, your reliance on estimates and standard coefficients should systematically decrease. The goal is to transition from static proxies to dynamic, real-time telemetry, ensuring your environmental metrics are as precise as your financial data.

Organizations should view this transition across three distinct maturity phases:

1. Phase 1: The Proxy Baseline (Crawl) At this stage, the focus is on directional accuracy. You rely on standard manufacturer spec sheets, global PUE averages, and generalized cloud provider data. You might use macro-level inputs, like a facility power bill, to validate your bottom-up estimates. This phase proves the value of the model without requiring new software investments.
2. Phase 2: Enriched Integration (Walk) Here, you replace generic estimates with environment-specific data. You integrate your TBM reporting engine with DCIM tools (like Sunbird or EcoStruxure) to capture your actual, site-specific PUE. Simultaneously, you leverage your CMDB (like ServiceNow or Device42) to pull accurate, asset-specific CPU core counts and hardware generations, allowing for highly tailored wattage estimates based on your exact fleet composition.
3. Phase 3: Real-Time Telemetry (Run) In the final mature state, manual estimates are entirely replaced by automated, API-driven telemetry. For cloud environments, standard vendor exports are augmented or replaced by specialized sustainability tools, like Greenpixie, that deliver highly granular, region-specific emissions data.  For on-premises environments, organizations deploy tools like BMC Discovery to push dynamic, real-time power consumption and utilization metrics directly into the CMDB, flowing seamlessly into the TBM model.

By mapping out this telemetry maturity path, TBM leaders can immediately deliver value with proxies today, while building the business case for the specialized tooling required for tomorrow.

Mapping the “Carbon Rails”

Once you have these estimates, you treat them exactly like your financial data. You are essentially adding a second and third “ledger” to your TBM model.

1. 1. Inject at the Source: Drive your estimated kWh and CO2 into the infrastructure layer of your model (the “Infrastructure Services” or “Technology Resource Towers” level).
   2. Follow the Currency: Ensure these metrics are assigned to the same Allocation Keys as your dollars. If a server’s cost is allocated based on CPU utilization or a flat monthly fee, its carbon and energy should be allocated the same way.

• The Result: Because the “road” is already built, these metrics will automatically flow up through your applications and services to the end-user. You aren’t just reporting on “Data Center Carbon”; you are reporting on “The Carbon Footprint of the Global Payroll App.”

At this stage, Sustainability becomes operational, embedded into the same data structures and allocation logic used to manage cost.

3. The Action Model: Reporting and Tangible Wins

The ultimate purpose of this data is to shift from static reporting to active remediation. By centralizing carbon, energy, and cost into a single view, TBM provides a “Value Lens” that allows the organization to optimize for the planet and the P&L simultaneously.

The Integrated Dashboard: Cost, Carbon, and Energy

A mature TBM-led ESG report doesn’t just show total emissions; it shows efficiency. In your monthly reviews, you should move away from isolated financial reports and toward an integrated view that presents three metrics for every service, application, or business unit:

1. Financial Cost ($): The traditional TBM view of spend and depreciation.
2. Energy Consumed (kWh): The operational footprint of the technology.
3. Carbon Emitted (CO2 tons): The environmental impact based on the specific power grid used.

The Jumpstart KPI Library

TBM practitioners can immediately add these two metrics to their existing dashboards to begin the conversation:

1. Carbon Intensity of Spend

• The Formula: Total CO2 Emissions divided by Total Technology Spend.
• Why it’s helpful: This metric provides a crucial unit economic view of your sustainability efforts by answering the macro question of how much carbon debt every dollar of budget is buying. If your technology spend increases due to business expansion, but this ratio trends downward, it proves your architecture is becoming inherently more efficient and successfully decoupling growth from environmental impact. Conversely, an upward trend acts as an early operational alarm indicating that your emissions are growing faster than your investments. This spike typically highlights unmanaged infrastructure sprawl, the aggressive scaling of inefficient legacy systems, or a shift of workloads to carbon heavy geographic regions. When this warning sign flashes, it creates an immediate business case to pause and review your architectural and sourcing strategies before the technical debt becomes an environmental liability.

2. Waste-to-Carbon Ratio

• The Formula: Estimated CO2 from flagged “Zombie” or underutilized assets divided by Total Technology CO2 Emissions.
• Why it’s helpful: This is your most powerful operational lever because it quantifies the environmental cost of sheer neglect. It translates an abstract corporate sustainability goal into an immediate engineering target. By showing stakeholders exactly what percentage of their total carbon footprint comes from infrastructure providing zero business value, you create a compelling, dual-incentive business case to decommission those assets and instantly reduce both cost and emissions.

The “Cost = Carbon” Efficiency Flywheel

In the TBM world, “waste” is a primary target. Every orphaned database, underutilized server, or over-provisioned instance is a dual failure.

By adding carbon and energy columns to your existing infrastructure hygiene reports, you provide a double incentive for remediation. When you show a stakeholder that decommissioning an idle cluster saves $10,000, 5,000 kWh, and 5 tons of CO2, you turn a routine housekeeping task into a high-visibility sustainability win. This “Efficiency Flywheel” ensures that sustainability isn’t an extra cost; it is a byproduct of running a tight, well-managed technology shop.  This is where Sustainability moves from visibility to optimization, enabling measurable progress against environmental goals through everyday technology decisions.

Conclusion & Recommendations

The journey to sustainable technology does not require an entirely new ecosystem of tools or perfect telemetry from day one; instead, the most pragmatic path forward relies on the operational discipline your Technology Business Management practice has already established. By treating carbon and energy as new currencies within your existing taxonomy, sustainability transitions from a siloed compliance exercise into an actionable, daily engineering metric. As the insights from Mastercard demonstrate, even “directionally correct” proxy data is powerful enough to drive immediate behavioral change. When business leaders and application owners can see the environmental cost of their infrastructure alongside the financial cost, the conversation naturally shifts—proving the goal of a modern technology portfolio is no longer just finding the cheapest way to operate, but finding the optimal intersection of cost, performance, and planetary impact.

Recommended Next Steps for TBM Practitioners & Leaders: To jumpstart this capability within your own organization, we recommend the following immediate actions:

• Start with the Data You Have: Do not wait for perfect sensor data to begin your modeling. Leverage your cloud billing exports (CUR) and basic on-premises proxy data, like your facility power bill and manufacturer spec sheets, to establish a baseline.
• Enrich, Don’t Rebuild: Map your estimated kWh and CO2 directly into your existing infrastructure layer. Allow these new metrics to “ride the rails” of your current allocation models to reach the consuming business units without adding administrative overhead.
• Leverage Taxonomy 5.0: Take advantage of the new ESG Solutions and tagging structures to formally categorize and track green technology investments alongside your traditional financial portfolios.
• Activate the Efficiency Flywheel: Add the Carbon Intensity of Spend and Waste-to-Carbon Ratio to your standard infrastructure hygiene dashboards. Use these metrics to create compelling, dual-incentive business cases for decommissioning zombie assets and right-sizing underutilized infrastructure.

By embedding environmental metrics into the core of your technology financial management, you empower your organization to make decisions that are both fiscally responsible and environmentally sound. Ultimately, bridging this gap ensures that every technology investment is definitively proven to be both valuable and greener.