Why employees often have more access than they need

Somewhere in your company there's probably a warehouse employee who can still open the finance module. A former project manager, now in sales, who can still edit HR records. An intern from two summers ago whose login still works. Nobody granted this access maliciously — it just never got taken away.

This is called permission creep, and it's one of the most common — and most overlooked — security gaps in business-critical software. This article explains why it happens, how to find it in your own systems, and what a practical, non-disruptive fix looks like.

What does "more access than needed" actually look like in practice?

It's rarely dramatic. It looks like:

• A customer service rep who can still see full salary data in the HR module, because HR and CRM were bolted onto the same FileMaker file years ago and nobody split the permission sets afterward.
• A sales manager who moved to marketing 18 months ago but can still approve purchase orders in the ERP system, because the request to remove that role got lost in an email thread.
• An external contractor who built an API connector between the webshop and the accounting system, and still has an active admin login six months after the project ended.
• Every user in the company sharing one generic "Admin" login because it was the fastest way to get a new hire working on day one — meaning nobody can actually tell who did what.

None of these people are doing anything wrong. But each one is a door that shouldn't be open, and every open door is a chance for a mistake, a breach, or — in the case of a disgruntled departure — deliberate misuse.

Why does this keep happening, even in well-run companies?

There are a few very ordinary reasons, and they compound over time:

1. Access is granted fast, but revoked slowly. Onboarding a new employee is urgent — they need to work today. Removing access when someone changes roles or leaves is administrative housekeeping, and housekeeping gets postponed.
2. Roles change, permissions don't. People get promoted, move departments, or take on temporary projects. The system was never built to automatically adjust for that.
3. "Just give them admin" is the path of least resistance. When a custom FileMaker solution or ERP system was built years ago, permission sets were often kept broad on purpose, because building granular, role-based access takes real design time that nobody budgeted for.
4. Nobody owns the review. IT assumes HR will flag departures. HR assumes the system owner reviews access. In reality, nobody has an actual recurring task called "review who can access what."
5. The system has grown organically. A FileMaker solution that started as a simple order-tracking tool ten years ago now touches invoicing, HR, and supplier data — but the original three users still have the original wide-open permissions, and every new module inherited the same broad access by default.

Why is this a real risk, not just a tidiness issue?

Over-permissioned accounts are one of the most common root causes behind:

• Accidental data damage. An employee with unnecessary edit rights deletes or overwrites records they didn't realize they could touch — a warehouse staffer who accidentally bulk-edits pricing because the field wasn't locked down for their role.
• Data leaks. Wide access means more people can export a full customer list, salary overview, or supplier pricing sheet — accidentally on a USB stick, or deliberately on the way out the door.
• Compliance exposure. GDPR and similar regulations expect you to apply the principle of least privilege — giving people access only to what their role requires. An audit that finds twelve people with unrestricted access to personal data is a real finding, not a technicality.
• Slower incident response. If something goes wrong — a record is changed incorrectly, data goes missing — and ten people technically had the rights to do it, tracing what actually happened takes far longer than if only two people could have.

[[IMAGE:left|padlock icon next to a long list of user accounts, several highlighted red]]

How do you find out who has too much access right now?

You don't need a big security project to start. A practical first pass looks like this:

1. Pull a full user list from every business-critical system — your FileMaker solution, ERP, accounting software, and any connected web apps. Include shared or generic logins.
2. Match each account to a real, currently active role. Cross-check against your HR list of current employees and their actual departments.
3. Flag anything that doesn't match, for example: accounts for people who left, accounts for people whose role changed, accounts with admin rights nobody can explain, and shared/generic logins used by more than one person.
4. Check module-level access, not just login access. Someone might correctly need to log in to the ERP, but not need access to the finance or HR modules within it.
5. Ask the uncomfortable question for each admin account: "Why does this specific person need full access, today, for their current job?" If nobody in the room can answer it in one sentence, that's a candidate for reduction.

This exercise alone, done once a quarter, catches the majority of permission creep before it becomes a real incident.

