Reading the organization activity log as your audit trail

The auditor's request lands in your inbox on a Monday: "Provide a record of all administrative changes to your account for the audit period, including who made each change and when." You are the one with the mandate to get the company through SOC 2, so this is yours to answer. You start where most people start. The help desk inbox. A spreadsheet someone kept for a while and then stopped. A few Slack threads where access got granted and nobody wrote it down properly.

By Wednesday you have a patchwork. You can mostly say who did what, except for the three changes a vendor made on your behalf that never landed anywhere you can point to. You are not missing the work. The work happened. You are missing the record that it happened, in a form you can hand to someone who was not in the room.

That gap is the difference between a control that exists and a control you can prove. An audit does not ask whether you are careful. It asks you to show it, in writing, with names and timestamps. The question worth sitting with before that Monday email arrives: when someone asks who changed what, can you answer in minutes, or does it cost you a week?

The organization activity log is a chronological feed of the events that matter for accountability. It is not a feature you remember to turn on. It records as the work happens, which is the only kind of record that survives an audit, because a log you have to maintain by hand is a log that goes stale the first busy week.

What lands in it is deliberately short. The log captures the events that change who can do what, or that touch your data:

• Members invited, accepted, promoted, or removed.
• Primary and backup contacts set or changed.
• Sensitive actions taken on your behalf, such as access granted or revoked, a policy refreshed, or customer data exported.
• Sign-ins from a new device, when we can determine it.

Routine traffic stays out on purpose. Filing a request, replying on a thread, reading a policy: none of that clutters the log, because an audit trail buried in noise is as useless as no trail at all. The point is a clean record of the handful of actions a reviewer asks about.

Here is the part that matters for someone carrying a compliance mandate. The log shows customer actions and Cloud Sentry actions together, in one feed, with a colored badge on every entry telling you which side took the action. Teal for your team, gray for ours.

That single design choice closes the gap that turned your Monday into a week. When a vendor makes a change on your behalf and it never lands in a record you control, you are stuck reconstructing it later. When the people running your environment write their own actions into the same log you read, there is nothing to reconstruct. The change to revoke a contractor's access shows up next to the request that asked for it, with our operator's name and role attached.

One partner running the work and recording the work means the change we make and the proof we made it are the same entry, not two systems you have to reconcile.

This is what people mean when they say evidence should fall out of running the environment properly. You do not assemble the audit trail. It is the byproduct of the operation being run in one place, by one accountable team, with both sides writing to the same record.

Reading the log is built for the moment an auditor is waiting. The page loads the most recent events, and filter pills narrow the view by source (your team or ours), by the person who acted, and by event type. The search box matches on the action label, so "access" or a teammate's name pulls the relevant slice fast.

Once the view shows what the request asked for, the Export CSV button downloads exactly that filtered set. One row per event, with stable column names suited to evidence collection, ready to attach to a workpaper or hand to your assessor. The export action gets logged back to the log itself, so the record of who pulled the evidence is preserved too. The trail does not have a blind spot where you reached in to read it.

For history older than the page loads, you file a request and we pull it from the audit store. Account-level events are retained for the life of the relationship, so the period an auditor asks about is the period you can produce.

A few things sit outside the log by design, and you should know them before you rely on it. Our internal teammate notes are not in it; the action a note led to is logged, the note itself is not. Other companies' activity is never visible to you. And changes made directly inside a vendor's admin console, without coming through us, are not captured here. If you need a view that spans systems we do not run, we can assemble one as a one-off, but it is honest to say the log covers the work that flows through us, not every click in every console you own.

That boundary is the right one. A log that claimed to see everything, including things it cannot observe, would be a log you could not trust. SOC 2 is paperwork with consequences, and the consequence of a record that overstates itself is a finding. A trail that is honest about its edges is one an assessor can lean on.

Walk back to that auditor's request. The patchwork version cost you a week and still had three changes you could not place. The version where the work was run in one operation looks different. You open the log, filter to the audit period and the event types in scope, read down the feed with both sides showing, and export the CSV. The changes a vendor made on your behalf are right there, in gray, with names and timestamps, because the team that made them wrote them down as they went.

That is the whole idea behind reading the activity log as your audit trail. The evidence is not a project you start when the email lands. It is already written, because the environment was run in a way that records itself. So the real question is not whether you can eventually answer the auditor. It is whether your answer is sitting there ready, or waiting to be reconstructed from memory. Which one describes yours today?