Everyone Has Admin Access: How Companies Quietly Break the System They Just Bought

I have never walked into a company where someone decided, on purpose, that seventy people should be able to delete the general ledger.

It happens anyway.

A few years ago I opened the user list at a new client. Roughly seventy NetSuite users. Nearly all of them held administrator access. I felt an actual wave of panic — the kind you feel as a former Controller, when you realize the numbers you are about to rely on could have been altered by anyone in the building, at any time, with no record of who did it or why.

Then I had to explain it to their senior finance leader. I didn’t have to say much. The look on her face said it all.

What “everyone has admin” actually costs you

Nobody grants blanket admin out of malice. It’s the path of least resistance. Someone hits a permissions error at close, they’re annoyed, the fastest fix is to promote them, and nobody ever goes back. Multiply by three years of new hires and you have seventy administrators and no idea how you got there.

At that client, the ERP was tightly integrated with Salesforce. That’s when the exposure stops being theoretical, because the blast radius is no longer one system. One wrong click could corrupt data across both platforms, delete critical records, or scramble financial reporting right before month-end close. Not a hypothetical breach by an outsider. An ordinary Tuesday, an ordinary employee, an ordinary mistake.

There’s a second cost, and it’s the one that shows up on the invoice. Full ERP seats are the most expensive kind, and companies buy them for people who never needed to enter a transaction — sales reps and operations staff who only wanted to look something up. Unused and over-provisioned licenses are not a one-time write-off. They are a recurring line item you keep paying every month for capability nobody is using and nobody should have.

And a third cost, harder to price: a user who logs into an environment with every option turned on is drowning. Give a collections clerk the full administrator interface and you have not empowered her. You have hidden her job inside a menu built for someone else.

What segregation of duties means if you’re not an auditor

Here is the whole idea without the audit vocabulary: no single person should be able to start, approve, and record the same transaction.

The person who creates a new vendor shouldn’t also approve the payment to that vendor. The person who issues a credit memo shouldn’t also be the person who reconciles the account it hits. The person who enters a journal entry shouldn’t be the only person who ever sees it.

That’s it. Segregation of duties is not an accusation that your team is stealing. In my years as an auditor and then as a public company Controller, the overwhelming majority of what these controls catch is error, not fraud. A fat-fingered amount. A posting to the wrong period. A duplicate that would have gone out the door and generated a furious phone call from a customer who just got billed twice.

Separating the steps is how a mistake becomes visible before it becomes a restatement. It is also, not incidentally, the first thing an auditor tests. If you ever intend to raise institutional money, sell, or go public, you will build this. Build it now, when it costs you an afternoon of design instead of a diligence finding.

The access model: what roles should exist, and on what principle

The principle is least privilege — every person gets the narrowest set of rights that lets them do their actual job, and nothing beyond it. Not the rights their title suggests. Not the rights their predecessor happened to have. The rights the work requires.

Here’s how we rebuilt it at that client, and how we’ve done it many times since.

Start by mapping department and function to verbs. For every group of users, answer three questions: what do they need to view, what do they need to edit, and what do they need to create? Do it by function, not by person. When we ran that exercise, the finding was the one I now expect: most users only needed to view information. They didn’t need edit rights at all.

Then apply segregation of duties across the roles you’ve drafted. Sales reps don’t need to edit GL accounts. AR clerks don’t need access to financial statements. Basic stuff — and it wasn’t happening.

Then give people their information in their home system. This is the step most companies skip, and it’s the one that makes the rest stick. We extended the ERP–CRM integration to push key AR and credit limit information into Salesforce, so sales and operations could see what they’d been logging into the ERP to find. Sales and Marketing stayed in Salesforce. Finance worked in the ERP. Nobody lost visibility; they gained it, in the place they already worked.

The cost savings were immediate. Every full ERP login we removed for someone who only needed to look at data came off the recurring bill, and it added up fast.

Then keep exactly two kinds of administrator, and count them. One is the system administrator role that maintains configuration. The other is a documented break-glass account for genuine emergencies. If you cannot name every administrator in your ERP from memory, you have too many.

Then wire access to offboarding. The day someone leaves, their access ends. Not at the next quarterly review. That day.

Your permissions structure should reflect how work actually gets done — not hand out keys to everything because it was easier to set up.

Who is allowed to change the system?

Fixing access solves half the problem. The other half is that in most companies, anyone with rights can change the configuration, and no one has to ask.

Your shiny new system goes live. Congratulations. Now watch someone break it within forty-eight hours.

I’ve seen it more times than I care to count. Months of implementation, a clean go-live, champagne — and then someone in finance tweaks one little thing to make their job easier. Suddenly inventory numbers don’t match. Operations can’t fulfill orders. Your system administrators are putting out fires. Close is miserable, and nobody can say what changed, because nothing was written down.

It also happens at a larger scale, with good intentions. I’ve had a client design an entirely new purchase order approval process internally, without involving us. By the time we saw it, it wasn’t aligned with how the system needed to work. We weren’t optimizing a process anymore. We were undoing one and rebuilding it.

Your ERP is the electrical system of your business. You wouldn’t let just anyone open a wall and start cutting wires. So why would you let them rewire your order-to-cash process on a Thursday afternoon?

What a governance council is and how to run one

This is why governance councils exist — and they are far less bureaucratic than the name suggests.

Who sits on it. Representation from Finance, IT, and Operations: the people who best understand how a change ripples through the system. Concretely, that’s a finance owner who lives with the close, your system administrator, an operations lead who owns fulfillment or service delivery, and whoever owns the integrations between systems. Four to six people. Small enough to actually decide something.

What it approves. Anything that changes how the system behaves for someone other than the requester. New or modified workflows and approval routings. New custom fields and custom records. Changes to the chart of accounts, item setup, or segments. Anything touching an integration. New roles and permission changes. Third-party apps. Data imports above a threshold you set.

What it does not approve. Running a report. Building a personal dashboard. Saved searches that don’t change anyone else’s data. If the council becomes the place where trivial requests go to die, people will route around it, and you’re worse off than before.

How often it meets. On a fixed cadence — biweekly for most growing companies, monthly once you’ve stabilized — with a written request queue and an emergency path for genuine breakage. Every approved change gets a recorded decision, a name attached, and a test before it hits production.

The value isn’t the meeting. It’s the sentence someone says in the meeting: wait, that’s going to mess with our month-end close, or that’ll break the integration we just built. That sentence is worth the hour.

The part everyone forgets: the procedures

The third leak is documentation. You launched with standard operating procedures. Then you changed the configuration eleven times and updated the procedures zero times. Now the SOP describes a system that no longer exists, so the team stops trusting it, and the real process moves back into people’s heads. That’s how tribal knowledge rebuilds itself inside a brand-new system.

I love a good SOP. They preserve quality, accelerate onboarding, and give everyone a baseline. But treating them as scripture is its own failure — if your procedures haven’t changed in two years, you’re not preserving what works, you’re preserving stagnation.

So make the update part of the change, not a project you’ll get to later. A configuration change isn’t done when it’s deployed. It’s done when the procedure that describes it has been rewritten and the affected users have been told.

The ruling

You did not buy a system that degrades on its own. You bought one that degrades because seventy people can change it and nobody has to ask.

Audit your user list this quarter. Rebuild your roles around what the work actually requires. Stand up a council with Finance, IT, and Operations and give it a standing hour. Update the procedure every time you change the system.

None of that requires new software. It requires deciding who is allowed to touch what.

Decide it before your next close decides it for you.