Building ESG Data Infrastructure for Multiple Reporting Frameworks

← Back to Blog

Most ESG data infrastructure is built reactively - one pipeline for CDP, another for GRI, a separate spreadsheet for TCFD scenario analysis, and a new module when CSRD arrives. The result is a fragmented collection of data silos that produce inconsistent figures across frameworks, require full reconstruction each reporting cycle, and fail under audit scrutiny because no single source of truth exists.

There is a better architecture. It treats ESG data like financial data: a single structured ledger where every metric has a unique definition, a documented source, and a complete history of changes - and where framework-specific outputs are views into that ledger rather than separate systems.

This article describes the architecture principles, the components you need, and the data governance practices that make it work.

The Core Problem: Metric Proliferation Without Standardization

Consider how many different ways a large industrial company might calculate and report its energy consumption across concurrent frameworks:

• GRI 302-1 requires total energy consumption within the organization, separated into non-renewable and renewable, in joules or multiples
• SASB (for the relevant sector) may require energy intensity per unit of production, in gigajoules per tonne
• TCFD does not require energy data directly, but energy data feeds into the GHG emissions calculation that TCFD's metrics pillar requires
• CSRD ESRS E1 requires energy consumption with disaggregation by renewable versus non-renewable and by fuel type, plus the absolute energy consumption figure in terajoule
• SEC Climate Disclosure requires energy consumption indirectly, as the activity data underlying the Scope 2 emissions calculation

These are all asking for variants of the same underlying data - how much energy did the company consume, from what sources - but in different units, with different disaggregations, and with different boundary definitions. Without a structured data layer that stores the granular underlying data and derives each framework's required metric from it, your team rebuilds the same data collection exercise 4-5 times per year with different output formats.

Architecture Principle 1: Collect Activity Data, Not Metrics

The most important architectural decision is to collect raw activity data at the granular level, and calculate framework-specific metrics as derived outputs. Do not design your data collection process around GRI 302-1 or SASB energy intensity - design it around the underlying energy consumption transactions: facility by facility, fuel type by fuel type, time period by time period.

For energy: collect electricity consumption in kilowatt-hours per meter or billing period, natural gas in cubic meters per billing period, fuel oil and diesel in liters per transaction - for each physical location or organizational unit. Store these records with their source document references (utility bill number, meter ID, invoice reference).

From this granular transaction-level dataset, you can derive:

• Total energy in joules for GRI (by summing and converting units)
• Energy intensity per tonne of production for SASB (by dividing by production data from your ERP)
• Grid electricity activity data for Scope 2 GHG calculation for SEC and TCFD
• Renewable versus non-renewable split for ESRS E1 (by tagging each electricity source)

Same source data, multiple output views. This is the single-ledger principle applied to ESG data.

Architecture Principle 2: Build a Metrics Registry

A metrics registry is a structured catalog of every ESG metric your organization reports, with a standardized definition for each. For each metric, the registry should record:

• Canonical name and ID: An internal identifier used consistently across all systems
• Unit of measure: The primary unit (e.g., metric tons CO2e) and allowed conversion factors
• Calculation methodology: The formula, any emission factors used, and their source and version
• Organizational boundary: Which entities are included and which are excluded
• Data source(s): Which systems or data providers supply the underlying activity data
• Framework mappings: Which GRI, SASB, ESRS, SEC, or TCFD disclosure this metric satisfies, and any required format or unit conversions for each framework
• Responsible owner: The team or individual accountable for data quality
• Review status: Whether this metric has been internally reviewed, externally verified, or limited-assured, and when

A metrics registry with 80-100 well-defined entries covers the vast majority of ESG disclosure requirements across the major frameworks. Without this registry, different frameworks produce different numbers for the same underlying reality because they are calculated by different teams using different methodologies - which is the single most common finding in third-party assurance engagements.

Architecture Principle 3: Version Control for Calculations, Not Just Data

ESG calculations change over time. Emission factors are updated annually. Methodology improvements change how a metric is calculated. Acquisitions and divestitures change the organizational boundary. Restatements are required when material errors are discovered.

