Quarterly Bitwarden access review pack for SOC 2 audits

On the first weekday of each quarter at 8am, build the Bitwarden access review pack our SOC 2 auditor asks for. Use a cron trigger, because the Bitwarden public API does not emit outgoing webhooks. Cron cannot express the idea of the first weekday of a quarter on its own, so schedule it across the first few days of January, April, July and October on weekdays only, and have the workflow exit immediately unless today really is the first weekday of that quarter. That way it fires exactly once per quarter even when the first of the month lands on a weekend.

Start by pulling the organization structure. List Members gives me every member with their role type, status, two factor state, and the collections granted straight to their account. List Groups gives me every group along with its collection assignments. List Collections gives me every collection but leaves out group assignments, so call Retrieve Collection for each collection to get the groups attached to it and their permission flags such as read only and hide passwords. To connect people to groups, call Retrieve Group Member IDs for each group, which is far fewer calls than asking per member. Treat collections as read only throughout. This API cannot create or enumerate collections into existence, and nothing in this review should ever modify Bitwarden.

Now resolve who reaches what. For every member, work out the full set of collections they can reach and, for each one, record the path they take to get there: through a group, naming the group, or through a direct grant on their own member record. If both apply, say so, because that overlap is often the sign of a grant nobody cleaned up. Capture the effective permission flags on each path. The grain of the matrix is one row per member and collection pair.

Then use List Events to find who has not touched the vault at all during the quarter. Query the event log across the full quarter date range and page with the continuation token until it comes back null. Collect the distinct acting user ids that appear, and treat any confirmed member who never appears as dormant for that quarter. Event logs need a Teams or Enterprise plan, so if that call is rejected on plan grounds, still produce the full matrix and state plainly in both outputs that dormancy could not be assessed this run.

Flag the exceptions that deserve a human decision, and rank them by severity rather than just listing them. The categories I care about are: owners and admins, because that is standing privileged access; members on custom permissions, remembering that the permissions object only takes effect when the member type is Custom, which makes those the interesting ones; direct collection grants that bypass groups, since those drift outside our normal provisioning path; and dormant accounts still holding a paid seat, including people invited long ago who never accepted. Apply real judgement to severity. A dormant owner matters far more than a dormant read only user, and a direct grant into a sensitive collection matters more than one into a general collection. Member type and status are integer enums that drive most of this logic, so confirm the values against the enum table on the member operation rather than guessing at them.

Write the full access matrix into our compliance workbook with the Google Sheets Append Values operation. Append and never overwrite, because the entire point is a quarter over quarter evidence trail. Stamp every row with the quarter it belongs to and the date the review ran so rows stay attributable long after the fact. If the sheet is empty, write a header row first. Append the values raw so nothing gets reinterpreted as a date or a formula.

Finally, open one Jira Service Management customer request with Create Customer Request that summarizes the exceptions for the quarter. One ticket per review, not one per exception, so the whole review is tracked through to sign off as a single unit of work. Write the summary for a human reviewer rather than as a data dump: lead with the headline counts and the highest severity items, group the exceptions by category, name the specific people and collections involved, and state what decision is being asked for on each one. Link to the workbook so the reviewer can open the full matrix. Create the request even when the exception list comes back empty, because the auditor needs evidence that the review actually ran.