AASB S2 Climate Disclosure: A Guide for Tech & Cloud Teams

Australia's new mandatory climate-related financial disclosure regime is no longer a finance-team-only concern. For technology companies running significant cloud infrastructure, AASB S2 pulls engineering and platform teams directly into the reporting process — because cloud compute, storage, and networking now count as measurable emissions sources that need to be tracked, estimated, and disclosed.

What is AASB S2 and who does it apply to?

AASB S2 is the climate-related financial disclosure standard issued by the Australian Accounting Standards Board as part of the Australian Sustainability Reporting Standards (ASRS), based closely on the International Sustainability Standards Board's IFRS S2. It requires in-scope entities to disclose climate-related risks, opportunities, governance processes, and greenhouse gas emissions in their annual reporting.

The regime is being phased in across groups of reporting entities based on size and other thresholds set out in amendments to the Corporations Act, with larger entities required to report first and smaller in-scope entities following in later years. If your company isn't currently captured, it's worth checking again as the phase-in progresses, or if you sit in a supply chain of a company that is — large reporters will increasingly ask suppliers and vendors for emissions data to satisfy their own Scope 3 disclosures.

Why does this reach into engineering and infrastructure teams?

Climate disclosure obligations extend beyond the finance function because a material share of many tech companies' emissions footprint sits inside cloud infrastructure — compute, storage, data transfer, and the data centres that host them. Engineering and platform teams are usually the only people with visibility into actual usage patterns, making them essential contributors to accurate reporting rather than passive data sources.

In practice, this means someone in infrastructure or platform engineering needs to be able to answer questions like: which cloud regions and services generate the most usage, how has consumption trended over the reporting period, and what assumptions sit behind any emissions estimate pulled from a cloud provider's dashboard. Finance and sustainability teams typically cannot answer these questions without engineering input.

Scope 1, 2, and 3 emissions: what cloud computing counts as

Under the GHG Protocol — the methodology framework that AASB S2 disclosures are built on — emissions are grouped into three scopes. Scope 1 is direct emissions from sources a company owns or controls (company vehicles, on-site generators). Scope 2 is indirect emissions from purchased electricity, heating, or cooling. Scope 3 is all other indirect emissions across the value chain, including purchased goods and services.

For most Australian tech companies, cloud computing emissions fall under Scope 3 (purchased cloud services) unless you operate your own data centres, in which case the electricity consumption may be reportable under Scope 2. This distinction matters because Scope 3 reporting generally relies on estimates and provider-supplied data rather than metered consumption, which introduces more uncertainty into the numbers you disclose.

How do you measure cloud carbon emissions in practice?

Measuring cloud emissions in practice means combining provider-supplied carbon tools with your own usage and billing data, because no single dashboard gives a complete, audit-ready picture on its own. The major cloud providers each offer some form of carbon reporting, but they differ in methodology, granularity, and export capability.

A common approach is to start with the provider's native tool for a baseline estimate, then cross-reference it against billing and resource-tagging data to validate which teams, products, or environments are driving the bulk of usage. This is also where cost and carbon tend to correlate — infrastructure that is expensive to run is often carbon-intensive too, so existing application-modernisation and cost-optimisation work can double as emissions reduction work.

Provider tool	Reporting granularity	Methodology notes
AWS Customer Carbon Footprint Tool	Account and service level	Location-based and market-based estimates; limited real-time detail
Microsoft Sustainability Manager / Emissions Impact Dashboard	Subscription and resource level	Integrates with broader sustainability data management
Google Cloud Carbon Footprint	Project and service level	Reports gross emissions; location-based by default

These tools are a reasonable starting point, but none of them are a substitute for understanding your own architecture. A workload spread across regions, idle resources left running, and data transfer patterns all affect the final number in ways a dashboard alone won't explain.

Treat emissions reporting as a data infrastructure problem, not just a compliance task

Accurate, defensible climate disclosure depends on the same fundamentals as any other reporting workload: clean source data, consistent tagging, repeatable pipelines, and a clear audit trail. Treating emissions reporting as a one-off spreadsheet exercise tends to break down the moment auditors or the board ask how a number was derived.

Companies with mature data-infrastructure are generally better placed here, because cloud billing exports, resource tags, and usage logs can be pulled into the same pipelines already used for product and cost analytics. If your cloud estate lacks consistent tagging by team, product, or environment, that's usually the first gap to close — without it, emissions attribution becomes a manual, error-prone exercise every reporting period.

Common challenges for Australian tech companies

The most common challenge is that emissions data lives in multiple disconnected systems — cloud billing, infrastructure-as-code, finance records — with no single owner responsible for reconciling them. A second common issue is that Scope 3 estimates from cloud providers use different underlying methodologies, making it hard to produce a single, defensible number if your infrastructure spans more than one provider.

Teams that have recently gone through legacy application-modernisation or infrastructure consolidation often find this easier, simply because there are fewer systems to reconcile and more consistent tagging already in place. Conversely, companies running a patchwork of legacy and modern infrastructure across multiple providers typically need more manual work to produce a usable baseline.

Where to start: practical steps

Start by confirming whether your company falls into a current or upcoming reporting group under the AASB S2 phase-in, and loop in your finance or sustainability lead early rather than waiting for a formal request. From there, engineering teams can usually make the most immediate progress by auditing resource tagging, consolidating billing exports, and documenting which cloud services and regions represent the bulk of usage.

It's also worth treating this as an ongoing capability rather than an annual scramble. Climate disclosure, like financial reporting, benefits from pipelines that run continuously rather than a manual pull together each reporting period. If you're also exploring how AI or automation can reduce the manual effort in pulling this data together, our ai-engineering team has seen similar patterns in other compliance and reporting workloads.

Frequently asked questions

Does AASB S2 apply to small or early-stage tech companies? Not immediately in most cases — the regime is being phased in by size and other thresholds, with larger entities reporting first. Smaller companies in a large company's supply chain may still be asked for emissions data informally before they're formally in scope.

Is cloud computing a material emissions source for software companies? It can be, particularly for companies with significant compute, storage, or data processing workloads. Whether it's material enough to warrant detailed disclosure depends on your overall emissions profile compared with other value-chain sources.

Can we rely solely on our cloud provider's carbon dashboard? It's a reasonable starting point but generally not sufficient on its own for audit-ready disclosure, since providers use different methodologies and the tools don't always capture your full architecture or usage context.

For more on building reliable reporting and data foundations, have a browse of our insights.

If you're assessing what AASB S2 means for your engineering and infrastructure teams, or need help turning cloud billing and usage data into a defensible reporting pipeline, get in touch — we can help you work out what's genuinely in scope and what a practical first step looks like.