Monthly Doppler audit log report for SOC2 reviews

On the first business day of every month at 9am in our workplace timezone, run an agent that produces a monthly secrets-access compliance report from Doppler activity logs and publishes it to Notion and Slack. The goal is a durable audit artifact our security and compliance teams can hand to SOC2 and ISO 27001 reviewers without anyone manually trawling the Doppler activity log.

Trigger: a cron schedule that fires at 9am workplace time on the first business day of each month (skip Saturdays and Sundays so the report always lands on a weekday). The reporting window is the previous 30 calendar days, ending at midnight of the trigger day in the workplace timezone.

Step 1: Pull the activity. Use Doppler's List Activity Logs operation to read workplace-wide audit entries. Paginate by incrementing the page parameter (per_page up to 100) until you have covered the full 30-day window or the response array comes back empty. Stop as soon as the entries fall before the window start. Activity logs are an enterprise-plan feature; if the call returns a permission error, fail loudly with a clear message so the user knows their Doppler plan does not include this.

Step 2: Bucket every event by category. The categories are: secret create, secret update, secret delete, member invite, member role change, service token create, service token revoke, project create or delete, and config create or delete. Count totals per category for the executive summary.

Step 3: Flag higher-risk activity into a "needs review" list. The risk heuristics are: any edit to a production config (configurable list of config names, defaulting to prd, prod, production); any actor who deleted or downloaded more than 10 secrets in a single day (treat as a bulk action); any action that happened outside business hours, defined as before 7am or after 7pm in the workplace timezone, or on a weekend; any service token minted without an expiry; any member role change that elevates a user (member to admin, viewer to collaborator).

Step 4: Write the report into Notion. The user will configure a Notion parent in their integration setup; accept either a database id (in which case use Create a Page under the database, with a Name property like "Doppler compliance report, May 2026") or a page id (in which case use Create a Page as a child page with that title). After the page exists, populate the body using Update Page Content as Markdown (preferred) or Append Block Children. The page must contain, in this order: an executive summary paragraph naming the window, total event count, and a one-line risk verdict; a counts table with one row per category; a "needs review" section that lists each flagged event with actor email, timestamp in the workplace timezone, resource (project, config, secret name), the risk reason, and a link back to the Doppler activity log entry by id; and a closing "signed off by" line with a blank for the compliance reviewer.

Step 5: Post a short Slack message via Slack Bot's Send a Message to the configured security channel. The message should be three lines: the month covered, a link to the new Notion page, and the top three flagged events as bullet points naming the actor and the risk reason. Keep it under 600 characters so it reads cleanly in the channel.

Inputs the user should be able to configure on the workflow: the Notion parent (database id or page id), the Slack channel id or name for the security team, the workplace timezone (default America/Los_Angeles), the list of production config names that get the strictest scrutiny (default prd, prod, production), and the bulk-action threshold (default 10 deletes or downloads per actor per day).

If no events occurred in the window or none qualified as risky, still publish the Notion page and Slack message; both should say so explicitly. A clean month is itself a compliance artifact and needs to exist in the audit trail.