Logging and audit trail: audit-proof logging under Swiss CO Art. 957a for SMEs

What are logs and audit trails?

A log is the timestamped record of an event in an IT system: a login, a database write, an API call, a permission change, an LLM output. An audit trail is the sum of these entries, complete and immutable, ordered in time, linking actor, action, and object. The audit trail serves three purposes: technical debugging, security forensics (what did the attacker do?), and statutory record-keeping (what did the system do, when, with which business data?).

In Switzerland, Article 957a of the Code of Obligations requires proper bookkeeping that is complete, truthful, systematic, and substantiated by source documents. Article 958f sets the 10-year retention duty for business records, accounting vouchers, and business correspondence. Anyone keeping books in software must log all relevant actions so the books remain auditable in 10 years - linking user, time, and modified data.

For AI systems an additional dimension applies: every LLM-generated document (client reply, posting suggestion, payroll calculation) must be reconstructible later. Which model version? Which system prompt? Which retrieval chunks from the vector database? Who approved the output? This is no longer optional, it is state of the art in 2026.

Why it matters

Three drivers make audit trails a mandatory discipline. First, the law: Swiss CO 957a, VAT Act, FINMA circulars for financial services, FADP Art. 8 (processor record duty). Second, security: without logs no incident can be reconstructed after the fact - the incident response (see incident-response-playbook) collapses in phase 2 (detection and analysis). Third, trust: a client asking who viewed her file when expects an answer in minutes, not weeks.

Concretely for a fiduciary: a client in Zug asks in July 2026 why her April payroll deviated. Without logs: hours searching Bexio backups. With logs: a Loki query on the client case, all actions visible in 5 seconds, including the AI suggestion and the manual override by staff.

Concretely for an LLM incident: a lawyer discovers that a chatbot gave a client wrong advice. Without logs: speculative debate over the error. With logs: exact prompt, exact model output, exact retrieval passages, exact timestamps - the lessons-learned analysis has material.

How it works

What to log. At minimum: login and logout with IP and user-agent, every write operation (Create, Update, Delete) on business or personal data, every permission change, every data export, every LLM inference with prompt hash and model version, every failed access attempt. Bulk database reads (e.g. the full client list) too, since exfiltration is a preferred attack path.

What NOT to log. Passwords, API tokens, clear-text secrets, full client records as payload (data minimisation under FADP Art. 6 and GDPR Art. 5). Instead: only references such as record IDs, hashed identifiers, or pseudonymised values. Credit-card PAN, bank-secrecy data, and health data never belong in normal logs.

Where to store. Hot storage for 30 days in Loki or Elasticsearch with indexed labels for fast queries. Cold storage for the remaining 10 years on WORM media (Write-Once-Read-Many): S3 Object Lock in compliance mode, Azure Blob Immutable Storage, local LTO tape with WORM cartridges, or Backblaze B2 with Object Lock.

How to make it immutable. Append-only database tables with RBAC enforcement (INSERT only, no UPDATE/DELETE). A hash chain similar to blockchain: each entry contains the SHA-256 hash of the previous entry. Tampering attempts become visible at the next verification (see ai-audit-trail-design). External timestamp services (RFC 3161 TSA) certify the time of log creation in a forensically defensible way.

Tools as of May 2026. Grafana Loki remains the open-source standard for container logs - stores labels indexed, body compressed; one-day setup, minimal ongoing effort. Wazuh is the SME choice for security event logging and combines SIEM with file-integrity monitoring. GrayLog 6 is popular for compliance logs with native retention management. Elasticsearch (now under Elastic License 2.0 and the early-2026 AGPL option) remains the heavyweight stack for full-text search.

Correlation and search. Logs from different sources need a common correlation field. The standard is a UUIDv7 request ID propagated from the web app through backend, database, and LLM gateway. A Loki query like `{service="fiduciary-api"} | json | request_id="018f2b4a-..."` pulls the whole client journey together.

Build audit logging in 6 steps

1. 01Inventory: which systems produce which logs in which format? Standardise on JSON logs with shared fields (timestamp, level, service, user, request_id).
2. 02Classify: what must be audit-proof for 10 years, what is fine at 90 days, what must never be logged (passwords, clear-text secrets, full payloads).
3. 03Set up hot storage: Loki or Elasticsearch for 30 days, with indexed labels for fast queries.
4. 04Set up cold storage: S3 Object Lock in compliance mode or LTO tape with WORM cartridges for the rest of the 10 years.
5. 05Make immutable: insert a hash chain, RBAC restricted to INSERT, external RFC 3161 timestamping as proof.
6. 06Test and rehearse: quarterly random queries, annual rehearsal of the cold-storage restore path.

When to use structured audit logging

Structured logging is not optional for organisations that (a) keep business books (Swiss CO 957a), (b) process personal data (FADP Art. 8 accountability), (c) carry out regulated activities (FINMA, FOPH, NCSC).

Concrete Swiss use cases: a fiduciary connected to Bexio, Abacus, or ProffixPx - any write action from the in-house app must be audit-proof. A law firm with electronic case files - client-file access must be provable (Art. 321 SCC does not require it directly, but defending against accusations of a breach demands evidence). An e-commerce site with VAT-relevant postings - the federal VAT auditor (ESTV) requires a full audit trail. An LLM platform in productive client use - every inference must be stored with prompt hash and output.

A rule of thumb: as soon as more than one person uses the system and external data enters, structured audit trail pays off.

When to scale logging back

Logs are not endlessly cheap. A 25-container platform produces several gigabytes per day - without sampling and retention policies, that fills even large disks within weeks. Three cases where logging should be scaled back:

Leaving debug logs at DEBUG level in production is a classic - it produces 10x to 100x more log volume than needed. Production standard is INFO, with targeted DEBUG only during failure analysis.

Healthcheck logs every second from 30 containers are noise that hides real events. Promtail or Vector filter such entries out before they reach Loki.

Logs with personal data in the payload are a FADP problem: the retention window for logs (often 90 days or 1 year technically) conflicts with the FADP deletion duty for personal data. Solution: no personal data in logs (see above), only references, or a two-track retention policy with automated removal of personal-data fields after their lifetime.

Also: untested audit logs mean you only imagine you have them. Quarterly random check queries on uncritical events preserve the discipline.

Trade-offs

FAQ

Related topics

Sources

1. Schweizerisches Obligationenrecht Art. 957a und 958f - Buchführung und Aufbewahrung · 2026-04
2. EDÖB - Leitfaden technische und organisatorische Massnahmen, Kapitel Logging · 2026-05
3. Grafana Loki 3.4 - Documentation, Retention and Compaction · 2026-05
4. Wazuh 4.10 - Documentation, File Integrity Monitoring and Audit · 2026-04
5. BSI IT-Grundschutz OPS.1.1.5 Protokollierung · 2026-03