Data Access Permissions: Why the Wrong People See Everything

The intern can see payroll. Nobody decided that.

Your bookkeeper left four months ago. Her Gmail is deactivated, but her login to the shared QuickBooks account still works, because nobody rotated the password. Meanwhile the sales rep you hired in March can open the same Google Sheet where finance tracks commission payouts and everyone's base salary, because that sheet also happens to have the deal pipeline tab he actually needs. Nobody designed those data access permissions on purpose. He's not looking. But he could, and one day someone will.

This is what bad data access permissions look like at a 15-to-80 person company. Not a hack, not a breach. Just a slow accumulation of "sure, give them edit access, it's easier" decisions that nobody ever revisits. By the time you notice, half your team can see or change data they have no business touching, and you have no clean way to say who's allowed to do what.

Why it happens

Nobody sets out to build this mess. Access control isn't a project. It's a side effect of every other decision you make while growing fast.

You start with one spreadsheet because it's free and everyone already has Google Workspace. Then someone needs to see it who shouldn't really see all of it, so instead of building a view, you just add them as an editor. It's Tuesday, you have four other fires, and "give Sarah edit access" takes ten seconds while designing a proper permission structure takes an afternoon you don't have.

Then you add tools. A CRM. A shared Slack workspace with forty channels. QuickBooks. Maybe Notion for internal docs. Each one ships with a default setting of "everyone in the workspace can see everything," because that's the setting that gets you to first value fastest. Vendors design onboarding to remove friction, not to enforce boundaries, because friction is the enemy of activation. So the boundaries never get set, and three tools later you've got customer PII sitting next to HR notes sitting next to a "confidential" folder that isn't.

The other driver is turnover. People join, get access to whatever they need for the current project, and when the project ends, nobody remembers to remove it. Offboarding usually catches the big stuff, email and Slack, but a contractor's access to the shared Airtable base or a departed employee's API key for your billing system quietly survives. We've seen SMBs with active logins for people who left over a year ago. Nobody was being careless on purpose. Nobody owned it.

Why the obvious fixes don't hold

There are two instinctive responses once someone notices the problem, and both fail in predictable ways.

Lock it down hard. Appoint one person (usually whoever's most anxious about it, often the founder or ops lead) as the sole gatekeeper for every access request. Every new hire, every new tool, every permission change routes through them. This feels responsible. In practice it turns one person into a queue. Requests pile up, people get impatient, and they start working around the gatekeeper: exporting a CSV and emailing it, screen-sharing sensitive data on a Zoom call, keeping a personal copy of "the numbers" in their own Drive. You've traded uncontrolled access for uncontrolled copies, which is arguably worse because now you've lost track of where the data even lives.

Write a policy nobody follows. The other move is a permissions policy document: who's allowed to see what, per role, with a nice table. It goes in the handbook. It gets referenced once during onboarding and never again. Six months later nobody remembers it exists, new tools get added without anyone checking it, and the actual access in your systems has drifted completely away from what the document says. A policy that lives in a doc instead of in the tools themselves isn't a control. It's a liability, because now you can point to a document claiming you have a process, and an auditor or a client's security team will ask you to prove the systems actually match it. They won't.

Both failures come from the same root cause: permissions were never wired into your actual systems. They were bolted on as a process, and processes decay the moment nobody's watching.

The tradeoffs, laid out plainly

There's no version of this that's free. Here's the honest tradeoff table.

• Role-based access in one connected system: moderate setup cost, low ongoing cost. You define access by job function (AE, ops manager, finance, contractor) once, and every new hire or departure just gets added to or removed from a role. The tradeoff is upfront time: you have to actually map who needs what, which takes a few hours of uncomfortable conversation about who's been over-permissioned.
• Single gatekeeper approval model: near-zero setup cost, high ongoing cost. Fast to start, but it doesn't scale past a handful of people and creates a bottleneck plus workaround behavior, as above.
• Enterprise IAM tooling (Okta, full SSO with granular policies): high setup cost, low ongoing cost once live, but usually overkill under 50-100 employees and a handful of tools. You'll spend more time configuring it than you save.
• Do nothing, review access "when we get to it": zero cost until the day it isn't. This is the default most SMBs are on, and it's the one that shows up as a stalled deal when an enterprise prospect's security questionnaire asks how you manage least-privilege access and you don't have an answer.

For most companies in the 10-150 employee range, the first option is the right trade. It costs you a real week of work, not a quarter, and it doesn't require hiring a security engineer.

A practical way to fix data access permissions

Start by treating this as a data mapping exercise, not a tooling purchase.

1. List your data categories, not your tools. Financial data, customer PII, deal/contract terms, HR records, product/engineering credentials. Tools will change; these categories won't.
2. Define roles, not people. Ops manager, AE, finance, engineering, contractor. Every person maps to a role; nobody gets one-off permissions outside that role without a documented exception.
3. For each role, decide read vs. edit vs. admin per data category. Most people need read access to far more than they need edit access to. Most SMBs default everyone to edit because it's the path of least resistance when a spreadsheet is your database.
4. Put the mapping into your actual systems, not a doc. If your CRM, your finance tool, and your project tracker all support role-based permissions (most modern ones do; HubSpot, QuickBooks Online, and Airtable all have some version of this), turn it on and use it. If your source of truth is still a pile of shared spreadsheets, that's your real problem, and permissions are just a symptom of it.
5. Build offboarding into a checklist that runs the same day someone leaves, not a mental note. Revoke access to every system, rotate any shared credentials they touched, and confirm it, in writing, within 24 hours.
6. Review the whole mapping quarterly. Not because it needs an overhaul every time, but because roles drift. Someone picks up a project outside their lane and quietly keeps the access after the project ends.

This isn't glamorous work. It's also the difference between passing a security questionnaire in two days and losing a deal because you couldn't answer basic questions about who can touch customer data.

Where AI fits, and where it doesn't

People get this part backwards. An AI assistant that can query your CRM, your finance data, and your support tickets sounds great, until you realize it inherits whatever access the account it's running under has. If that account can see payroll because nobody scoped it properly, your AI summary tool can now surface salary numbers in a report meant for the whole sales team. The AI didn't create the problem. It just executed the broken permission model faster and with less judgment than a human would have used.

AI is genuinely useful once your data lives in one connected system with real role-based boundaries — it can draft a weekly ops summary scoped to what a manager should see, flag anomalous access patterns, or answer "who touched this record" instantly instead of someone digging through exports. None of that works safely on top of a shared spreadsheet where everyone has edit access to everything. Fix the access model first. The automation layer on top of it is the easy part.

If you're not sure where you stand

Most founders we talk to haven't looked at this directly. They know it's probably messy, but nobody's had the time to map it out. If you want a second set of eyes, we run a free 30-minute Process Teardown where we map one of your actual workflows, including who can touch what data along the way, and show you where it's quietly costing you hours or risk. No pitch, just the map. You can also look at how we've connected disconnected systems for other teams before deciding if it's worth the conversation.