The most common security breach in mid-size companies isn't caused by a hacker. It's caused by an employee with too many permissions.
Cybersecurity

The most common security breach in mid-size companies isn't caused by a hacker. It's caused by an employee with too many permissions.

When people picture a security incident, they picture an attacker on the outside. A phishing email. A zero-day. Someone clever, somewhere far away, breaking through the perimeter.

The reality, in the kind of companies we audit every week, is much more boring. The most common breach is caused by an internal user with more access than they ever needed.

The principle is simple. The practice never is.

Least privilege says one thing: each person should have access only to what they need to do their job. Not more, not less.

It's repeated in every security framework. NIS2, ISO 27001, ENS, CIS Controls. Everybody nods at it. Almost nobody enforces it.

What we actually find when we audit:

  • The sales rep who can query the entire customer database — including invoices and contracts from customers they've never worked with.
  • The senior technician who has admin access to production "just in case" since 2021.
  • The intern using shared credentials that have rotated through the team since 2019.
  • The ex-employee whose account is still active months after they left.
  • The service account with full read/write on a database that hasn't been used since the last migration.

Nobody configured it that way out of malice. Nobody reviewed it either.

It's not about who gets in. It's about what happens after.

When an incident does occur — phishing, credential leak, compromised laptop, ransom — the question that determines the size of the impact isn't "how did they get in?". It's "what could they do once inside?".

An attacker who lands in a properly segmented environment hits a wall. An attacker who lands in an over-permissioned environment finds a highway.

The same compromised credential in two different companies produces two completely different stories — and two completely different remediation bills — depending on what that user was actually allowed to touch.

The question to ask yourself today

Don't think about it as a theoretical exercise. Think about it as a fire drill.

Do you know exactly what each user can do inside your systems?

If the answer takes more than a few seconds, you already have your next audit pending.

What "good" looks like

  • Role-based access mapped to job function — not "copy permissions from X" when somebody joins.
  • Quarterly access reviews with explicit sign-off from the data owner, not just IT.
  • Offboarding tied to HR — accounts disabled the same day the contract ends, automatically.
  • Privileged access separated — admins use a different account for admin tasks than for daily email and Teams.
  • Service accounts treated like people — owned, documented, rotated.

Where we come in

At AP Interactive we audit identity and access management as part of our security reviews — covering Active Directory, cloud IAM, application-level permissions and service accounts. We don't sell you a tool: we tell you exactly where the gaps are and what the cleanup plan looks like.

If you've never run a permissions audit, or if the last one was more than a year ago, get in touch. The first finding is usually surprising. The first ten are usually obvious in hindsight.