A three-tier AD group structure for new starter permissions is the right conceptual foundation. Core permissions that everyone gets, department-based groups for shared resources and distribution lists, job role groups that define what each role actually needs. Clean, logical, auditable.

The challenge is not designing the model. It is maintaining it. A 20-year-old AD mess did not happen because nobody understood RBAC. It happened because every exception, every urgent one-off, every "just add them to this group for now" created a deviation from the intended model that was never cleaned up. The question for any rationalization project is not just how to get to a clean state, but what mechanism prevents the same drift from accumulating over the next 20 years.

The Three-Tier Model: What It Gets Right

The structure proposed in the Reddit thread reflects sound RBAC thinking.

Core permissions define what every employee needs regardless of role: access to email, shared drives, basic productivity tools, the intranet. Putting this in a single group means a new starter gets baseline access the moment they are added to the group, without anyone having to think about it.

Department groups handle shared resources within a team: shared mailboxes, department-specific file shares, distribution lists. They also provide a clean place to scope access that is departmental rather than role-specific.

Job role groups define the specific access profile for each function: which applications, which file shares, which permission levels. A Sales Representative role group grants Salesforce access at the standard rep level, read access to the pricing drive, and whatever else every Sales Representative needs. This is the birthright access definition for that role.

The key discipline that holds the model together is the question the OP identified: when a user needs something outside the standard role, does this belong on the role (meaning every future person in this role should have it) or on the user (meaning this is specific to this person's situation)?

If the answer is role, update the role definition and document the change. If the answer is user, grant it as a time-bound exception and track it separately. Doing the opposite in either case is how the mess accumulates.

Why a SharePoint Document Is Not the Right Governance Layer

The SharePoint version history approach addresses the audit requirement, but it has structural weaknesses that become more visible at scale.

The document is descriptive, not prescriptive. It records what roles should have, but it does not enforce that the actual AD groups match the document. The document says the Sales Representative role should have Salesforce access. But whether a specific new hire actually got that access, whether the group membership was correct when they were onboarded, and whether their access was removed correctly when they left are questions the document cannot answer.

Auditors increasingly expect system-generated evidence rather than documents that someone maintained manually. A log that shows "user X was added to role group Y at timestamp Z by administrator A as part of onboarding playbook B" is stronger audit evidence than a SharePoint document that shows the role definitions were updated three months ago.

The third problem is that the SharePoint document is a separate system from the actual provisioning. Someone reads the document, manually applies the groups, and the connection between intent and execution is a human action with no verification that the two match.

The Automation Layer That Prevents Future Drift

The mechanism that prevents a clean AD setup from degrading back into a mess is automated provisioning tied to an authoritative source of truth.

The source of truth should be the HR system: who the person is, what department they are in, what their job title is, and when their employment status changes. When a new hire record appears in the HR system with the role "Sales Representative" in the "Sales" department, an automated provisioning workflow should apply the Core group, the Sales department group, and the Sales Representative role group automatically, without anyone having to read a document and manually apply group memberships.

This is birthright access: the access a person receives automatically based on their role and department attributes, defined once and applied consistently to every new hire in that role without manual interpretation.

Zluri connects to Active Directory and HR systems to enable this workflow. When a new user is detected in the directory with the appropriate attributes, a provisioning playbook runs and applies the defined access profile. The same applies to role changes and departures: when an employee moves departments, their old department group is removed and their new one is applied. When they leave, all group memberships are revoked.

The SharePoint document becomes the source for defining the playbooks, not the tool for executing provisioning. The actual provisioning is automated.

Handling Exceptions Without Polluting the Role Model

Every rationalized role model encounters exceptions. The question is whether exceptions are handled through the role model (which creates drift) or through a separate exception process (which keeps the role model clean).

The right mechanism for exceptions is a self-service access catalog with a formal request and approval workflow. When a user needs access outside their standard role, they submit a request specifying the application, the access level, the duration, and a business justification. The request routes to the appropriate approver: their manager, the application owner, or whoever the organization designates for that resource. Once approved, access is granted and tracked separately from the role-based grants.

The key elements that keep this clean: the exception is documented at the time of request with a business justification, it is associated with a specific user rather than silently added to a role group, it can be time-limited so it expires automatically, and it is visible in access reviews so it can be certified or revoked when it is no longer appropriate.

Zluri's App Catalog provides this workflow through a web portal and Slack integration. Employees request access through a structured form, approvers act through Slack or email, and provisioning runs automatically on approval. Every exception is tracked with a full audit trail: who requested, who approved, when it was granted, and when it expires or is revoked.

This is the mechanism that prevents "just add them to this group for now" from becoming permanent. The exception is granted in a controlled way, tracked, and reviewed rather than silently accumulating in a role group that gradually becomes meaningless.

Access Reviews: The Mechanism for Catching Drift

Even with automated provisioning and a formal exception process, access drift is a reality. People change roles, projects end, and business needs evolve. Access that was appropriate six months ago may not reflect the person's current responsibilities.

Regular access reviews, where managers are prompted to certify that their team members' access is still appropriate, close the drift detection loop. The review presents the manager with a list of each person's current access profile and asks them to confirm, modify, or revoke each item. If the manager indicates that someone should no longer have a particular access, the system removes it automatically.

This is a materially different process from a quarterly manual audit where someone digs through AD groups and tries to reconcile what they find against a SharePoint document. The review presents current data from the system, captures decisions in the system, and executes changes through the system. The audit trail is the review process itself.

For the original audit requirement: access reviews in an IGA platform generate timestamped, non-editable reports of who reviewed what, what decisions were made, and when changes were executed. This is the evidence trail auditors want for SOC 2, ISO 27001, and similar frameworks.

The Version History Requirement

The SharePoint version history covers changes to the role definition document. What it does not cover is the actual history of who had what access and when.

A system audit trail covers both. Every change to the role definition is captured when the playbook is updated. Every provisioning event, when a user was added to a group, when they were removed, when an exception was granted, when it was revoked, is captured in the system log with timestamps, actor, and context.

When an auditor asks "what access did this user have on this date, and was it consistent with their role at the time," the system can answer that question directly from the log rather than requiring someone to cross-reference a SharePoint document with manual AD exports.

Practical Steps for the Rationalization Project

The rationalization project and the governance improvement work in parallel, not in sequence.

Start by defining the clean role model: the three-tier group structure, the access profiles for each job role, and the business justification for each element. This is the design work.

While that is happening, implement the provisioning automation for new hires and leavers. This stops the accumulation of new drift even before the legacy cleanup is complete.

Then run the cleanup: use the role definitions to normalize existing users to their correct access profile, identify and document legitimate exceptions, and remove access that has no business justification.

Once the initial cleanup is complete, the ongoing governance consists of automated provisioning for lifecycle events, the exception request process for non-standard access, and quarterly access reviews that catch what automated rules miss.

Zluri supports this full cycle: Active Directory integration for provisioning and deprovisioning, App Catalog and approval workflows for exception management, and access review campaigns with automated follow-through on decisions. The SharePoint document can remain as a human-readable record of role definitions, but the system provides the authoritative audit trail.