What Is an Evidence Vault and Why Your Sustainability Assurer Now Demands One?

The spreadsheet problem

Spreadsheets are remarkable tools. They are flexible, fast to build, and familiar to every finance team. For the first generation of sustainability reporting — when the goal was simply to produce a number and publish it — they were adequate. But as sustainability reporting matures into a regime that demands independent assurance, the structural limitations of spreadsheets become critical weaknesses.

A spreadsheet has no tamper-evidence. Anyone with edit access can change a cell, close the file, and there is no record of the change. Version history in Google Sheets or SharePoint captures file saves, not individual cell changes — and certainly does not link those changes to source documents. When a senior leader asks for the number to be "slightly adjusted" to hit a round figure, or when a data entry error is corrected without documentation, the spreadsheet absorbs the change silently.

A spreadsheet also has no audit trail in the sense that an assurer needs it. It cannot answer the question "who entered this figure, when, based on what source document, using which emission factor version?" It can only answer "what is the current value of this cell." The difference between those two questions is the difference between a report that can be assured and one that cannot.

The problem compounds over time. A sustainability report builds on years of comparative data. If your FY2024 baseline figure was entered incorrectly in a spreadsheet and subsequently corrected without documentation, your FY2026 assurer cannot verify the historical chain. They are looking at current numbers without visibility into how they were derived or whether they were changed.

What an evidence vault is

An evidence vault is a tamper-proof, chronologically ordered repository of every piece of data that feeds into a sustainability report. Three properties define a true evidence vault:

Append-only. Entries in a vault cannot be edited or deleted. This is a fundamental design principle, not a permission setting. If an error is discovered — a bill was entered with the wrong kWh figure, or the wrong emission factor version was applied — the correction is made by adding a new entry that explicitly references the original and reverses or supersedes it. The original entry remains in the record, permanently. Every state the data has ever been in is preserved. An assurer can see not just the current figure but the complete history of every change.

Hash-chained. Each entry in the vault contains a cryptographic hash of the previous entry. This means the integrity of each record depends on every record that preceded it. If anyone attempts to alter a historical entry — to change the kWh figure, to substitute a different source document, to backdate an approval — the hash of that entry becomes invalid, which invalidates the hash of every subsequent entry. The tampering is immediately detectable without comparing against an external backup. The mathematical integrity of the chain is self-proving.

Source-linked. Every emission entry in the vault traces to its source document. Not a reference number. The actual document — the electricity bill from Singapore Power, the diesel invoice from your fuel supplier, the travel management system export for Q3 flights. The source document is captured at the time of entry and stored immutably alongside the record. This means an assurer can follow the chain from the final tCO2e figure in your sustainability report all the way back to the original bill, in a single unbroken, verifiable sequence.

Why assurers now require it

When Singapore's listed companies face mandatory limited assurance for Scope 1 and 2 emissions from FY2029 under the SGX climate disclosure rules aligned to IFRS S2, their assurers — typically the same Big Four or mid-tier audit firms that audit financial statements — will need to evaluate four things:

First, completeness: are all material emission sources included in the reported figure? Second, accuracy: are the emission factors applied correctly and from approved sources? Third, consistency: is the methodology applied consistently across reporting periods? Fourth,controls: are there controls that prevent unauthorised modification of data between source and report?

A hash-chained evidence vault directly addresses all four. Completeness can be evaluated by reviewing whether all expected source document types are represented in the vault. Accuracy can be verified by checking that each entry's emission factor version matches the stated methodology. Consistency can be confirmed by comparing methodology records across periods. Controls are demonstrated by the cryptographic integrity of the chain itself.

A spreadsheet fails all four. It cannot demonstrate completeness (there is no systematic record of what was included). It cannot confirm emission factor versions were applied correctly (formulas can be overridden). It cannot verify consistency across periods (there is no linked historical record). And it has no controls — anyone with edit access can change anything, at any time, without a trace.

This is why assurers are beginning to make implementation of proper data management infrastructure a prerequisite for providing assurance, rather than simply a recommendation. An assurer who cannot verify the chain of evidence cannot issue an unqualified opinion. A qualified opinion — or a failure to obtain assurance at all — is a material disclosure risk for SGX-listed companies.

The difference between a vault and a document management system

When sustainability teams hear "evidence vault," a common first reaction is: "We already store our bills in SharePoint. Is that not the same thing?" It is not, and the distinction matters.

