Using the Audit Log for Compliance and Accountability

What Gets Audited

Blueprint's audit log captures 29 specific actions organized into 10 categories. Connection actions (4 total) track when ad platform connections are created, updated, reconnected, or removed. Team actions (5 total) cover member invitations, invitation acceptance, role changes, member removal, and invitation cancellation. Workspace actions (1) record workspace setting modifications. Budget actions (4) capture budget target creation, updates, deletion, and application to ad platforms.

Alert actions (1) log when alert configurations are changed. Negative keyword actions (3) track list creation, keyword additions, and keyword removals. Placement exclusion actions (3) mirror the negative keyword structure -- list creation, addition, and removal. Conversion action changes (1) record modifications to conversion tracking configuration. Billing actions (2) capture plan changes and payment method updates. Finally, account actions (3) track profile updates, password changes, and account deletion requests.

Every audited action is captured regardless of whether it succeeds or fails at the application level. If a budget update is submitted but fails validation, the attempt is still logged with the failure reason in the details field. This comprehensive capture means the audit log serves as both an accountability tool and a debugging aid -- you can trace exactly what happened, in what order, and whether each action completed successfully.

Reading the Audit Log UI

The audit log is accessible from Settings → Audit Log in your workspace. It displays as a flat table with five columns: Date/Time (in your local timezone), User (the display name of the person who performed the action), Email, Action (with a color-coded badge), and Details (a JSON-like summary of what changed). The table is paginated at 25 entries per page, with navigation controls at the bottom.

Action badges are color-coded by their prefix to help you scan the log quickly. Connection-related actions use the info color (blue), team actions use primary (teal), budget actions use warning (amber), and account-level actions use danger (red). This color system lets you visually distinguish between routine operational changes (connection syncs, team invites) and high-impact modifications (budget changes, account deletions) without reading every line.

Above the table, category filter chips let you narrow the view to specific action types. The available filters are: All, Connections, Team, Workspace, Budgets, Alerts, Billing, and Account. Clicking a chip filters the table to show only actions in that category. This is particularly useful during client reviews or audits when you want to show only budget-related changes without the noise of routine connection and team events. The filters work with pagination, so you can page through filtered results without losing your filter selection.

Audit Log Architecture

Blueprint writes audit log entries asynchronously using BullMQ, the same job queue system that powers data sync workers. When an API endpoint performs an auditable action, it dispatches an audit log write job to the queue rather than writing directly to the database. This async pattern is critical for performance -- audit logging should never add latency to the actions being logged. If the audit log database is temporarily slow or unavailable, the API request still completes successfully, and the audit entry is written when the queue processes the job.

Each audit log job includes retry logic with exponential backoff. If the initial write attempt fails (due to a database hiccup, network issue, or any transient error), BullMQ retries the job up to 3 times with increasing delays between attempts. This ensures that audit entries are not lost due to momentary infrastructure issues. Only after all 3 retries are exhausted is the job marked as failed, and even then the failure is logged to Blueprint's structured logging system (pino) so it can be investigated.

Every audit log entry captures contextual metadata beyond just the action itself. The IP address is extracted from x-forwarded-for or x-real-ip headers (to correctly identify the client behind load balancers and proxies), and the user agent string is stored to identify the browser or API client used. For actions that modify existing data, the entry includes both the before and after state, creating a diff-like record of what changed. For example, a budget target update would show the previous target amount and the new amount, making it easy to see exactly what was modified without needing to compare snapshots.

Using the Audit Log for Client Transparency

For agencies, the audit log is one of the most powerful tools for building and maintaining client trust. When a client asks "who changed the budget on campaign X?" or "when was that keyword list updated?", you can pull up the audit log and show them the exact entry with the user, timestamp, and before/after state. This level of transparency eliminates finger-pointing and builds confidence that their account is being managed professionally.

Consider sharing audit log screenshots or exports during regular client review meetings. Showing a filtered view of budget-related actions for the month demonstrates that changes were deliberate, documented, and traceable. This is particularly valuable for clients who have been burned by agencies that made unexplained changes or could not account for budget discrepancies. The audit log turns "trust us" into "verify for yourself."

If you give clients Viewer access to the workspace, they cannot currently see the audit log directly -- the audit log is accessible to Analysts and above. However, you can filter the audit log to budget actions, take a screenshot, and include it in your client reporting deck. This hybrid approach gives clients the transparency they want while keeping the full audit log (which includes internal team management actions) visible only to your team.

SOC 2 and Compliance Readiness

Blueprint's audit log is designed with compliance frameworks in mind. For organizations pursuing SOC 2 Type II certification or similar compliance standards, the audit log provides several key capabilities that auditors look for. First, it creates an immutable record of all significant actions within the platform. Audit log entries cannot be edited or deleted through the application interface, ensuring the historical record cannot be tampered with after the fact.

Second, every entry includes user attribution -- you can always trace an action back to the specific person who performed it, identified by both their user ID and email address. Combined with RBAC enforcement (which ensures only authorized users can perform certain actions), this creates a clear chain of accountability. Third, IP tracking provides an additional layer of context that auditors value. If a suspicious action appears in the log, the IP address can help determine whether it originated from an expected location or network.

The before/after state capture is especially valuable for compliance. When an auditor asks "can you prove that budget change X was authorized and what the previous value was?", the audit log entry contains both the old and new values alongside the identity of the person who made the change. This eliminates the need for manual change documentation or approval workflows -- the audit trail is generated automatically for every action, every time, without requiring any additional effort from your team. While Blueprint's audit log alone does not make you SOC 2 compliant, it provides the technical foundation for the access control and change management controls that auditors evaluate.