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?".

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.

Frequently asked questions

What is the principle of least privilege?

It means each person should have access only to what they need to do their job — not more, not less. It's a requirement in every major security framework, including NIS2, ISO 27001, the Spanish ENS and CIS Controls. In practice, most companies configure access broadly by default and rarely review it afterwards.

Why does over-permissioning matter more than how an attacker gets in?

When an incident happens — phishing, a leaked credential, a compromised laptop — the size of the damage depends on what that account could reach, not on how the attacker got in. The same compromised credential produces very different outcomes in a properly segmented environment versus an over-permissioned one.

What does a good access control setup actually look like?

Role-based access mapped to actual job function rather than copied from a colleague, quarterly access reviews signed off by the data owner (not just IT), offboarding tied automatically to HR so accounts are disabled the same day a contract ends, separate accounts for privileged and daily tasks, and service accounts that are owned, documented and rotated like any other identity.