A common infrastructure failure is storing only the current version of each metric's value and calculation, without retaining the historical calculation record. This makes year-over-year comparison unreliable and makes audit support impossible - because when your assurance provider asks "how did you calculate this 2023 Scope 1 figure?" you should be able to reproduce the exact calculation with the emission factors and activity data that were current in 2023, not the 2025 versions.

Version control for ESG infrastructure means:

• Storing emission factor tables with effective date ranges, so historical calculations can be reproduced using the factors that were current at reporting time
• Maintaining calculation audit logs that record who ran the calculation, when, with which inputs, and what output was produced
• Keeping restatement records that document the before and after values, the reason for the restatement, and which prior disclosures were affected
• Locking reporting-period datasets when they are used in a filed disclosure, so the data underlying a filed report cannot be changed without a formal restatement process

Architecture Principle 4: Separation of Data Collection, Calculation, and Disclosure

In most current ESG processes, these three stages happen in the same spreadsheet workbook: data is entered in one tab, calculations happen in another, and the output is copy-pasted into the sustainability report. This architecture cannot support multi-framework disclosure, version control, or audit trails at scale.

A structured ESG data architecture separates these stages into distinct layers with defined interfaces:

Data collection layer: Structured intake forms, API connections to source systems (ERP, utility billing, HR), and a validation queue where submitted data is reviewed before being added to the calculation dataset. This layer is write-once for approved data - once a data point is approved for the reporting period, it cannot be edited without a formal correction workflow.

Calculation layer: A deterministic calculation engine that applies documented emission factors and methodology rules to the activity data, producing the metrics in your registry. The calculation is triggered on demand and produces a versioned output with a full audit log. When emission factors are updated, the engine can recalculate historical periods and flag the delta for restatement review.

Disclosure layer: Framework-specific report generators that pull from the metrics registry and format the output for each disclosure standard. This layer handles unit conversions, aggregations, and presentation formats - but does not recalculate or transform data. It is a read-only view into the calculation layer's outputs.

As we discuss in our article on choosing the right framework for your industry, the key insight is that multiple disclosure frameworks are different views into the same underlying data - not different data collection exercises. The architecture above makes that principle operational.

Data Governance: The Layer Most Teams Skip

Technical architecture without data governance is a database without a process. The governance layer that makes ESG infrastructure work includes:

• Data stewards per metric category: Named individuals (not team-level accountability) who are responsible for the accuracy of specific metrics. For GHG emissions, this might be the sustainability director. For workforce metrics, HR. For energy data, facilities management.
• A review and approval workflow: Before any data is included in a regulatory filing, it must pass through an approval chain with documented sign-offs at each stage.
• A change management process: Any change to a metric definition, calculation methodology, or organizational boundary must be approved, documented, and assessed for restatement impact before implementation.
• Access controls: Granular permissions that allow data stewards to submit data for their area but not modify data from other areas or locked prior periods.

This governance layer is not glamorous. It does not show up in a dashboard. But it is what assurance providers test when they perform limited assurance procedures, and it is what distinguishes ESG infrastructure that can support mandatory disclosure from ESG infrastructure that supports voluntary reporting.

Practical Starting Point for Teams Building Now

If your team is starting from scratch or migrating from a spreadsheet-based process, the practical sequencing is:

1. Define the metric inventory first - before building any systems, produce a complete list of every metric your organization needs to report, with its framework mapping and data source.
2. Assess current data sources - for each metric, identify where the activity data currently lives and what transformation is needed to produce the metric.
3. Build the collection layer for your highest-frequency data - GHG activity data (energy, fuel, refrigerants) for most companies, since this feeds the most regulatory frameworks.
4. Implement version control and approval workflows before your next regulated filing - even a simple workflow is better than no workflow when your assurance provider arrives.
5. Build framework-specific output templates after the data layer is stable - not before, because rebuilding output templates is cheap but rebuilding a data architecture is not.

If you want to see how Nossa Data's platform implements this architecture in practice for ESG compliance teams, request a demo and we will walk you through the data collection, calculation, and disclosure layers for your specific reporting requirements.

---

← Back to all articles