Blog

The audit log every sGTM container should expose

Built-in logs cover errors. Compliance information lives elsewhere.

For compliance reviews, what auditors want is rarely what default logging exposes. Two signals matter most: who changed the container, and what was sent to which destination.

Workspace change log

GTM tracks every change. Access under Versions. Export periodically via the GTM API. A weekly job that pulls changes and writes to your audit storage gives a permanent record.

Per-event destination log

Default logs show errors but not successes. Build with structured logging:

log({
  type: 'destination_send',
  destination: 'meta_capi',
  event_name: getEventData('event_name'),
  consent_state: getEventData('consent_state'),
  timestamp: Date.now()
});

Forward to long-term storage. 30-day retention is rarely enough; 12-24 months is typical.

Access log

Three layers: GTM workspace permissions, container permissions, runtime auth token. The access model post covers each.

Configuration drift log

If you use CI to export the container JSON, your git history is your drift log.

What auditors typically ask

  • "Show me every change to the consent management tag in Q1." Workspace change log.
  • "Demonstrate that no PII was sent to non-EU destinations." Per-event destination log.
  • "List everyone who could publish a tag change." Access log.
  • "Show me the diff of the container between Jan 1 and Mar 31." Git history.