What To Look for in Integration Platform Audit Logging
When you start looking for an enterprise-grade integration solution, compliance and security are two of your top priorities. But when you actually have conversations with vendors, you’ll hear terms like “audit logging,” “activity logging,” and even “activity audit” used interchangeably, meaning you have to guess at whether a specific platform complies with your requirements or not.
That’s why you need your own framework to evaluate what’s actually happening behind that “activity audit.” Without that framework, you might deploy a platform that can’t track credentials throughout the company, or gives you no visibility on configuration changes.
For an integration platform, audit logging needs to log four components: configuration changes, authentication events, data syncs, and field-level changes.
Here’s what each of these mean.
TL;DR
Not all integration platforms mean the same thing when they say “audit logging.” To evaluate vendors properly, look for four capabilities: configuration change logging (who modified a flow and how), authentication event logging (what connects to what and under what permissions), data sync event logging (what moved, when, and whether it succeeded), and field-level change logging (which specific fields changed and in what direction).
Configuration change logging: Who touched an integration flow?
Configuration change logging creates a record when an integration is created, modified, or deleted. This record includes the name of the person (or, at least, the account) who made that change, the date and time it was made, and the impact of that change.
In teams of 10 to 50 people, it’s pretty easy to track down who changed an integration and find out what change they made. But when hundreds of people might have access to the same platform, you need dedicated tools to identify and trace these changes. Not only that, but enterprise organizations typically work in environments that are more strictly regulated. You need to know when an integration stops being compliant, where that change came from, and who can give you more context on it.
Most platforms log system-wide events, but look for user-attributed events. You should be able to trace any configuration changes to specific credentials, in case you need to investigate a misconfiguration or update documentation.
Timestamps are also essential for these logs. The more specific the timestamps, the easier it is to investigate any configuration issues. It’s not just an extra data point for each record, it’s an essential element for any investigation.
Knowing when a change was made and who made it is useful, but audit logging should include clear before/after states for each change. Say, for instance, that a specific field mapping between Jira and Asana gets updated. A before/after state would show what the field mapping was before it was updated (e.g., To Do→Backlog) and what it was after an update (e.g., To Do→In Progress). That would allow an IT team to link a sudden influx of unexpected Asana tasks to this field change.
Finally, audit logging should include configuration changes for whatever your overall audit cycle is (e.g., a year). That cycle might depend on other processes throughout your organization or compliance frameworks you follow.
Authentication event logging: Tracking what connects to what
Every account that has access to your integration platform is a potential entry point for a malicious actor. Small organizations can afford to not have a centralized platform for managing credentials. You can’t. You need a centralized record of every connection attempt, every change in credentials, every OAuth permission request, and every login event.
By their nature, integration platforms get access to a broad range of source systems. Not only do these platforms use credentials to automatically access these systems, but each user has their own credentials to access the platform itself. That leads to a sprawling number of credentials to track and manage. This is both a security and compliance risk.
Many situations can cause these risks without clear, centralized authentication logging. Imagine, for example, that an employee leaves suddenly. They have credentials for your integration platform and multiple tools that are integrated through it. But when that person leaves, no one knows exactly which tools they have credentials for. That means you either have to manually hunt them down one by one, or risk a malicious actor accessing your tools through abandoned credentials.
Authentication event logging needs visibility into tool connections. An integration platform should give you a single place to review all tool connections, including the credentials used for these connections. It should also include tracking for tool connection events, including new tools being connected, connections or credentials being modified, and connections being revoked.
Authorization tracking is also essential. Authorization is typically a step within tool connection which actually allows data to flow between tools. Knowing where authorizations come from and what they include is vital.
Finally, authentication event logging should include visibility on permission scope changes. Permission scopes determine the range of actions integration platforms can take and the data they can access. For example, take an integration that was built with read-only permissions to support reporting workflows. A rogue user updates this integration to include read/write permissions, not knowing that the limitation was there for a good reason. At best, this results in a broken integration. At worst, you’re looking at overwritten data that’s difficult or impossible to revert.
Data sync event logging: The operational audit layer
Data sync event logging creates a record for each time an integration platform moves data or creates a work item. This record includes what was synced, how much data was synced, and whether an individual sync succeeded or failed.
This type of audit logging gives IT teams two essential types of data: positive evidence (i.e., data synced successfully) and investigative evidence (i.e., data didn’t sync as expected). While it can be used for troubleshooting, this log is more for audits and compliance. With a clear record of every data sync event, you can review patterns that lead to failures or compliance gaps.
Audit logging needs to include per-event timestamps. This level of granular detail is essential for a proper audit trail, especially for matching individual failures to specific syncing events. That audit trail should also include success/failure statuses with error detail. An integration platform should clearly label flows that have failed, with individual statuses for the most common failure states (e.g., authentication issues, configuration changes).
You also need a strong search function to find the data sync events you need for audits and investigations. That function should also allow you to narrow your search to specific data flows, work item types, or sync types. Without that specificity, your investigations will take much longer.
Much like with other types of audit logging, data sync events should be recorded and kept for whatever your audit cycle is. That way, you’re not going to have gaps in your audit trail come compliance review time.
Field-level change logging: The most granular audit layer
Most integration platforms log changes at the item level (e.g., tasks, issues, records). While that can surface a number of errors, misconfiguration problems, and security issues, it leaves many of them buried. Field-level changes can uncover field mapping and other issues.
Audit logging needs to go deeper than data flows or work items. Field-level changes give you more granular visibility on everything from historical states to updated states and sync direction. With this detail on a field-by-field level, you can ensure data flows access the right fields — and do so properly.
While troubleshooting might only require work item depth, field-level change logging is essential for compliance investigations. It allows IT teams to know exactly what changed within individual work items, which is essential for ensuring integrations stay compliant. Otherwise, you’ll run into issues like a status field being changed from “Approved” to “Pending” through an integration, with no one able to explain how or why that happened.
Field-level change audits should include records of old values, new values, and timestamps for when these changes occurred. That way, you can link specific changes to any productivity losses, misconfigurations, or technical issues. You should also be able to see which direction data flows for each field-level change, since field-level sync direction can be different from the direction of the overall flow.
Audit the right way
Deep audit logging capability is essential for an enterprise-grade integration platform. But when vendors use the terms without being able to explain what they mean, you need to do your own research. Configuration change logging is especially important in organizations that democratize integration access (i.e., business users in all teams can build their own integrations). Authentication event logging centralizes credentials so you can ensure only pre-approved tools are accessed by your integration solution, preventing potential data breaches or configuration errors. Data sync event logging creates a record of every single time your integration platform pushes data, including which fields it’s pushed to and the direction data is flowing. Finally, field-level change logging gives you the granular data you need to review exactly what’s going on in every integration.
These features are essential for keeping your integrations compliant, preventing potential security risks, all while ensuring teams can truly work seamlessly across tools.
Want an integration platform with robust audit trails?
Get a product demo and see what Unito's deep integrations and robust audits can do for your workflows.
FAQ: Integration platform audit logging
What is an integration platform audit log?
An integration platform audit log is a ledger that records every event occurring within an integration platform. These events include what an integration changed, who or what triggered that change, and when it happened. This log allows IT teams to troubleshoot integrations when they stop working, verify credentials, review data syncing events, and validate field-level changes.
What’s the difference between an activity log and an audit trail?
There are two main differences between an activity log and an audit trail:
- Depth: An activity log typically records less information than an audit trail. Where an activity log might tell you what work item was synced by what integration, an audit trail would add who authorized that action, what permission scope was involved, and more. It would also stay available for longer.
- Purpose: Activity logs are typically used for troubleshooting, which is why they don’t show nearly as much information as an audit trail. Audit trails are an evidence trail, used to maintain data security and ensure compliance.
Does SOC 2 compliance require integration platform audit logging?
While SOC 2 doesn’t specifically mandate audit logging by name, audit logging can help you meet its other requirements. For instance, its monitoring and access control criteria require a traceable record of who accessed what systems, what was changed, and when that change happened. For integration platforms, that means you need logs covering authentication events, configuration changes, and data sync activity, which audit logging covers.
How long should integration audit logs be retained?
The exact time will vary depending on specific compliance frameworks you need to meet. But for most organizations, retaining audit logs for one to three years should satisfy most requirements.
What is field-level change logging in an integration context?
Field-level change logging means an integration platform doesn’t just log which work items were synced or modified by an integration, but which fields in these work items were changed. Not all integration platforms have audit logs that handle this kind of depth, because it requires sorting states rather than just events, but it allows for quicker troubleshooting and better compliance.