Access Control Basics: Principle of Least Privilege in Practice

Most breaches don't happen because an attacker found a zero-day vulnerability in your software. They happen because someone's credentials were compromised — and those credentials had access to more than they needed. The principle of least privilege is the direct countermeasure: give every user, system, and process the minimum level of access required to do their job, and nothing more.

It sounds obvious. In practice, most growing businesses look nothing like this. Admin rights get handed out liberally because it's faster than figuring out the exact permissions required. Employees accumulate access over time as their role evolves. Contractors get temporary access that never gets revoked. The result is a sprawling, poorly understood access landscape where a single compromised account can do enormous damage.

What Least Privilege Means (and Why Most Teams Ignore It)

Least privilege means calibrating access precisely to what's necessary for a specific role or task, at the specific time it's needed. An accountant doesn't need access to production databases. A developer doesn't need access to payroll. A contractor doesn't need access to the full company Google Drive.

The reason teams ignore this isn't malice — it's friction. Figuring out exactly what someone needs, granting those specific permissions, and adjusting them over time is slower than giving admin access and moving on. The cost of getting it wrong isn't felt immediately; it only becomes visible after an incident. And by then, the cause is buried in the complexity of whatever grew up in the meantime.

This is a classic case of short-term convenience creating long-term risk.

The Cost of Over-Privileged Access

When access controls are loose, a single compromised account can become the entry point for a catastrophic breach. Consider a few scenarios:

A phishing email tricks a developer into providing their credentials. Because the developer has admin rights on your AWS account (because that was easier to set up), the attacker can now create new users, exfiltrate data, deploy ransomware, or run up a massive infrastructure bill before anyone notices.

A former employee's account isn't fully deprovisioned. They still have read access to the company's Google Drive. Months later, they download a folder of customer data. You don't find out until a client reports a suspicious contact.

A third-party integration that was set up two years ago has administrator-level API access to your CRM. The third-party vendor is acquired, suffers a breach, and now an attacker has full access to your customer database.

In each case, least privilege would have contained the damage significantly.

Mapping Your Access Landscape

Before you can apply least privilege, you need to understand what access actually exists. This is often the most uncomfortable step because it reveals how far from ideal the current state is.

Start by listing all systems and services your organisation uses — cloud platforms, SaaS tools, internal systems, databases, code repositories. For each, identify who has access and at what permission level. Most SaaS tools have an admin area that shows this. Cloud platforms have IAM consoles.

You're looking for:

• Admin or owner-level accounts — who has them, and do they genuinely need that level?
• Dormant accounts — former employees, contractors, or test accounts that haven't been used recently
• Overly broad permissions — engineers with access to finance systems, marketing with access to production databases
• Service accounts and integrations — API keys and integration accounts that may have excessive permissions

This inventory becomes the baseline from which you work.

Applying Least Privilege to SaaS Tools

For most growing businesses, SaaS tools are where the most access exists and where controls are most often neglected.

Work through your key tools and ask: what's the minimum role that allows this person to do their job? Most SaaS platforms have multiple permission tiers — viewer, editor, admin, owner. A surprising number of people end up as admins when they only needed editor access.

Key actions:

• Remove admin rights from anyone who doesn't genuinely need them for day-to-day work
• Demote owners and admins to lower permission tiers where the role allows
• Audit any role that gives access to billing, user management, or data export — these are particularly sensitive
• Remove accounts for anyone no longer with the organisation

If your team is small enough, this can be done manually in an afternoon. For larger teams or more complex access landscapes, consider a SaaS management platform that centralises visibility.

Applying Least Privilege to Cloud Infrastructure

Cloud platforms — AWS, Google Cloud, Azure — make least privilege both more important and more complex. The blast radius of a compromised cloud account is potentially enormous: data exfiltration, infrastructure manipulation, cost fraud, ransomware deployment.

Use the IAM features native to your cloud platform to create specific roles with defined permissions rather than granting broad admin access. For specific tasks, use time-limited, just-in-time access rather than persistent elevated permissions.

Practical steps:

• Protect the root or owner account. This should have MFA enabled, not be used for day-to-day operations, and ideally not be associated with a personal email address.
• Create service-specific roles. An application that reads from a database should have read-only access to that database, not full database admin rights.
• Use IAM policies, not individual permissions. Policies are easier to audit, modify, and apply consistently across similar roles.
• Audit API keys regularly. Unused keys should be deleted. Active keys should have the minimum permissions needed.

Access Reviews: Making It a Habit

Access tends to accumulate over time as roles evolve, projects change, and people come and go. A single access review, however thorough, becomes outdated quickly. The goal is to make access reviews a regular practice.

A quarterly access review doesn't need to be comprehensive every time. A practical approach is to rotate focus: this quarter, review cloud IAM; next quarter, SaaS tools; the quarter after, code repositories. By the time you've cycled through everything, three to four months haven't passed since the last review of any given system.

Build offboarding and onboarding checklists that include access. When someone joins, define their access explicitly from the start. When someone leaves, have a clear revocation checklist that covers all systems — including the ones that don't obviously come to mind, like Slack, GitHub, or the company password manager.

Conclusion

Least privilege isn't a one-time task. It's a posture that needs to be designed into your processes from the start and maintained through regular review. The initial effort to map your access landscape and reduce permissions to what's actually needed will take several hours — but it's hours that could prevent a breach that costs weeks of recovery time, significant money, and lasting reputational damage.

Start with the highest-risk access: admin accounts, cloud infrastructure, financial systems. Work down from there. And build the habit of reviewing access every time someone joins, changes role, or leaves. The discipline compounds over time.