What should a data integration platform's audit trail actually record?
Most security reviews ask for an audit log and accept a screenshot. The useful question is narrower: after an incident, can you reconstruct who changed which pipeline, from where, and when — without having to ask the person who changed it?
Bridge logs operator activity rather than data values: who signed in, from which IP address, and which data connections, transformations and jobs they then worked on. Visibility is split by role — auditors see every user's activity, everyone else sees their own and their tenant's.
The four questions an audit log has to answer
An audit trail is only useful if it answers a specific question after a specific incident. Four questions come up repeatedly, and a log that cannot answer all four leaves the reviewer reconstructing events from memory.
| Question | What the record contains | Why it decides the investigation |
|---|---|---|
| Who | The account that signed in and performed the operation | Attribution is impossible if a team shares one login |
| When | Timestamp of the sign-in and of the operation | Orders the change against a deploy window or a known incident |
| From where | The IP address of the session | Separates console work from API calls made by an integration |
| What | The object class touched — data connection, transformation, job | Scopes the blast radius before anyone opens a pipeline |
The third row is the one that gets skipped in procurement checklists and matters most in operations. When a scheduled job starts failing at 02:00, the first question is whether a person changed something or an automated caller did. Without the source address, both look identical.
Operator activity is not the same as data content
Two different things get called "audit": knowing what an operator did, and knowing what data moved. They are separate controls with separate evidence, and conflating them is how reviews end up with a log nobody can use.
| Control | Default | What changes when it is enabled |
|---|---|---|
| Real-data display in exploration and test runs | Off | Lets a user preview actual field values while exploring data or running a transformation in test mode. It is a deliberate tenant-administrator decision because enabling it exposes sensitive values. |
| SecretKey reveal | Requires the user's own password | An AccessKey identifier alone is not enough to recover the secret, so a leaked key is not automatically a leaked credential. |
| Import and export in a sandbox tenant | Restricted to the tenant owner | Other users cannot import or export data connections, transformations, jobs or batch jobs, which keeps a sandbox from becoming an exfiltration path. |
| Kerberos configuration | System-level, view-only for tenants | Tenant users can read the configuration but not create or edit it; the principal binding is managed centrally. |
The first row is the design choice worth arguing for in a review. Showing real data in a console is convenient and is exactly what makes a support session dangerous. Shipping with it off means the convenience has to be asked for, by a named administrator, with the risk on the record.
Credentials belong to a user, not to the administrator
API access uses an AccessKey and SecretKey pair issued by a system administrator to a user who is authorised to integrate. Regenerating the pair replaces it, and viewing the SecretKey requires re-entering the account password.
The consequence for audit quality is simple and usually missed: an integration should have its own identity. If every automated change is made with an administrator's credentials, the audit log attributes machine work to a person, and the log stops being evidence. Give the integration its own user, and each API-triggered change appears under a name that maps to a system you own.
Where this log ends and other systems begin
A platform audit log covers actions taken inside the platform. It does not, and should not, claim to be the record of what was read from a source database or written to a warehouse — those systems keep their own access logs, and they are the systems of record for their own traffic.
Inside the platform
Sign-ins, IP addresses, and operations on data connections, transformations and jobs, with role-split visibility.
At the source
The database's own audit or session log records who queried which table. Keep it; the platform log will not replace it.
At the target
Warehouse query history and access grants show what was written and by which account.
In the data itself
Row-count reconciliation and file hashes prove the data arrived intact — a separate control from knowing who ran the job.
Map those four together and a review has a complete story. Present only the first and the reviewer will ask about the other three; present all four and the conversation moves to the questions that actually need a decision.
Audit, answered
Does the audit log record row-level data changes?
No. It records operator activity — sign-ins, source addresses and operations on data connections, transformations and jobs. Row-level provenance comes from the source engine's own log, and data-level agreement comes from reconciliation.
Who can see another user's activity?
Auditors can see every user's operations. A non-auditor sees their own operations and their tenant's.
Is sensitive data visible in the console by default?
No. Real-data display during data exploration and test runs is off by default. A tenant administrator can enable it, which exposes actual values and should be a recorded decision.
How should an automated integration be attributed?
Give it its own user and its own AccessKey pair, so the log records each call against that identity rather than borrowing an administrator's account.
Can alerts go outside the platform?
Yes. Push configuration delivers over SMS and email to configured contacts, each with a name, phone number and address; either channel can be left empty if only one is used.
How do we prove the data itself is intact?
With reconciliation receipts and file hashes rather than the operation log. Both methods are described on the cut-over page.
Bring the audit questions to a POC
Run the trial inside your own environment and review the operation log with your security team before you buy.