Audit Trail and Data History

The audit trail is the assurance layer of the platform. Every raw data entry, every indicator action, every edit, deletion, and calculation gets logged with attribution and timestamp. This guide explains what's tracked, how to use it for assurance, and how to use it day-to-day for data quality.

What gets logged

The platform tracks every action across two domains:

• Indicator entries. Additions, edits, deletions, calculations (when raw data feeds an indicator), and direct manual entries (when a value is entered directly via the Calculated Metrics flow).
• Raw data entries. Additions, edits, deletions of operational data points.

Every entry in either log captures:

• The action type (add, edit, delete, calculate).
• Who performed the action.
• When the action happened.
• The site the entry applies to.
• Any attached files or notes.

This is what assurance providers ask for first. ISAE 3000 and ISAE 3410 expect a clear inventory management plan with version-controlled calculations, source documentation, and evidence of internal reviews. The audit trail is that evidence.

Where to find it

Open Audit in the left sidebar. The Audit tab has two main sections:

• Indicator Entries Audit — every indicator action across the workspace.
• Raw Data Entries Audit — every raw data action.

Both sections render as filterable, exportable tables. Click any row for a deeper view of that specific action.

Indicator Entries Audit

Each row shows:

• The indicator name (e.g., Total GHG Emissions, Ratio of Capital Spend to Revenue).
• The action type — was the entry an edit, a deletion, or a new calculation triggered by raw data feeding the indicator.
• Notes attached to the entry.
• Files attached as supporting documentation.
• The timestamp of when the entry was logged.
• The user who logged it.
• The site the entry applies to.

Raw Data Entries Audit

Same shape, applied to the raw data layer:

• The raw data type (e.g., Grid Electricity, Diesel — Stationary Combustion).
• The action, notes, files, timestamp, user, and site.

Both audit logs work the same way — same filters, same exports, same drill-in.

Drilling into an entry

Click any row in either audit section to open the full detail view. From there you can see:

• The exact value before and after the change (for edits).
• The full notes text.
• Every supporting document attached to the entry.
• The factor and methodology used (for emissions-linked entries).
• The full chain of changes if the entry has been edited multiple times.

This is the level of detail an assurance reviewer wants when challenging a specific number.

Exporting for assurance

The audit table is exportable. The most common use case: when generating a report for a specific period, export the audit report for the same period so the auditor can compare the report outputs against the underlying data history.

A typical assurance hand-off:

1. Generate the GRI or IFRS report for the reporting period (see Generate your first GRI report / Generate your first IFRS report).
2. Export the audit log filtered to the same period.
3. Send both to the assurance provider.

The auditor can then trace any number in the report back through the audit log to the underlying data entry, the user who logged it, and the supporting documentation attached.

Best practice: attach files and notes as you log

The audit trail is only as useful as the evidence captured at log time. As a habit:

• Attach the source document. Electricity bill PDF for an electricity data point. Fuel receipt for a fuel entry. Supplier statement for a Scope 3 figure.
• Add notes when files aren't available. Capture the source, the methodology, any allocation choices (e.g., "Q2 electricity bill split 60/40 across two sites by floor area"), or any caveats.
• Be specific in notes. "From [supplier name] monthly invoice, dated [date]" beats "supplier provided."

Files and notes attach to the entry at log time via the Audit Information section on the Log Data page (see Log your first data point). Once attached, they appear in the audit log and are exported with it.

Using the audit log for data quality

Beyond external assurance, the audit log is your day-to-day data quality tool:

• Identify errors quickly. When a number on the dashboard looks wrong, open the audit log and trace it back. Who entered it, when, with what supporting documentation. Most data quality issues become obvious at this view.
• Fix issues without losing history. Delete an incorrect data point and the deletion is logged — the history of "this value existed and was removed by [user] on [date]" is preserved. Re-enter the correct value and that's logged too.
• Spot patterns. Frequent edits to the same data type often indicate a process problem (unclear allocation method, ambiguous data source) rather than a one-off error.
• Internal audit. Periodic review of the audit log catches problems before they reach assurance — much cheaper to fix.

Informal data history: the drill-down view

In addition to the formal audit log, you can view historical data informally from the deep-dive page for any raw data point or indicator. Click into a raw data type from the Raw Data page, or into an indicator from the KPIs page, and the drill-down panel includes an entries table showing past entries grouped by reporting period (monthly, quarterly, or annual depending on the data type's default frequency).

This is the lighter-weight view — useful for "what did we report for Q2?" without going through the full audit log. The drill-down doesn't show edit/delete history (it shows current state); the audit log does.

What the audit log enables

Three audiences, one source:

• Third-party assurance providers — ISAE 3000 / ISAE 3410 / ISSA 5000-aligned evidence.
• Internal audit and data quality teams — anomaly detection, root-cause analysis on data issues.
• Stakeholders asking how a number was produced — investors, regulators, customers querying a specific disclosure.

It's also what makes year-on-year recalculation defensible. When a structural change requires base year recalculation, the audit log records the original values, the recalculation methodology, and the adjusted values — so the comparison is reproducible.

What this guide doesn't cover

• Configuring audit retention. All audit data is retained — there's no toggle to disable or shorten retention. Configurable retention is not in scope.
• Read-only views and dashboard interactions. These aren't logged in the audit trail by design — the audit log focuses on changes to data, not on who looked at what.
• Methodology depth on assurance standards. See the reporting guides for ISAE 3000, ISAE 3410, and ISSA 5000 coverage.

Where to go from here

• How emissions calculations work — the calculation chain that the audit log traces.
• Log your first data point — how to attach files and notes at log time so they end up in the audit log.
• Frameworks supported in GreenSphere — what reports the audit log supports for assurance.
• For methodology depth on assurance: see the reporting guide on common reporting mistakes, particularly the documentation discipline points.