How do I audit what my IT company can access?

Inventory the administrative accounts, remote-access tools, and who can reach email, the database, and backups; get an attributable activity log of what they have done; review and remove unneeded access on a schedule; and confirm a current BAA covers the access. If they cannot produce an inventory and a log, that absence is the finding.

What should an IT activity log show?

Each action - remote sessions, changes, scripts or commands run - tied to a specific person or the agent, timestamped, and reviewable by you. A monthly summary or "trust our memory" is not an audit trail. The ability to see a complete, attributable log is what makes a provider verifiable rather than just trusted.

Why are shared admin accounts a problem?

A generic admin account everyone uses makes actions unattributable - you cannot tell who did what - and it is harder to revoke cleanly when someone leaves. Replace shared accounts with individual ones so every action ties to a person, and remove access for anyone who no longer needs it.

How to audit what your IT company can actually see and do

6 min read · Published 2026-06-29 

auditaccessactivity logvendortransparency

How do you audit what your IT company can see and do?

You audit it by answering two questions with evidence, not assurances: what can they access (which accounts, systems, and remote tools), and what have they done (is there a complete, attributable log of actions). Then you review accounts on a schedule, remove what is not needed, and confirm there is a BAA covering the access. If your provider cannot produce an access inventory and an activity log, that absence is itself the finding.

Step 1: inventory the access

Which administrative accounts exist on your server, workstations, and network gear?
What remote-access tools are installed, and who can use them?
Are any accounts shared (a generic "admin" everyone uses), rather than individual?
Who has access to email, the practice-management database, and the backups?

Shared, always-on, or forgotten accounts are the ones that turn into a breach.

Step 2: get the activity log

Ask for the record of what your provider has actually done - remote sessions, changes, scripts or commands run. A mature setup has an attributable event log: each action tied to a person or the agent, timestamped, and reviewable by you. If the only "log" is the vendor's memory or a monthly summary, you cannot truly audit them. (See what glass-box IT means.)

Step 3: review on a schedule

Remove access for anyone who no longer needs it (former staff, former vendors).
Replace shared accounts with individual ones so actions are attributable.
Confirm remote access is scoped and can be revoked - and that you would see a change.
Re-check after any provider change. (See the transition checklist.)

Step 4: confirm the paperwork

Any vendor with access to systems holding PHI should be covered by a current Business Associate Agreement. Access without a BAA is both a security and a compliance gap. (See what is a BAA?)

What "good" looks like

A practice that can, in a few minutes, show who has access, see a complete log of what was done, and revoke access itself has turned vendor trust into vendor accountability. That is the glass-box standard - and it is the difference between hoping your IT is behaving and being able to verify it. (See is my IT vendor my biggest security risk?)