Audit Logs

The Activity Log we looked at in Lesson 2.4 is fine for ad-hoc review. Audit Logs are what you point compliance auditors at. They include metadata the Activity Log doesn't (IP addresses, user agents, a payload describing what each action changed), and they can flow continuously to a SIEM, which is the part most security questionnaires care about.

Saturday probably isn't running a SOC 2 audit right now. Setting up the flow is one configuration, a drain billed on the volume of data it exports (Drains pricing). Not having logs on the day you finally need them costs far more. Set it up the day you're on Enterprise. Confirm the destination is healthy on the day before your auditor calls.

Outcome

Audit Logs from Saturday's team flow through an Audit Log Drain to your chosen destination (Datadog, Splunk, Panther, Amazon S3, or a custom HTTPS endpoint). You've exported the last 30 days as a CSV and spot-checked it for anything that doesn't match expected activity.

Hands-on exercise 6.2

Two halves: set up the drain, then read the historical data.

Requirements:

1. Open Team Settings > Drains and click Add Drain
2. Choose Audit Log as the data type
3. Pick a destination based on what your security team already runs:
   • Datadog: most common for teams already on Datadog for observability
   • Splunk: common for security-heavy orgs, through the HTTP Event Collector
   • Panther: Vercel has a built-in source there, so it's the short path if your team already runs it
   • Amazon S3: for a raw archive you control
   • Custom HTTPS endpoint: for in-house SIEMs or pipelines
4. Follow the destination-specific setup. Most ask for an API key, a token, or an endpoint URL. For S3 and custom endpoints, pick JSON or NDJSON to match what your SIEM expects.
5. Click Test on the Drains page to send a sample event, and confirm it appears in your destination within a few minutes.
6. Open Team Settings > Security & Privacy > Audit Log, select the last 30 days as the timeframe, and click Export CSV. Look for anything you don't recognize.

Implementation hints:

• The drain is team-wide: one setup covers every project. Audit Log Drains don't offer project selection, filters, or sampling, so retention and filtering happen on the destination side.
• Audit logs are visible to team Owners only, so this whole lesson assumes you're one.
• Don't pick a custom HTTPS endpoint unless your pipeline needs it. Splunk, Datadog, and Panther receive fixed formats those tools already parse; with a custom endpoint, parsing is on you. If you do go custom, add a signature secret so you can verify deliveries.
• The CSV export doesn't download in the browser. Vercel emails the team owner who requested it a link, and that link expires (details), so download it the same day.
• If your team already streams through the older Custom SIEM Log Streaming (configured under Security & Privacy > Audit Log), Vercel is replacing it with Audit Log Drains. You can run both while you validate the drain, then remove the old stream (migration guide).
• For the historical review, pay attention to:
  • User removals you didn't approve
  • Settings changes outside business hours (could be legitimate, worth a quick check)
  • Env var changes on production
  • Firewall rule changes
  • Anyone signing in from an unusual country
• Every event carries the IP address and user agent of the request behind it. If you're investigating something, those are the fields you want.

Try It

Creating the drain is itself an audit event. Look for the drain-created action in your destination. With a custom HTTPS endpoint, it looks something like this:

{
  "schema": "vercel.audit_log.v1",
  "id": "uev_7Qm2c8VbT1sXh4Lr9NaKdPEo",
  "teamId": "team_saturday",
  "action": "drain-created",
  "timestamp": 1779896531000,
  "actor": {
    "type": "user",
    "id": "user_eve",
    "name": "eve",
    "email": "eve@saturday.example"
  },
  "ipAddress": "203.0.113.42",
  "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15",
  "payload": {
    "drainUrl": "https://siem.saturday.example/vercel"
  }
}

That's the level of detail the Activity Log doesn't give you. The actor's IP and user agent sit at the top level, and payload holds whatever the action changed, so its shape differs from one action to the next. The timestamp is Unix milliseconds, which means your SIEM may need a parsing rule to show it as a date.

Now make a change you'd want an auditor to see. Edit a Config env var on Saturday, and within a few minutes an env-variable-edit event should land in your destination.

For the historical review, open the CSV from the export email in a spreadsheet, or load it into your SIEM. For a small team you should recognize every row. For a large team, filter by actor_email, action, or timestamp to make the review tractable; the previous and next columns show what changed. Note anything that doesn't look right.

Done-When

• Team Settings > Drains lists an Audit Log Drain, and its test event arrived at your destination
• A real event from your own change, such as env-variable-edit, arrived at your destination
• The drain has been running for at least an hour with no error indicators
• You've exported the last 30 days as a CSV and reviewed it
• Any events you didn't recognize have been investigated

Troubleshooting

The test event never shows up in my destination.

The most common cause is a credential issue: an expired API key, a wrong endpoint URL, or an IAM role that can't write to the bucket. Custom endpoints also have to answer with a 200 OK. Check the drain's status on the Drains page and your destination's own ingestion logs.

Events arrive, but my existing SIEM rules don't fire.

This is expected if those rules were written for the older Custom SIEM Log Streaming. Audit Log Drains send the vercel.audit_log.v1 schema: occurred_at became a Unix-millisecond timestamp, the context fields moved to top-level ipAddress and userAgent, and targets became payload. The action values changed too, without a one-to-one rename, so update any rule that matches on a specific action (schema mapping).

The CSV link in my email doesn't work.

The link expired. Request a fresh export from Security & Privacy > Audit Log and download it the day it arrives.

I see actions I didn't take personally.

Integrations, deploy hooks, and platform-side jobs produce events alongside human ones. They're normal, and you should expect a baseline level of them. They're worth excluding from your alerting rules so they don't trigger false positives.

Solution

The configuration:

Team Settings > Drains
  Data type:        Audit Log
  Destination:      [Datadog | Splunk | Panther | Amazon S3 | Custom HTTPS]
  Status:           Healthy
  Test event:       confirmed at the destination

Team Settings > Security & Privacy > Audit Log
  Export:           last 30 days (CSV), reviewed

Once you have this, the work isn't "set it and forget it." You should:

• Add an alerting rule for high-risk events: env var changes on production, firewall rule deletes, member removals
• Add an alerting rule for sign-ins from unusual geographies (especially relevant if you have a small, geographically concentrated team)
• Make audit log review a monthly habit. Even a 10-minute scan catches things that would otherwise go unnoticed for quarters.

Up next: we tighten down previews even further with Trusted IPs and Password Protection.