Prepare IT customer sustainability answers for the service actually delivered
A customer asks for the annual sustainability answer for its managed application. The contract says hosting started in July, the current architecture shows two cloud regions, and a provider file contains an apparently complete six-month total. Before answering, reconstruct what actually ran and which records belong to this application.
This guide is for IT account leads, service-delivery teams and reporting reviewers. Its original fictional case tests the link between a statement of work, operational changes and supporting data. The outcome is a bounded customer answer and a precise unresolved question, not a service-footprint calculation method.
Name the delivered service and the requested claim
All organisations, identifiers, records, dates and quantities in the case are invented. Supplier Vale maintains customer Nera’s claims application, ClaimLane, during calendar 2025. Region R1 and Region R2 are fictional location labels, not actual provider regions. The evidence pack is stipulated below; it describes no Nitium engagement or real provider performance.
Nera’s question Q8 asks for the full-year greenhouse gas emissions of delivering ClaimLane, together with its hosting locations and supporting evidence. Nera includes production, recovery and application testing in that request. These are three connected questions with different available answers. A location list can be supported even when the requested emissions total cannot.
Statement of work SOW-1 assigns Vale application maintenance from 1 January through 30 June. Nera operates the servers, purchases their electricity and retains infrastructure records. Addendum A2 takes effect on 1 July and adds provider-hosted production and recovery to Vale’s deliverables. It does not say the old servers stop on that date.
Read those documents as evidence of the agreed responsibilities in this fictional arrangement. They are not energy records. Likewise, a question about the service is not answered merely by confirming that Vale has a corporate inventory. Keep the customer’s requested object, the commercial description and the actual operating history beside one another.
GHG Protocol’s Product Standard overview distinguishes a company-wide value-chain inventory from an individual product inventory. That distinction provides context here; this guide does not apply the Product Standard or determine a complete service life-cycle boundary.
Reconcile the contract date with the cutover record
Deployment log D7 records cloud production starting on 1 July in R1. Recovery record R7 starts the linked recovery database in R2 on the same date. Cutover sign-off C10 records the customer-hosted servers remaining in service through 9 July, with their retirement effective 10 July. The nine days of dual running belong in the history.
The resulting sequence is customer-managed production from 1 January to 9 July, cloud production in R1 from 1 July to 31 December, and cloud recovery in R2 for that same July–December interval. Retain both entries for 1–9 July. The addendum’s effective date and the operational retirement date answer different questions; neither overwrites the other.
Change ticket T10 introduces a testing environment on 1 October in R1. It shares project TEST-S with an unrelated application, LedgerBird. Its owner confirms that both applications use the project, but the retained report contains no breakdown between them. A current diagram shows TEST-S without showing that it existed for only three months of this service year.
For each change, retain the component, actual start and end dates, customer or provider account, region, operational record and responsible custodian. In this case D7, R7, C10 and T10 supply those links. This small history prevents an accurate December picture from becoming an inaccurate description of January.
Read a provider file at its own scope
Google Cloud’s methodology describes customer reports built from usage-based allocations. It says customer-specific data are not third-party verified or assured and may be revised when methods or inputs change. These are provider-specific statements, not a finding about the fictional file below.
Google’s export documentation identifies covered services and a selected billing account; its example retains month, project, service, region and model-version fields. Those fields illustrate why a total needs its identifiers. The case uses an invented provider format, not an actual Google export.
Vale holds fictional provider file E12, version V1, for billing account B7. Its note says the listed figures are estimated, location-based totals for the specified cloud components only. Assume the production and recovery rows use the same unit and method, have separate identifiers, and contain no overlap or missing months within their stated July–December coverage.
The dedicated project CL-PROD, linked by D7 to ClaimLane production in R1, lists July 120, August 100, September 80, October 70, November 65 and December 65 kg CO2e. The six entries sum to 500 kg CO2e. This is arithmetic on supplied fictional estimates, not an independent measurement of the application.
Dedicated project CL-REC, linked by R7 to ClaimLane recovery in R2, lists 10 kg CO2e in each of those six months: 6 × 10 = 60 kg CO2e. Together the two dedicated projects give 500 + 60 = 560 kg CO2e. Both projects must appear in the stated subtotal even though only one serves production traffic.
TEST-S lists October 80, November 70 and December 50 kg CO2e, totalling 200 kg CO2e. T10 connects ClaimLane to this shared project, but does not assign any of that quantity to it. Adding all 200 would include LedgerBird’s unspecified contribution. Omitting the project from the history would hide testing that Nera explicitly included.
The reviewer therefore preserves 200 as the shared-project estimate and leaves ClaimLane’s testing contribution undetermined. Neither an equal split between two application names nor a split by invoice value is established by this pack. Ask for an existing service-specific breakdown and its basis, or a separately scoped method decision. This guide prescribes no allocation.
Keep customer infrastructure and corporate data visible
Nera supplies an electricity schedule for its whole building covering January–June. It includes other systems and identifies no ClaimLane quantity. The pack has no suitable July record for the retained servers. Their confirmed operating dates remain part of the service history, but the schedule cannot populate a ClaimLane emissions row on the evidence supplied.
Record two separate limitations: January–June has a building record without an application breakdown; 1–9 July lacks a suitable quantity record. “Customer-managed” describes who holds and operates the infrastructure in SOW-1. It does not turn either limitation into zero, establish an exclusion from Q8 or erase Vale’s maintenance work during those months.
Vale also holds a company-wide annual inventory and office electricity schedule. Neither contains a ClaimLane assignment or an approved service-level method. Keep them as corporate evidence for corporate questions. Their presence does not establish the share attributable to this contract, and this guide does not calculate one.
E12 supplies no estimate for Vale’s maintenance activities or shared offices. Its limited coverage does not settle whether those activities belong inside the intended footprint. The method reviewer still needs to agree the study boundary with the customer.
Give the customer three explicit outcomes
Hosting-history answer: the records support customer-managed production through 9 July, cloud production in R1 and recovery in R2 from 1 July, and shared testing in R1 from 1 October. Include the dual-running interval. A statement that ClaimLane was hosted only in R1 throughout 2025 would contradict these records.
Available quantitative evidence: “The fictional provider’s V1 file reports an estimated 560 kg CO2e for ClaimLane’s dedicated production and recovery projects for July–December 2025, on its stated location-based basis. It excludes the undetermined share of TEST-S, customer-managed infrastructure and Vale’s other delivery activities. It is not the full-year emissions of delivering ClaimLane.”
Full-year service-emissions answer: unresolved. In the response file, preserve the supported hosting history and the qualified subtotal separately from Q8’s requested full result. If Nera can use that narrower information, obtain acceptance of the stated scope before placing it in the customer’s required format. Do not rename the subtotal to make it fit.
Reopen only what new evidence actually resolves
Suppose a later provider file E12 V2 replaces the December production entry of 65 with 75 kg CO2e and expressly supersedes V1. All other listed entries and coverage remain unchanged. The production sum becomes 510 and the dedicated-project subtotal becomes 570 kg CO2e. Retain V1 as superseded rather than adding V1 and V2 together.
That 10 kg change is a revision to a supplied estimate in this scenario. It establishes no operating deterioration or improvement. It also resolves none of the shared-testing, customer-infrastructure or other-delivery questions. Recheck the exact answer and its attachments; replacing one number cannot turn partial coverage into a complete service assessment.
Hand over the architecture and the unresolved link
The useful handover is a dated component map with the SOW, operational change references and exact evidence version attached to each component. In this case the next questions are concrete: what supports ClaimLane’s share of TEST-S; what suitable records exist for Nera’s server period; and what service-level boundary and method are actually required? Another corporate total will not answer them.
Have a second reader reproduce 500, 60 and 560 from V1, identify the nine dual-running days, and explain why the full-year field remains unresolved. Confirm permitted recipients before releasing architecture or account details. The labels here are fictional; actual identifiers may need a controlled evidence route that preserves the necessary scope information.
For questionnaire submission and approval decisions, use the supplier response guide. For controlled disclosure, use the confidential evidence guide. The colocation guide addresses a different problem: what facility PUE can establish about a customer electricity record.
Discuss a reporting-evidence handover with Nitium Advisory using a non-confidential outline of the service, period and unresolved record link.
Sources and limits
GHG Protocol: Product Standard overview; service scope and boundaries in chapters 6–7.
Google Cloud: methodology, reporting context; export guide, account coverage and example fields.
Sources checked 14 October 2026. This is original fictional reporting preparation, not legal advice, a prescribed allocation method, a complete footprint, certification or independent assurance. It makes no claim about actual cloud-region performance or savings from changing architecture.
Comments