Our company is growing and going through an internal restructuring and broader IT transformation. That has exposed weaknesses in how we manage access for new employees and people moving between teams.
Historically, our IT service management workflow copied security group memberships from a similar existing user. This provided access to SharePoint sites and libraries, shared drives, SaaS applications, and other systems with minimal manual effort. It worked reasonably well at a smaller scale, but it now creates a serious risk of excessive or incorrect access, especially when the reference user has accumulated permissions over time.
We have stopped copying users and are currently setting up access manually after consulting the employee's manager. That has led to a discussion about the right long-term approach:
- Should we formally document business roles and map them to system permissions, despite having a complex organizational structure?
- Should we delegate access decisions to business or data owners, using resource-level requests and periodic access reviews?
- Or should we use a combination of role-based baseline access and owner-approved exceptions?
For example, SharePoint access could use its native request process, while SaaS application owners could be notified when a new employee needs access. How do other organizations handle joiners, movers, and access reviews without relying on copied permissions, spreadsheets, or ad hoc approvals?
4 Answers
I would keep a small set of standard role templates, but require resource-owner approval for anything outside the baseline. Copying access from an existing employee is convenient, yet it often copies historical exceptions and permissions that the reference person no longer needs.
If you have around a few dozen roles, a role catalogue can be useful, but treat it as controlled documentation rather than a spreadsheet that someone updates manually whenever they remember. Automate membership where possible and use scheduled reviews to catch anything that falls outside the standard model.
Every application needs a business owner, and every SharePoint site or data set needs an owner who is responsible for deciding who should have access. IT can implement the permissions, but it should not be expected to define the business roles alone.
Start by documenting the main business processes and access decisions, then map those roles to application permissions. Keep the standard roles simple and use an approval workflow for exceptions. That is more maintainable than trying to model every possible combination of permissions up front.
A common setup is for the HR system to trigger an onboarding workflow. The workflow assigns a baseline template based on attributes such as department and job function, then gives the manager a chance to request additional applications or permissions.
Groups work well for collaboration platforms, while SaaS applications often need separate owner approval because each application has a different administrator. Provisioning tools can automate the common applications, but there will usually be a long tail that still needs a ticket or owner action. The important part is recording who approved the access and reviewing it later.
A combination usually works best, but divide it by the type of resource. Use real, well-defined roles for baseline access where the role is consistent. HR attributes such as department, job title, cost center, or location can drive dynamic groups and automated provisioning for standard mail, collaboration, departmental sites, and common applications.
For everything more sensitive or less predictable, use owner-approved access packages. Bundle the relevant group, SharePoint role, and application role together, require approval from the data or system owner, and add an expiration date plus recurring access reviews. That gives you a documented entitlement without asking IT to guess what each person needs.
Grant access through groups rather than directly to individual users wherever possible. Direct permissions and copied memberships are what tend to create hidden access over time. Native SharePoint requests can still be useful, but they should be paired with an accountable owner, an expiry, and periodic review.
That model also works for internal transfers, as long as the old role-based access is removed rather than simply adding the new department’s groups. Movers are where copied permissions tend to become especially dangerous.