# Quarterly Bitwarden access review pack for SOC 2 audits

> Every quarter, map who can reach which password collections, flag the accounts worth a second look, and log it all as audit evidence.

- Workflow type: agent
- Services: Bitwarden, Google Sheets, Jira Service Management
- Categories: Operations
- Published: 2026-08-04

## What it does

- Builds a complete picture of who has access to which password collections, and whether that access comes through a group or was granted to someone directly.
- Highlights the accounts a reviewer should actually spend time on: owners and admins, people on custom permissions, one off direct grants, and accounts that never touched the vault all quarter.
- Adds the full access list to your compliance spreadsheet as a new block each quarter, so you build an evidence trail over time instead of overwriting last quarter's work.
- Opens a service desk ticket summarizing the exceptions, so the review gets assigned, worked, and signed off rather than sitting in someone's inbox.

## What you'll need

- A Bitwarden organization on a Teams or Enterprise plan, since the activity history this review relies on is only available on those plans.
- An organization owner to set up the Bitwarden connection, because only owners can access the credentials.
- A Google account and a spreadsheet you want to use as your compliance workbook.
- A Jira Service Management project where the quarterly review ticket should be raised.

## Prompt

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.

## How to customize

- Change the schedule if your audit cycle runs monthly or twice a year instead of quarterly.
- Adjust what counts as an exception, for example flagging dormant accounts after 30 days instead of a full quarter, or treating direct grants as acceptable in some collections.
- Point the ticket at a different service desk or request type, and set who it goes to for sign off.

## Example output

Q3 2026 Bitwarden access review: 47 members, 12 collections, 9 exceptions to review.

High priority
1. Dormant owner. j.reyes@acme.com holds Owner and had no vault activity for the entire quarter. Full privilege plus zero usage is the combination worth acting on first.
2. Direct grant into Finance Secrets. m.okafor@acme.com reaches this collection through a grant made straight to their account rather than through the Finance group, which puts it outside our normal provisioning path.

Medium priority
3. Custom permissions. Two members sit on custom permission sets rather than a standard role. Confirm each still needs the elevated rights.
4. Standing admin access. Four accounts hold Owner or Admin. All were active this quarter, so this is a confirm and move on item.

Low priority
5. Three dormant read only users still consuming seats. No access risk, but roughly 3 seats of spend to reclaim.

Full matrix appended to the compliance workbook, Access Review tab, 214 new rows.

## FAQ

### Does this change anything in my password vault?

No. The review only reads your organization structure and activity history. It never adds, removes, or edits members, groups, or collections, so it is safe to run against a live vault.

### Do I need a paid Bitwarden plan?

Yes, a Teams or Enterprise plan. The dormant account check depends on your organization's activity history, which those plans include. If your plan does not have it, the review still produces the full access matrix and simply notes that dormancy could not be assessed.

### Will it overwrite last quarter's review in my spreadsheet?

No. Each run adds new rows below the existing ones and stamps them with the quarter they belong to. That is deliberate, because auditors want to see the review happening consistently over time, not just the most recent snapshot.

### What happens if there are no exceptions that quarter?

It still records the full access matrix and still opens the ticket. A clean review is itself evidence that the control ran, which is exactly what an auditor is looking for.

### Can I use this for audits other than SOC 2?

Yes. User access reviews are a common control across ISO 27001, HIPAA, and most customer security questionnaires. The same evidence pack generally satisfies all of them.

Use this prompt in General Input: https://www.generalinput.com/prompts/quarterly-bitwarden-access-review-pack-for-soc-2-audits