Quarterly Doppler access review board for SOC 2 audits

Build me an app my security lead opens once a quarter to run our user access review on our Doppler workplace, so we stop doing it in a spreadsheet the week before the SOC 2 audit. It should be a working surface with saved decisions, not a generated report.

The main screen is a review board with two tabs. The first tab covers human access. Build it by calling Doppler List Projects to get every project, then Doppler List Project Members for each project, which returns users, groups, service accounts and pending invites. Resolve each member's role name using Doppler List Workplace Roles, and use Doppler List Project Roles where the role is scoped to the project rather than the workplace, so the reviewer sees a readable role label like Admin or Collaborator instead of a slug. One row per project and member pair, grouped by project, showing the member name and email, the member type (user, group, service account or invite), the role, and the project.

The second tab covers non-human access, because auditors want machine credentials reviewed too. For each project from Doppler List Projects, call Doppler List Configs to enumerate its configs, then Doppler List Service Tokens for each config. One row per token showing the token name, its project and config, the environment the config belongs to, its access level, and when it was created and when it expires.

Cross-reference every human row against our identity provider using Okta List Users. Match Doppler members to Okta users by email address, and use the status filter so you can tell active people apart from ones that are SUSPENDED or DEPROVISIONED. Anyone who is suspended or deprovisioned in Okta but still has Doppler access is lingering access, which is the finding auditors hit most often, so pin those rows in a clearly marked section at the very top of the board above everything else. Also flag Doppler members who have no matching Okta user at all, since those are unmanaged identities. Pending invites that were never accepted should be surfaced as their own flag too.

The reviewer works down the list marking each row keep or revoke, with an optional note. Store those decisions per review cycle, where a cycle is a named period like Q3 2026, along with who made the decision and when. Show progress for the current cycle (how many rows are decided out of the total) and let the reviewer filter to just the undecided rows so they can pick the review back up. Keep completed cycles readable afterwards, because the board doubles as our evidence record: an auditor should be able to open a past cycle and see every row, the decision, the reviewer and the date.

Revoking is different for machines and humans. Marking a service token revoke gives a real button that calls Doppler Delete Service Token directly in the app, behind a confirmation dialog, and the row records that the revocation actually went through. Marking a human revoke raises a ticket with Linear Create Issue for an admin to action, with the person, the project, the role and the reason in the description, and the app stores the resulting issue so the row links to it and shows the ticket as the remediation trail. Note that Doppler Remove Project Member does exist, so also offer a direct remove action on human rows behind an explicit confirmation, but keep the Linear ticket as the default path, since fully offboarding a person usually spans more systems than Doppler alone and we want an admin to sign off. If you want to offer identity-side action as well, Okta Suspend User and Okta Deactivate User are available for people who are still active in Okta but should not be.

Add a Prepare this cycle's packet button that kicks off a background agent. The agent walks every project, pulls Doppler List Activity Logs to work out when each person and each token was last actually active, and then writes a findings summary back into the app where the board can display it alongside the current cycle. The summary should call out dormant accounts that have not been active all quarter, roles that look over-privileged relative to how the person actually uses the project, and anyone holding access to a production config who has not touched it all quarter. Have it reference specific people, tokens and projects rather than generalities, since this is what gets read in the audit. Show the reviewer that the job is running and display the findings when it lands.

Sort the board so the riskiest access is first: lingering access from the Okta cross-reference at the top, then dormant and over-privileged rows the agent flagged, then everything else. Make the quarter-over-quarter case easy by defaulting the cycle to the current quarter and letting the reviewer start a new cycle when the next review comes around.