Before a security review, the most useful preparation is often the simplest: check who can access what, and whether that access still makes sense. Over time, teams change, roles shift, contractors finish projects, and permissions accumulate. An audit before a review helps you find stale accounts, overly broad roles, and shared logins while there is still time to fix them calmly.
Start with a complete list of users across the tools in scope. Include active staff, contractors, partners, and any service accounts used for integrations. For each person, note their team, their role, and the level of access they hold. If that information is spread across several systems, gather it into one working list first. An audit built on an incomplete list will miss the very accounts that create the most risk, such as former team members or old test accounts.
Review roles against real work, not job titles alone
Job titles do not always match daily work. A person may hold an admin role from an earlier project, or a manager may have access they no longer use. For each role, ask what tasks the person actually needs to complete, and whether a lower level of access would still allow that work. Apply the idea of least access: give people what they need for their current work, and nothing extra by default. Pay special attention to powerful roles such as admin, billing, data export, and settings control, limiting them to a small, named group and checking whether activity in those roles can be reviewed.
Find stale, duplicate, and shared accounts
Stale accounts are a common audit finding. Look for accounts that have not signed in for a long period, accounts linked to people who have left, and accounts created for a short project that has ended. Confirm each one with a team lead before removing or downgrading access, because an account that looks unused may belong to a seasonal worker or a shared workflow. Also look for duplicates, where one person holds two accounts, and for shared accounts used by several people, which make it impossible to trace activity fairly. Where a shared account is still needed, document who may use it, why it exists, and how its use is monitored.
Document fixes and set a regular review rhythm
An audit is only useful if its results are recorded. Keep a simple log of what was reviewed, what changed, who approved each change, and what remains open. Note any exceptions, with a reason and a review date, rather than leaving them undocumented. Finally, turn the audit into a routine: a short review each quarter, plus a check whenever someone joins, changes teams, or leaves, prevents access from drifting again. Assign one owner for the routine, and keep the checklist where the team can find it. For related guides, see A Trial-to-Paid Onboarding Checklist for B2B SaaS Teams and How to Run a Churn Survey and Actually Act on the Answers.