How to Answer Carbon and Data-Center Disclosure Requests

Carbon disclosure questions have moved from rare edge cases in enterprise RFPs to standing line items in procurement templates across financial services, healthcare, manufacturing, and large technology companies. The shift is not cosmetic — buyers are under ESG reporting pressure from their own investors, and the software vendors they select become part of their Scope 3 disclosure. A B2B SaaS company that cannot provide a coherent, evidence-backed response to these questions is increasingly at risk of losing deals that have nothing to do with product capability.

What Buyers Are Actually Asking

Enterprise sustainability questionnaires tend to cluster around five categories. The first is organizational emissions: does the vendor track its own Scope 1, 2, and 3 emissions, and under what framework? The second is data-center efficiency: where are production servers located, and what is the power usage effectiveness (PUE) of those facilities? The third is renewable energy: what percentage of the electricity consumed by the vendor's infrastructure is covered by renewable energy certificates (RECs) or direct power purchase agreements (PPAs)? The fourth is carbon targets: does the vendor have a published net-zero or carbon-neutrality commitment, and what is the target year? The fifth is assurance: have the emissions data been verified by a third party, and under what standard?

Most SaaS companies are unprepared for all five categories on the first pass. The practical goal in an initial deal cycle is not to achieve comprehensive assurance — it is to demonstrate that the company understands the framework, knows where its emissions live, and can point to credible third-party evidence for the largest categories.

The CDP disclosure framework is increasingly cited as the baseline standard by large enterprise buyers. CDP (formerly Carbon Disclosure Project) operates a standardized questionnaire system and maintains a public database of corporate environmental disclosures. A buyer asking whether the vendor reports to CDP is asking a binary question; the answer at early stage is almost always no, but acknowledging the framework by name signals literacy.

Understanding Scope 1, 2, and 3 for Software Companies

The GHG Protocol Corporate Standard divides emissions into three scopes. Scope 1 covers direct emissions from sources the company owns or controls — vehicles, on-site generators, refrigerants. For a typical B2B SaaS company with no physical manufacturing, Scope 1 is either zero or negligible.

Scope 2 covers indirect emissions from purchased electricity, heat, or cooling. For SaaS companies that own their own office space and consume electricity for lighting, HVAC, and workstations, Scope 2 represents the primary owned-operations emission category. The GHG Protocol provides two Scope 2 accounting methods: the location-based method (using average grid emission factors for the regions where electricity is consumed) and the market-based method (using supplier-specific emission factors, adjusted for RECs). Most enterprise questionnaires accept either method as long as it is named.

Scope 3 is the value chain — everything upstream and downstream of the company's direct operations. For SaaS companies, the dominant Scope 3 category is cloud infrastructure: the energy consumed by cloud provider data centers running production workloads. This is where the majority of a software company's carbon footprint lives, and it is the category most difficult to quantify without a formal lifecycle assessment. Critically, it is also the category where cloud provider sustainability commitments provide the most useful proxy evidence.

The Green Software Foundation's Software Carbon Intensity (SCI) specification, which builds on the GHG Protocol, offers a structured method for calculating the carbon intensity of software products specifically. Referencing SCI in a procurement response signals a more sophisticated understanding of the space and is worth including as a forward-looking framework even if full SCI measurement has not yet been implemented.

Cloud Provider Sustainability Commitments as Vendor Evidence

The practical reality for most B2B SaaS companies is that the largest portion of their environmental footprint is controlled by their cloud provider, not by them directly. This is not a weakness in a procurement response — it is an accurate description of the structure, and enterprise buyers understand it. The key is citing provider data with specificity rather than waving at it generally.

AWS publishes an annual Sustainability page and a Customer Carbon Footprint Tool that enterprise customers can use to estimate the emissions associated with their own AWS usage. AWS has committed to powering operations with 100% renewable energy by 2025 and reaching net zero by 2040. The AWS Global Infrastructure page documents the PUE of owned data-center facilities by region, with recent figures for hyperscale AWS-owned facilities running between 1.1 and 1.2.

Microsoft Azure publishes a Sustainability page and an Emissions Impact Dashboard available to Azure customers. Microsoft has committed to being carbon negative by 2030 and removing all historical emissions by 2050. Azure data centers in Microsoft-owned facilities report PUEs in the 1.1–1.18 range, and Microsoft's 2023 Sustainability Report provides region-level detail on renewable energy coverage.

Google Cloud publishes a Sustainability page with per-region data on carbon-free energy percentage (CFE%). Google operates under a commitment to run on 24/7 carbon-free energy by 2030 and has maintained carbon neutrality since 2007 through offsets. Google's data-center PUE averages around 1.10 across its owned facilities, making it one of the most efficient large-scale infrastructure operators.

A procurement response that names the provider, cites the relevant region, references the provider's current PUE for that region, and links to the provider's published sustainability report is a materially stronger response than one that describes the company's general commitment to environmental responsibility without evidence.

Credible vs. Vague Responses

The clearest way to distinguish a credible response from a vague one is the presence of measurable data. Statements like "we are committed to reducing our environmental impact" or "sustainability is a core company value" do not answer any of the five question categories listed above. They read as filler to procurement teams who have reviewed hundreds of RFPs and can identify boilerplate immediately.

