The login nobody remembers granting
Your bookkeeper stopped doing your books eighteen months ago. She still has admin access to QuickBooks. Your old sales rep left for a competitor last spring, and her Gmail is still tied to the shared drive that holds every signed customer contract you have. This is what a broken data access control setup looks like day to day: nobody granted either of those on purpose, exactly. They just never got taken away, and nobody's checked since.
That's what weak data access control actually looks like in most small and mid-sized businesses. It isn't a hacker breaking in. It's a slow accumulation of logins, shared passwords, and "just give them admin, it's faster" decisions that nobody ever goes back and cleans up. By the time a company has 10 employees and 8 tools, almost nobody in the building could tell you, with confidence, who can see the customer list or edit a live invoice.
Why it happens
Access sprawl isn't a discipline problem. It's a structural one.
Every tool you add (QuickBooks, HubSpot, Google Drive, Airtable, Slack, a shared Dropbox folder for contracts) comes with its own permission model. QuickBooks has roles. Google Workspace has groups and sharing links. HubSpot has permission sets that don't map cleanly to either. None of them talk to each other. So when someone joins the team, whoever onboards them just grants access tool by tool, usually erring toward "give them enough to do their job," which in practice means admin. Figuring out the minimum viable permission level for six different systems takes longer than anyone has.
Nobody owns this. In a 40-person company there's an IT person. In a 12-person company, access decisions get made by whoever's setting up the new hire's laptop that week, and it's rarely written down anywhere. We looked at one client's stack before a recent engagement, a 22-person services firm, and found 47 active user accounts across 11 tools, three of which were shared logins used by more than one person. Nobody could say who had touched the customer database in the last month. Not because they were careless people. Because there was no single place that answered the question.
Why the common fixes fail
The instinct is usually one of two moves, and both fall short.
"We'll just remember to remove access when someone leaves." This depends on one person remembering to go into 8 to 11 different tools, in a moment when they're also handling an exit interview, a final paycheck, and equipment return. It works until it doesn't. And it usually doesn't the one time it matters, like when a departure is contentious.
"Let's buy an enterprise identity tool." Okta, Azure AD Premium, JumpCloud: these are the right answer at 150 employees. At 15, they're a project that gets 60% implemented, costs $8 to $15 per user per month, and gets quietly abandoned when the person who set it up leaves. We've seen this exact pattern twice this year. A real SSO rollout, half-finished, sitting alongside the same shared logins it was supposed to replace.
There's a third failure mode worth naming because it's just as common: locking everything down so hard that the founder becomes the bottleneck for every permission request. That's not access control, that's a queue. People route around it with workarounds, screenshots in Slack, exported CSVs emailed around, which quietly recreates the exact exposure you were trying to close.
The real tradeoff
None of this is really an access-control problem on its own. It's a symptom of not having one place that knows who your people are and what they're allowed to touch. Every fix you consider trades off along the same two axes: how much it costs to set up, and how much it depends on someone remembering to maintain it.
| Approach | Setup cost | Depends on memory? | Fits a 10–50 person company? |
|---|---|---|---|
| Manual per-tool access, no process | None | Completely | Only by accident |
| Shared logins for convenience | None | Somewhat | No — untraceable |
| Full enterprise SSO (Okta, etc.) | High ($$$, weeks) | Low | Usually not yet |
| One identity source + role mapping | Moderate (days) | Low | Yes |
The sweet spot for most SMBs is the last row, and it's less exotic than it sounds. You don't need enterprise SSO to fix this. You need one identity source, usually the Google Workspace or Microsoft 365 account your team already has, and a habit of granting access by role instead of by person, so that removing someone from a group actually removes their reach instead of leaving five orphaned logins behind.
A data access control checklist that actually works
If you want to know where you actually stand, this takes half a day, not a quarter-long project:
- Inventory every tool that touches customer, financial, or employee data. Not just the obvious ones. Check for the Airtable base someone spun up, the shared Dropbox folder, the Zapier connections that move data between systems unattended.
- Pull the current user list from each one. Most tools have an admin panel that shows this in under two minutes. Write down who has owner/admin access versus edit versus view-only.
- Flag anyone who shouldn't be there. Former employees, contractors whose project ended, vendors who needed one-time access. This step alone usually turns up 15–30% of accounts as stale.
- Map access to role, not person. "Sales rep" gets X, "ops manager" gets Y. When someone leaves the role, they lose the access. You're not hunting through a spreadsheet trying to remember what Dave specifically had.
- Tie an offboarding step to your actual HR process, whatever that is, even if it's just a line in the termination checklist that says "remove from Google group, which cascades to connected tools." The trigger has to be an event that already happens, not a task someone has to remember on their own.
- Revisit it quarterly. Fifteen minutes, same day every quarter. Treat it like a fire drill, not a project.
That's the whole system. It's not glamorous. It's also the difference between "we can answer who has access to what in five minutes" and "let me check with a few people and get back to you," which is the answer almost every company gives right now.
Where this touches automation and AI
This is the part people skip, and it's the part that matters most going forward. Every SMB we talk to now wants to add some kind of AI layer, an assistant that can answer "what's our AR aging look like" or "pull me every customer who hasn't ordered in 90 days" by querying across tools. That only works safely once the underlying access is structured, because an AI agent that can query your systems inherits whatever access boundary you give it. If your data access control is a mess of shared logins and forgotten admin rights, you're not adding an AI assistant. You're adding one more account with broad reach and no owner, except this one runs 24/7 and doesn't get an exit interview when the project ends.
Fix the access model first: one identity source, role-based permissions, a real offboarding trigger. Then the AI layer becomes a straightforward decision: what can this agent read, what can it write, and who's accountable for that scope? Skip the fix and you're just automating the exposure you already had.
Where to start
Most companies don't get to this until something forces the issue — a departing employee, a client security questionnaire, an insurance audit that asks who has access to what. You don't have to wait for that. The half-day inventory above will tell you more about your actual risk than any tool you could buy.
If you want a second set of eyes on it, we run a free Process Teardown: a 30-minute session where we map one of your workflows, access included if that's the one keeping you up, and show you where it's quietly costing hours or exposing more than it should. No pitch, no obligation. It's the same kind of work we did for the clients in our case studies, where the fix wasn't a new tool, it was finally connecting the ones already in use.
0 Comment