Unit 2.3: Activity Logs and the Audit Trail
Introduction
For a regulated enterprise, the audit trail is not an operational convenience; it is evidence, and evidence has to outlive any 35-day window and has to be tamper-evident. The IONOS Activity Log is deliberately narrow: it tells you who did what within one contract, it cannot be altered, and it keeps only 35 days. Those constraints are not gaps to complain about; they define the design. The audit architecture that satisfies a BSI or GDPR reviewer is built around the log, not inside it, by treating its retention window as an export deadline into immutable storage. This unit sets out the log's exact shape and then the external retention pattern FinCorp must adopt.
1. The Fixed Shape of the Activity Log
The Activity Log lets contract owners and administrators view the history of actions performed on resources within a single contract: user logins, resource provisioning, configuration changes, data access, resource retrievals, modifications, and deletions. Four properties fix its shape and drive every downstream decision.
- Per-contract. The log is scoped to one contract and queried per contract, against the endpoint
https://api.ionos.com/activitylog/v1/contracts/{contractNumber}. There is no cross-contract view; an organisation spread across several contracts has several independent logs. - Read-only. The log is read-only by design. Entries cannot be edited or deleted by anyone, which is what makes the live log trustworthy as a short-term record, but it also means the log itself is not where long-term, legally defensible retention happens.
- 35-day retention. Entries are retained for 35 days; data older than 35 days is purged. The window is not configurable upward, so anything you need beyond 35 days must leave the log before it expires.
- GET-only API. Every call to the Activity Log API is a GET. There is no POST, PUT, or DELETE: you cannot write to it, cannot mutate it, and, importantly, cannot ask it to push events to you. Retrieval is pull-only, using Basic Authentication or a Bearer token, with date-range filters (startDate, endDate) and limit/offset pagination. Access is governed by the Access Activity Log capability right covered in Unit 2.2.
The combination is the whole story: a trustworthy but short-lived, pull-only, single-contract record. It is excellent as a source of truth and unsuitable, on its own, as a system of record.
2. Designing Aggregation and Retention Externally
Because the platform offers neither cross-contract aggregation nor push delivery, both of those capabilities are the customer's to build, and the native pattern composes around the log rather than expecting more from it.
Aggregation is a pull-and-fan-in design. A scheduled job (running under a scoped service user with the Access Activity Log right and a short-lived API token, per Unit 2.2) calls each contract's GET endpoint on a cadence comfortably inside the 35-day window, then forwards the records to a central destination: an Object Storage archive, and typically onward into an external SIEM for correlation across contracts and with non-IONOS sources. The platform will never initiate this transfer, so the schedule is the control; if the job stops, evidence silently ages out at 35 days with no alert from the log itself.
Long-term retention is an export-before-expiry design. The documented recommendation is to download Activity Log data and store it on different storage, with IONOS Cloud Object Storage as the explicitly recommended target. To make that archive defensible, the destination bucket uses Object Lock, which applies WORM (write-once-read-many) protection so objects cannot be deleted or modified for a specified retention duration; enabling Object Lock automatically enables bucket versioning, and Compliance mode prevents the retention period from being shortened or the object overwritten during that period. The result is a tamper-evident archive whose immutability is enforced by the storage layer, compensating for the fact that the live log keeps only 35 days. Object Lock must be enabled at bucket creation (it cannot be added to an existing bucket and cannot later be disabled), so the archive bucket is designed up front, not retrofitted.
For FinCorp, this makes the 35-day figure an operational deadline rather than a retention policy. A daily export job pulls each contract's log into a German-region Object Storage bucket created with Object Lock in Compliance mode, set to the retention period FinCorp's regulators require (often years). The live log remains the working view; the locked bucket is the system of record. If FinCorp ever splits its estate across contracts, the same job simply iterates more contract numbers, since aggregation was always going to be external anyway.
Decision Summary
Design the audit trail as a short-lived source feeding an immutable external archive.
| Audit requirement | What the Activity Log gives you | The design you must add |
|---|---|---|
| Who did what, recently, in one contract | Per-contract, read-only log, 35-day retention | Use it directly as the live view; grant Access Activity Log narrowly |
| Retention beyond 35 days | Nothing; data older than 35 days is purged | Scheduled export to Object Storage before expiry; treat 35 days as a deadline |
| Tamper-evident long-term evidence | Read-only live log, but only 35 days | Object Lock (WORM, Compliance mode) on the archive bucket, enabled at creation |
| Cross-contract or correlated audit | No cross-contract view, GET-only, no push | Pull each contract and fan in to an external SIEM; the schedule is the control |
Summary
The Activity Log is per-contract, read-only, retained for 35 days, and exposed through a GET-only, pull-only API, which makes it a trustworthy short-term source but never a long-term system of record. Aggregation across contracts and any correlation are external designs because the platform offers no cross-contract view and no push. Long-term, tamper-evident retention is achieved by exporting before the 35-day purge into an Object Storage bucket created with Object Lock, so the window becomes an export deadline rather than a retention ceiling.
Key Points:
- The Activity Log is per-contract, read-only, retained 35 days, and GET-only; data older than 35 days is purged and the window is not extendable.
- There is no cross-contract aggregation and no push delivery; both are customer-built as a scheduled pull-and-fan-in, often into an external SIEM.
- Long-term retention is an export to Object Storage with Object Lock (WORM); Compliance mode makes the archive immutable, and Object Lock must be enabled at bucket creation.
- Treat 35 days as a hard export deadline: if the export job stops, evidence ages out with no alert from the log.
Important Terminology:
- Activity Log: A per-contract, read-only record of actions on resources, retained 35 days and accessed through a GET-only API.
- Object Lock: WORM protection on an Object Storage bucket (enabled at creation, auto-enables versioning) that prevents objects from being deleted or modified for a set retention period; Compliance mode forbids shortening that period.