Agency Access Reviews: Check Who Can See Each Client File

An agency access review starts with the work people actually perform. A staff member who schedules an appointment may need different information from a reviewer preparing a factual dispute. Write down those responsibilities before choosing role names. Labels such as administrator or assistant are useful only when their permissions have a clear meaning.

Build a matrix with roles on one side and actions on the other. Include viewing a client, editing contact information, opening a document, exporting records, approving a draft and managing other users. Record whether each role should be allowed, denied or conditionally allowed. Have the responsible agency owner review the proposed matrix.

The FTC recommends limiting access to sensitive information according to business need. Turn that principle into observable checks rather than assuming a role label enforces it. The matrix is your expected result. The configured software's behavior is the observed result. Any difference needs a documented decision before the agency relies on that permission for real client work.

Create controlled test users representing the roles you intend to use. Give them fictional clients and documents. Sign in separately as each user instead of changing a label while remaining in an administrator's session. An existing privileged session can conceal the restrictions a regular staff member encounters.

For each action, record the expected result, observed result and relevant test reference. Check both the visible interface and the result of normal supported navigation. A hidden button alone does not prove that the underlying action is restricted. Ask your technical owner to validate server-side enforcement through an authorized testing process where needed.

Include at least one user who belongs to a different fictional agency or workspace. That account should not gain access merely because it knows a client reference or receives a copied link. Do not test against unrelated real accounts. The purpose is to verify your own permitted boundaries with controlled fixtures and resolve unexpected access before sensitive records are introduced.

A permission review that checks only the client summary misses several common data paths. List document previews, downloaded files, exported spreadsheets, printable packets and any sharing features your configuration actually supports. Determine which role needs each path and why.

Review how an exported file is protected after download. Removing application access does not retrieve a copy already saved elsewhere. Set an agency procedure for permitted storage, sharing and disposal of those copies. Avoid copying sensitive information into general project tools simply because those tools are convenient for task assignment.

Test a fictional attachment link after changing the user's role and after signing out. Record whether access depends on authentication, a time-limited link or another documented mechanism. Different mechanisms require different handling procedures. An unexpected result is a reason to investigate the configuration, not to improvise a workaround that broadens access. Keep the test notes useful without embedding real document contents or live access secrets in the notes themselves.

Use a synthetic employee who moves from intake to review. Begin with the intake role, record the allowed actions, then apply the approved role change. Reopen the session through the supported flow and verify that the new permissions match the matrix. Check whether old sessions retain privileges and ask the technical owner to resolve any uncertainty about session invalidation.

Next, rehearse a departure. Remove the test user's access through the normal account-management process. Confirm the expected result for a new sign-in attempt and an already open session. Review any separate shared mailbox, document service or vendor access that would exist in your real operating environment.

The exercise should produce a checklist with owners, rather than a vague instruction to “deactivate the user.” Specify who handles each connected system and how completion is recorded. Preserve necessary business records under the agency's retention procedure; an employee departure does not automatically mean their work history should disappear. This is a proposed operational rehearsal, not a claim about every platform's session behavior.

Repeat the review when responsibilities, vendors or sensitive workflows change. A regular calendar review is useful, but it should not be the only trigger. A new bulk export, contractor role or document-sharing feature can alter the exposure before the next scheduled review arrives.

Keep a concise exception register. Each exception needs the affected role, business reason, approving owner, compensating procedure and review date. Temporary access without an end condition tends to become permanent by accident. Avoid treating an exception as approved simply because it has appeared in several previous reports.

For a small agency, the most useful first result may be a short list of accounts that no longer need access and a clearer separation between preparation and approval. Record what was verified, what remains uncertain and who will resolve it. Do not claim that an access review establishes complete security or legal compliance. It tests defined permissions at a particular time and gives the agency a concrete basis for correcting observed gaps.