The First Step to ESG Compliance Is Trusted Data Infrastructure
Disputes over ESG reporting rarely concern the conclusion. They concern the numbers underneath it. This article explains why buying a reporting platform first usually fails to solve the problem, and what an auditable data chain — starting from metering and testing — actually looks like.
The problem is not the report — it is everything before the report
When a customer questionnaire or a disclosure requirement arrives, the common first move is to procure a reporting or carbon-management platform. Deployment is fast. Then, during first data entry, it becomes clear that energy figures sit in three places (facilities, finance, equipment ledger) and do not reconcile; material usage exists only as spend, not weight; test data lives in local files on instrument PCs and nobody can show it was not altered.
This kind of project gets stuck at the same point almost every time — the data was already untrustworthy before it reached the system. A reporting platform can amplify data quality. It cannot manufacture it.
What "trusted" means: four questions a reviewer will actually ask
Unpacked, "trusted data" is a set of checkable properties. A reviewer rarely challenges a number directly. They follow four lines of questioning, and any unanswered line downgrades that number.
| Dimension | What the reviewer asks | What it requires |
|---|---|---|
| Provenance | Which device or system produced this number? | Device or system ID, collection method, whether hand-transcribed |
| Timing | When was it measured, and which period does it represent? | Timestamp, sampling interval, period-attribution rule |
| Status | Was the instrument in valid calibration and control at the time? | Calibration records, intermediate checks, control-sample results |
| Change control | Was the value modified? By whom? | Version records, modification trail, review and approval |
Of these four, "status" is the easiest to overlook and the hardest to reconstruct. An instrument can be accurate, but if it was outside its calibration validity or its control sample was out of limits, that data set is not acceptable in an audit sense — and that can only be proven by process records, never added at the reporting stage.
Three layers of ESG data infrastructure, starting at the instrument
In practice the infrastructure splits into three layers. All three must hold for the reporting above to stand. Any missing layer will surface during audit or customer due diligence.
Layer 1: metering and testing — where the data is born
The job of this layer is to let data carry identity from birth: device ID, measurement time, method parameters, calibration and control status, operator. Most modern instruments can do this, but the default configuration prints only the result and discards the context.
Three things worth doing first: confirm the instrument software exports reviewable raw records rather than summary values only; associate calibration and control results with the measurement record; and establish a unique-identifier rule for devices and data so the same instrument does not appear under several names across spreadsheets.
Layer 2: collection and governance — gathering it and aligning definitions
This layer brings instrument data, energy metering, production systems (MES/ERP) and purchase records together, and resolves three classes of conflict: units, definitions (for example including versus excluding packaging), and time periods.
Do not attempt full integration first. Pick five to ten key data flows by the criterion "large effect on the reported result, and the customer will ask about it", get the definitions written down and signed off by the departments involved. That is worth more than a hundred unused interfaces.
Layer 3: reporting and audit support — making conclusions reproducible
This layer turns data into conclusions while ensuring conclusions can be recalculated. The requirements: every summary value in the report drills down to a raw record; every issue is versioned; and changes in definitions between years are explained.
Audit-ready does not mean passing one audit. It means being able to produce a complete evidence chain at any time. That is why this layer should be designed for "someone will come and check this", not "I need to submit a form".
A 90-day starting checklist
If no system exists yet, run a minimal viable loop in 90 days rather than waiting for budget and software.
- Weeks 1–2: list the specific metrics required by customers and regulators, with each definition and boundary confirmed.
- Weeks 3–4: find the existing source for each metric and label it as metered, system-recorded, evidenced or estimated.
- Weeks 5–6: define the device and system list for the key metrics, and check export capability, calibration status and control records.
- Weeks 7–8: connect three to five key data flows, unifying units and reporting periods.
- Weeks 9–10: run an internal mock audit — someone who did not supply the data traces three data points the way an auditor would.
- Weeks 11–12: close gaps, produce the data dictionary and retention rules, then discuss systemisation and automation.
Common pitfalls
The same failure patterns recur across plants of very different sizes:
- Buying the system before the data: most of the project then goes into cleaning historical data, and the timeline stretches indefinitely.
- Treating scanned test reports as data: images cannot be calculated, versioned or aggregated.
- Reporting only entity-level totals without product or batch detail: when a customer asks for supplier-level or product-level figures, the work starts from zero.
- Writing "estimated" against a data gap and moving on: state the estimation method, assumptions and effect, or the item is treated as incomplete in review.
Frequently Asked Questions
We are a small plant. Do we need a data infrastructure?
What is usually required first is not a full platform but one self-evidencing data chain. Starting with the two or three metrics customers ask about most often costs little and delivers more than a one-off platform purchase.
How does ESG data relate to a laboratory quality management system?
They overlap heavily. Both rest on traceability, reproducibility and change control. A laboratory already operating ISO/IEC 17025 or an equivalent system usually has most of the data-integrity and calibration-record foundation in place and can reuse it rather than rebuild it.
Is blockchain notarisation necessary?
No. Notarisation addresses tamper evidence and trusted time — an enhancement. Source, definition, calibration status and change records are the baseline. Without those four, notarisation adds limited value.
How long should ESG data be retained?
Follow the customer contract and applicable regulation. Where neither specifies, retain at least one full audit cycle including raw records, not just the summary tables.
Working on a carbon footprint or ESG data project?
Tell us the product, the boundary the customer requires and the data you already hold. An engineer will review the method fit and confirm what is available in writing.
Ask an Engineer