Role-based access control (RBAC)

Role-based access control, formalised in NIST’s RBAC model, introduces one layer of indirection between people and permissions. Instead of granting access to a person, you define a role, attach permissions to it, and assign people to the role. Adding a person becomes one decision instead of forty, and removing them becomes one decision rather than a search.

The benefit is reviewability. A list of two hundred individual grants cannot be audited by a human. A list of six roles can, which means the question “who can read customer data?” has an answer somebody can actually give.

Two things go wrong in practice. Role explosion happens when every exception spawns a new role, and the model degrades back into per-person permissions with extra steps. Role creep happens when a role quietly accumulates permissions because adding one was easier than arguing, so the role that everyone holds ends up carrying rights that only one person needed.

Both are treated the same way: review the roles rather than the people, and ask what would break if a permission were removed. In a SaaS product, RBAC usually appears twice, once for your own staff and once as a feature enterprise customers demand for their users.