Blog

The Control Room: Control 5.18 – Access Rights

Written by sallydeiteratecom | Apr 21, 2026 4:49:45 AM

Access is one of those things that feels simple. Until it isn’t.

Someone needs access to a system. You give it to them. They do their job. Everyone moves on. But over time, access builds up. People change roles. Contractors come and go. Permissions get layered on top of each other. And suddenly, no one is quite sure who can access what, or why.

That’s whereISO 27001: Control 5.18: Access Rights comes in.

What the control is really about

At its core, Control 5.18 is about making sure that access to information and systems is granted, reviewed and removed in a controlled way. Not just at the start. Not just when something goes wrong. Continuously.

It requires organisations to:

  • assign access based on role and business need
  • approve access before it is granted
  • review access regularly
  • remove or adjust access when roles change or people leave

In plain English: people should only have access to what they need, and nothing more, for as long as they need it.

Where things usually break down

Most organisations don’t fail this control because they don’t care. They fail because access management is spread across:

  • multiple systems
  • different teams
  • informal processes

…and a lot of “we’ll sort that later”

A few common patterns:

  • Access creep: People accumulate permissions over time. No one removes the old ones.
  • Leaver risk: Accounts aren’t disabled quickly enough when someone leaves.
  • Shared accounts: Credentials get reused because it’s “easier”.
  • No regular reviews: Access is granted once and then never looked at again.

Individually, these seem manageable. Collectively, they create real risk.

Why this control matters more than people think

Access is the gateway to everything else. If someone has access they shouldn’t have:

  • controls can be bypassed
  • data can be exposed or altered
  • audit trails become unreliable
  • incidents become harder to detect and investigate

And importantly, from an audit perspective, it’s one of the first places auditors look. Because it tells them a lot about how disciplined your environment really is.

What “good” looks like in practice

A strong approach to access rights is not complicated. But it is consistent.

  1. Role-based access: Access is tied to roles, not individuals. When someone changes roles, their access changes with it.
  2. Approval before access is granted: No backdoor access. No “just give them admin for now”. Every access request has a clear owner and approval trail.
  3. Regular reviews: Access is reviewed periodically, not just when there’s a problem. This is where most organisations fall short.
  4. Timely removal: When someone leaves or changes roles, access is removed or adjusted quickly. Not next week. Not when someone remembers. Immediately.
  5. Clear visibility: You can answer, without hesitation: “Who has access to this system, and why?” If that question takes more than a few minutes to answer, there’s work to do.

Where tools and systems make the difference

This is one of those controls where manual processes don’t scale well. Spreadsheets, email approvals and ad hoc reviews might work at a small size, but they quickly become unreliable. What makes the biggest difference is:

  • having a central view of systems, assets and owners
  • linking access to roles, responsibilities and users
  • scheduling and tracking access reviews as part of an assurance program
  • capturing evidence of approvals and changes

Because ultimately, this control is not just about doing the right thing. It’s about being able to prove you’re doing it.

The real shift

Control 5.18 is not about locking everything down. It’s about moving from reactive access decisions, fragmented processes and unclear ownership to something that is structure, visible and repeatable.

When done well, access management becomes part of business as usual. Not something you scramble to fix before an audit.

Most organisations don’t have a single catastrophic access failure. They have a slow drift into over-permissioned systems and unclear ownership. Control 5.18 exists to stop that drift. Not with complexity. But with consistency.

And like most good controls, it works best when it’s part of a system, not a standalone activity.