Designing Role-Based Access Control That Survives Your Next Reorg

A role called "Sarah's access" or even something that sounds more formal but was really built around what one specific engineer needed at the time will outlive its usefulness the moment Sarah changes teams. A role called "backend engineer, billing service" describes a function that persists even as the specific people filling it change.

Write down the actual job functions in your engineering org first, on paper, before touching a permission system: who needs production database access, who needs to deploy, who needs to see customer data, who needs billing system access. The roles fall out of that list much more cleanly than if you start from the tool's permission model.

The instinct to give new hires broad access "so they're not blocked" creates exactly the sprawl that makes an eventual security review painful. Start every new role at the minimum access needed to do the job on day one, and add specific permissions as specific needs come up, rather than starting broad and hoping someone eventually narrows it.

This is uncomfortable at first because it means people occasionally have to ask for something they don't yet have. That friction is small compared to the alternative, which is an access review a year later finding forty people with production database write access when only six actually use it.

When a team is restructured, the question isn't "what new roles do we need," it's "do the existing role definitions still map cleanly onto the new team boundaries." If your roles were built around durable functions rather than the current org chart's specific shape, a reorg mostly means reassigning people to existing roles, not redesigning the whole system.

Treat any reorg as a trigger to review role assignments even if the roles themselves don't change, because people moving between teams is exactly the moment old access quietly gets left behind.

Removing someone from your single sign-on provider does not automatically revoke access to a cloud console they logged into directly, a database with a shared credential, or a third party tool with its own separate account. Every role definition should come with a paired list of exactly which systems grant that role's access, so offboarding is a checklist, not a guess made under time pressure on someone's last day.

This is the same list you'll want during a security audit, so building it as part of role design saves you from reconstructing it from memory later under real time pressure, when the person who could have told you what a departing engineer actually had access to is the one who just left.

Pair every role with a checklist covering these places:

• Your single sign-on provider, which is only the starting point for removing someone.
• Any cloud console the person logged into directly, outside of single sign-on.
• Databases that use a shared credential, which removal from the identity provider does not revoke.
• Third party tools that keep their own separate accounts for the same person.

A team that small often runs on informal access, everyone has broad rights because everyone is trusted and the overhead of formal roles feels excessive for a group where everyone already knows each other. Even here, three roles usually cover it: an engineer role with deploy access and read access to production logs, a lead role that adds database write access and billing system access, and a contractor role with scoped access to a specific service and nothing else.

Three roles is not a burdensome system to maintain, and it's the difference between an offboarding that takes five minutes and one that requires reconstructing what a departing person actually had access to from memory, chat history, and whoever happens to remember granting it.

As the team grows past ten or fifteen people, expect these three roles to split further, a lead role often separates into someone who owns infrastructure decisions and someone who owns people management, and each split is a natural point to revisit whether the underlying permission boundaries still make sense rather than just renaming the existing role.