A credible response has the following structure. It opens by naming the framework used for emissions accounting (GHG Protocol, SCI, or both). It then states the Scope 1 figure (typically zero for cloud-native SaaS), the Scope 2 figure (based on office electricity consumption with methodology noted), and a Scope 3 description that acknowledges cloud infrastructure as the primary category and cites the provider's published data. It lists the data-center regions in production use. It quotes PUE for those regions from the provider's published documentation. It notes the provider's REC coverage or renewable energy commitment. It ends with a statement about the company's forward-looking plans — even a modest one, such as initiating a formal carbon measurement process in the next calendar year.

A single-page document covering these points, formatted as a vendor sustainability fact sheet, will satisfy the majority of procurement-level requests. ESG team requests will require more, but they also arrive later in the sales process and can be addressed with a supplemental package.

How ESG Teams and Procurement Teams Ask Differently

Procurement teams operate from standardized templates. The questions they ask about sustainability are typically checkbox-driven: does the vendor have an environmental policy? Has the vendor disclosed emissions under a recognized framework? Does the vendor have a named point of contact for ESG matters? Answering these questions requires the existence of basic documentation — a one-page environmental policy, a named contact, a framework citation — more than it requires a mature sustainability program.

ESG teams ask structurally different questions. They want emissions data disaggregated by Scope, not just acknowledged at a high level. They ask about the boundary of the company's emissions inventory — which entities and geographies are included. They ask about assurance methodology, meaning whether the data have been reviewed by an independent third party under ISAE 3000 or a similar assurance standard. They ask about Science Based Targets initiative (SBTi) alignment, which requires emissions reduction targets consistent with limiting global warming to 1.5°C.

Recognizing which team is driving a disclosure request in a given deal changes both the depth of the response and the timeline for preparing it. A procurement-team request can typically be answered from a vendor sustainability fact sheet developed in two weeks. An ESG-team request — particularly from a large financial services or public company buyer — may require a more extended engagement and is best flagged early to the deal team as a potential extended diligence cycle.

Understanding the difference also matters for internal prioritization. The ESG questionnaires now appearing in software procurement are increasingly driven by procurement teams working from standardized templates, not ESG specialists — which means the bar for a satisfactory initial response is lower than many vendors assume.

Building a Vendor Sustainability Fact Sheet in Two Weeks

A reusable sustainability fact sheet requires five inputs: the list of cloud regions in production use, the cloud provider's published PUE for those regions, the provider's current renewable energy certificate coverage or carbon-neutral status, a statement of the company's own office electricity consumption and any green power options in the lease or utility contract, and a one-paragraph description of the framework used.

Week one covers research and drafting. The process starts with pulling the list of production AWS, Azure, or GCP regions from the infrastructure team. The provider's sustainability page for each region is then reviewed and the relevant PUE and REC figures are documented with links to the source pages and publication dates. The company's office lease or facilities manager is contacted to determine whether the building operates on green tariff electricity or whether RECs are purchased separately. A one-page draft fact sheet is assembled from these inputs.

Week two covers legal review and distribution system setup. The legal or compliance team reviews the draft to ensure no claims exceed what the cited sources support. A storage location is established for the fact sheet in the sales response library — the same library described in building an ESG response library for sales. A version date is added to the footer, and a calendar reminder is set to review and update the document annually or when the cloud provider publishes updated sustainability data.

The completed fact sheet is then attached as a standard appendix to security and compliance questionnaire packages. It does not require a sustainability hire. It does not require a third-party audit. It requires accurate research and honest representation of what the cited sources say.

Connecting Sustainability Responses to Deal Velocity

Sustainability disclosure requests, when handled poorly, create two deal-cycle risks. The first is delay: a prospect's procurement team sends a questionnaire, the vendor has no prepared response, weeks pass while the vendor assembles an ad hoc answer, and the deal timeline slips. The second is qualification failure: the ESG team reviews the response, finds it insufficient, and flags the vendor as non-compliant with the buyer's supplier code of conduct, triggering a requirement for remediation before contract execution.

Both risks are avoidable with a prepared response library. The connection between sustainability response quality and deal velocity is the same structural relationship described in calculating deal value unlocked by accessibility conformance: a compliance-adjacent capability that, when absent, creates friction, and when present, removes a source of delay from the sales process without requiring the product to change.

The business case for building the sustainability fact sheet is not that it will win deals on its own. It is that its absence will increasingly cost deals at the qualification stage, and building it costs less than losing a single mid-market deal to an unresolved disclosure requirement.

Conclusion

Carbon and data-center disclosure requests are a structural feature of enterprise software procurement in 2026, not a niche concern driven by a minority of buyers. The good news for B2B SaaS companies is that the evidentiary foundation for a credible response is largely available from cloud provider public disclosures. AWS, Azure, and GCP have published detailed sustainability commitments, regional PUE data, and renewable energy coverage figures that can be cited directly in RFP responses. The GHG Protocol provides the framework. The CDP disclosure standard provides a reference point buyers recognize.

A vendor that understands the Scope 1/2/3 structure, knows where its emissions live (primarily in cloud infrastructure under Scope 3), and can point to provider-published data for those emissions is in a defensible position with most procurement teams. A vendor that responds with vague sustainability language and no supporting data is increasingly at risk of stalling or losing deals at the qualification stage.

The two-week fact sheet sprint described here is the minimum viable investment. It does not resolve every possible ESG diligence scenario — an ESG team at a major financial institution will require more. But it resolves the most common procurement-team requests, prevents avoidable delays, and builds a foundation that can be extended over time as the company's own emissions measurement matures.