Setting Up Role-Based Access Control (RBAC) in Enterprise Shared Drives
I inherited a shared drive structure with over four hundred folders, a permissions scheme that had accreted over nine years with no consistent logic, and an access audit that our new compliance officer requested within her first month on the job that we simply could not produce accurately. Rebuilding this into a proper RBAC model took about five months of actual work, spread across a year because we had to do it without disrupting daily operations for six hundred employees. Here's what actually mattered.
Audit Before You Redesign
The instinct when facing a mess like this is to jump straight to designing the ideal future state. I made myself resist that and spent the first three weeks purely on discovery: pulling a full permission export for every folder, cross-referencing it against our HR system to find accounts belonging to people who had left the company two, three, even five years earlier, and documenting every case of permissions granted directly to individual users rather than through a group, since those individual grants were the ones nobody remembered the reason for.
We found sixty three former employee accounts still holding active access to sensitive folders, including three that still had access to the finance drive containing payroll data. That single finding alone justified the entire project to leadership and got me the budget and time I needed to do it properly rather than rushed.
Roles Should Map to Job Functions, Not Departments
My first draft of the RBAC model mapped roles directly to department names, everyone in Finance gets the Finance role, everyone in Marketing gets the Marketing role. This fell apart almost immediately in review because departments contain people with very different access needs. A finance director needs access to strategic planning documents that a finance data entry clerk should never see. Grouping by department either meant over-provisioning the clerk or under-provisioning the director, and neither is acceptable.
I rebuilt the model around job function tiers within each department instead: a base role that everyone in the department gets, and additional roles layered on top for specific responsibilities like budget approval, contract access, or executive reporting. This meant more roles overall, we ended up with around ninety distinct roles instead of the dozen or so a department-based model would have produced, but each role actually meant something specific, which made both provisioning and auditing dramatically easier.
The Group Nesting Trap
Early in the redesign, I nested groups inside other groups to avoid duplicating membership management, a Finance-All group that contained the Finance-Directors and Finance-Analysts subgroups, for instance. This seemed efficient until I tried to run a permission audit and discovered that our directory service's reporting tools didn't cleanly flatten nested group membership into a simple "who has access to what" answer. Answering the compliance officer's basic question, "who can access the vendor contracts folder," required manually tracing through three levels of group nesting for some folders.
I flattened the structure after that, accepting some duplication in group membership management in exchange for every folder's access being answerable with a single, flat group lookup. Nested groups are elegant in theory and painful in practice when someone with a compliance deadline needs a straight answer fast.
Handling the Exceptions Without Breaking the Model
No matter how well designed the role structure is, there will be legitimate one-off access needs, a project that spans two departments, a temporary contractor who needs narrow access to one specific folder, a legal hold that requires read access for an external auditor. I built a formal exception process rather than letting these creep back in as ad hoc individual grants: any access outside the standard role model requires a documented business justification, an expiration date, and manager sign-off, logged in a tracking sheet that gets reviewed quarterly.
The expiration date turned out to be the most important part. Before this process existed, temporary access requests never actually expired, they just accumulated, which is exactly how we ended up with the original mess. Now every exception has a built-in prompt to either renew with justification or revoke.
Quarterly Access Reviews Are Non-Negotiable
Even a well designed RBAC model degrades over time as people change roles, get promoted, or move between departments without their old access being revoked. We now run a quarterly review where each department head gets a report of everyone with access to their folders and has to actively confirm or flag each person, rather than a passive "let us know if something's wrong" email that nobody reads. Making the review an active confirmation task rather than a passive notification increased actual engagement from department heads by a wide margin, we went from maybe 20 percent response rate on passive emails to essentially 100 percent on the active confirmation workflow, because it's built into a system that tracks completion and escalates to their manager if it's not done within two weeks.
What I'd Do Differently Starting Over
I'd build the exception tracking and quarterly review process before finishing the initial role rollout, not after. We treated those as phase two work and spent about four months with the new clean role structure slowly accumulating the same kind of undocumented individual grants that caused the original mess, before the review process caught up and started enforcing discipline. The technical design of an RBAC model is honestly the easier half of the problem. The ongoing governance is what determines whether it stays clean five years from now or ends up right back where we started.