What does "least privilege" actually mean for a custom system like FileMaker?

The principle of least privilege simply means: every user gets exactly the access their current role requires — no more, no less. In a custom-built FileMaker solution, this is done through privilege sets: named permission groups (e.g. "Warehouse," "Sales," "Finance," "Read-only Reporting") that define, layout by layout and field by field, what a user can view, create, edit, or delete.

Done well, this looks like:

• A warehouse employee can view and update stock counts, but cannot see purchase prices or margins.
• A sales rep can see customer order history, but cannot edit invoices that finance has already closed.
• A finance user can see everything related to invoicing and payments, but not HR salary records, even if both live in the same underlying system.
• Anyone leaving a role has their privilege set changed — not just their password — on their last working day, as a standard offboarding step, not an afterthought.

Done poorly — which is common in older, organically-grown FileMaker files — everyone gets close to full access because separating it out later feels like too much rework.

How do you fix over-access without breaking people's daily workflow?

This is the part companies worry about most: "if we tighten permissions, will people suddenly be locked out of things they actually need?" A few practical steps reduce that risk:

• Start with the highest-risk accounts first — generic/shared logins, former employees, and unrestricted admin accounts. These are the easiest to justify fixing and carry the least workflow disruption.
• Build role-based privilege sets, not person-based ones. Define "what does a Sales Rep need" once, then assign every current and future sales rep to that role. This also makes onboarding faster, not slower.
• Roll out changes in a test/staging copy first if the system is heavily used, so you can confirm nothing breaks before applying it live.
• Communicate the change, briefly: "We're tightening system access to match current roles — if something you need stops working, tell us and we'll adjust it." This turns a security fix into a two-way conversation instead of a surprise.
• Make offboarding a checklist item, not a memory. The moment someone's role changes or they leave, revoking/adjusting system access should be as automatic as disabling their email account.

How often should access actually be reviewed?

As a practical rule:

• Immediately when someone joins, changes role, or leaves.
• Quarterly, do a full review of all admin-level and financially sensitive access.
• Annually, review every privilege set from scratch — not just who's assigned to it, but whether the role definition itself still makes sense as the system has grown.

FAQ

Does this apply to small companies too, or only large ones with big IT teams? It applies more to small and mid-sized companies, if anything — they're the ones most likely to be running one shared "Admin" login for everyone because a dedicated IT security review was never budgeted.

Isn't restricting access going to slow my team down? Properly designed role-based access is usually invisible in daily use — most employees only ever touch the parts of the system relevant to their job anyway. The friction only appears when access was undefined to begin with and people got used to seeing everything.

We built our FileMaker system ourselves years ago and don't fully remember how permissions are structured. Where do we start? Start with the user list and role-matching exercise above — it doesn't require deep technical knowledge of the file's internals, just an honest cross-check against who currently works where.

Can AI tools help manage this? Used carefully, yes — an AI assistant integrated into a system like FileMaker can help flag unusual access patterns (e.g. a rarely-used account suddenly exporting large amounts of data) faster than a manual quarterly review would catch it. It doesn't replace the underlying privilege set design, but it adds an extra layer of ongoing monitoring.

Checklist: is your system at risk of permission creep?

• We can list every active user across our core systems today, without pulling records first.
• No two people share a single login.
• Removing system access is a mandatory step in our offboarding process.
• Privilege sets are based on roles, not built individually per person.
• We've reviewed admin-level access in the last three months.
• We know exactly why every admin account needs the access it has.

Getting permissions right isn't a one-time project — it's an ongoing part of keeping business-critical software both usable and safe, which is exactly the theme explored in our broader guide on how to secure and maintain business-critical software. If your FileMaker system, ERP, or connected web applications have grown organically over the years and nobody's entirely sure who can access what anymore, that's a solvable problem — whether through redesigning privilege sets in your existing FileMaker solution, tightening the connections between integrated systems, or simply mapping out current access with a short consultancy session before it becomes a bigger risk. Loggix can help you take that first honest look.