A document management system like SharePoint, Dropbox, or Google Drive is a file storage system. It stores documents. It does not link those documents to specific emission entries. It does not record the emission factor version applied to each document's data. It does not capture a human approval record for each entry. It does not create a cryptographically secured chain between entries. And crucially, it does not prevent authorised users from replacing documents with different versions without an audit trail.

An evidence vault is a data management system built around the emission entry as the fundamental unit of record. When a sustainability data manager processes an electricity bill, the vault records: the entry timestamp, the user who created it, the source document (the bill itself, captured immutably), the kWh figure extracted, the emission factor version applied (e.g., Singapore Power 2025 grid emission factor), the resulting tCO2e calculation, the GHG Protocol scope and category assigned, and the human reviewer who approved the entry. All of this is cryptographically chained to the previous entry. The source document cannot be substituted. The calculation cannot be silently altered. The approval record cannot be removed.

The practical test: if your sustainability data manager left tomorrow, could your assurer reconstruct the complete chain from every bill in your FY2029 report back to the original source documents, with a clear record of every decision made along the way? In a vault, yes. In SharePoint plus Excel, almost certainly not.

How hash chaining works — in plain English

Hash chaining sounds technical. The concept is actually straightforward, and understanding it helps you explain to your board why this infrastructure matters.

A hash function takes any input — a document, a number, a text string — and produces a fixed-length output called a hash or digest. SHA-256, for example, always produces a 64-character string regardless of whether the input is three words or three thousand pages. The same input always produces the same hash. Any change to the input — even a single character — produces a completely different hash. This property makes hashes useful as fingerprints: you can verify that a document has not been altered by checking that its current hash matches the hash recorded when it was first captured.

Hash chaining takes this one step further. When an emission entry is created, the system computes a hash of that entry's data. That hash is stored as part of the entry record. The next entry's data includes the previous entry's hash — so the next entry's hash is a fingerprint of both its own data and everything that came before it. And so on, forward through time.

The result: if anyone attempts to alter a historical entry — to change a kWh figure, substitute a different bill, or backdate an approval — the hash of the altered entry changes. That changed hash propagates: the next entry, which included the original hash, now has an inconsistency. Every entry from that point forward is invalidated. There is no way to alter history without breaking the chain — and a broken chain is immediately visible to anyone who verifies it.

For sustainability reporting, this means your assurer can verify the integrity of the entire history of emission entries programmatically. They do not need to compare against a backup or rely on access logs. The chain either holds or it does not.

What this means for IFRS S2 FY2029 assurance

IFRS S2 requires that climate-related financial disclosures — which include greenhouse gas emissions — be prepared with the same rigour as financial statements. For SGX-listed companies, the mandatory limited assurance requirement from FY2029 means that by the time your FY2029 assurance engagement begins (likely in mid-2030), your assurer will expect infrastructure comparable to what your finance team uses for financial statement preparation.

Limited assurance requires the assurer to conclude that nothing has come to their attention that would indicate the figures are materially misstated. To reach that conclusion, they need to follow the chain from the tCO2e in the report back to the source. In a hash-chained vault, that chain is explicit, verifiable, and complete. The assurance engagement becomes a structured verification process. Without the chain, the assurer is performing forensic archaeology — and they may not be able to reach a conclusion at all.

The practical implication: assurance engagements for companies with proper evidence infrastructure will be faster, cleaner, and less expensive than for companies without it. The Big Four have begun pricing this distinction into their sustainability assurance proposals. Companies that have invested in evidence infrastructure get lower assurance fees and cleaner opinions.

Building your vault now: why earlier is better

Every year of clean, hash-chained sustainability evidence is a compounding asset. When your FY2029 assurance engagement begins, an assurer who can review five years of methodologically consistent, cryptographically secured evidence has a fundamentally different experience than one who is handed a folder of Excel files and asked to reconstruct the chain manually.

Singapore companies that begin building evidence infrastructure in 2026 or 2027 arrive at FY2029 with three to four years of clean historical data. Companies that wait until 2028 face two problems: they need to reconstruct historical evidence retrospectively (difficult, often impossible to do with genuine integrity), and their assurers must price in the additional risk and effort.

The infrastructure also benefits non-assurance use cases. When your supplier customers ask for your Scope 1 and 2 data, the vault gives you a defensible, verifiable figure rather than a spreadsheet number. When your banks ask for sustainability metrics as part of a green loan covenant review, the vault provides the methodology and source documentation they need to assess your compliance. When your board's risk committee asks whether your sustainability figures are reliable, you can show them the chain.

The evidence vault is not a compliance overhead. It is the infrastructure that makes your sustainability data credible — to assurers, to customers, to financiers, and to your own governance processes.