ITGC tells you access needs to be controlled. It doesn't tell you how to actually build that control, which is the part most implementations get wrong.
Where this fits
Access control is one of five ITGC categories, and the one that carries the most audit weight, since it changes constantly while the other categories tend to stay stable. What auditors test for, and how those audits are structured, is covered in our companion guide to the ITGC audit process.
This guide covers a different question: how do you actually design and build the access control mechanisms an ITGC program depends on, before an auditor ever shows up to test them. Getting the underlying model right determines whether testing later goes smoothly or turns into a scramble.
The access control models
Most access control implementations rest on one or two of a small set of models. Picking the right one, or the right combination, shapes everything downstream.
Role-Based Access Control (RBAC). Access is tied to a job role rather than an individual. A "Finance Analyst" role gets a defined bundle of entitlements, and anyone assigned that role inherits the bundle. RBAC is the most common model because it's straightforward to audit: reviewing access means reviewing role assignments, not hundreds of individual permission grants.
Attribute-Based Access Control (ABAC). Access decisions factor in attributes beyond role: department, location, employment type, data classification. ABAC handles nuance RBAC struggles with, like a contractor in one region needing narrower access than a full-time employee in the same role.
Policy-Based Access Control (PBAC). Access decisions run through a centrally defined policy engine rather than being hardcoded into individual role or attribute assignments. A PBAC policy might state that anyone accessing a financial system from outside a defined location needs an additional approval step, regardless of their role. PBAC tends to layer on top of RBAC or ABAC rather than replace them, adding a rules layer that can evaluate context, like Segregation of Duties conflicts, dynamically rather than only at the point access is first granted.
Least privilege as a governing principle, not a model. Least privilege isn't a control type on its own. It's the standard every model should be evaluated against: does this identity have exactly the access its current role requires, no more. RBAC and ABAC are mechanisms for enforcing least privilege at scale; without that discipline, either model quietly accumulates excess access over time.
The building blocks of an access control program
A working access control program is made up of a handful of mechanisms, each addressing a different point in the identity lifecycle.
Authentication. Verifying an identity is who it claims to be, before anything else happens. Multi-factor authentication has become the baseline expectation for any system touching sensitive or financial data, since password-only authentication is trivially defeated by credential theft or reuse.
Provisioning. Granting access when it's first needed, tied to a defined role or request, with documented approval. Provisioning that happens ad hoc, through a Slack message or a verbal request, is the single most common source of access that later shows up as unexplained or excessive.
Role and permission design. Structuring RBAC or ABAC roles so they map to actual job functions, not to whatever access happened to get granted historically. Poorly designed roles, ones that accumulated permissions from years of exceptions, tend to violate least privilege by default, regardless of how well the provisioning process around them works.
Monitoring and logging. Recording every access grant, change, and login event in a retrievable form. Logs are what make every other control provable. A well-designed access model with no logging still leaves an auditor unable to confirm it operated as intended.
Recertification. Periodically confirming that existing access still matches current need. This is the mechanism that catches drift: role changes, project access that outlived the project, permissions nobody remembered to revoke.
De-provisioning. Removing access when it's no longer needed, ideally triggered automatically by an identity lifecycle event like a termination or role change, rather than a manually filed ticket that depends on someone remembering to file it.
Manual vs. automated implementation
Every one of these building blocks can be run manually or automated, and the choice compounds over time.
Manual provisioning means a ticket, an approval, and someone in IT configuring access by hand in each application. It works at small scale. It breaks down as application count grows, since the same new hire might need accounts provisioned across a dozen systems, each with its own manual process and its own chance for delay or error.
Automated provisioning ties access grants to a defined trigger, typically an HR system event, and pushes the correct role-based access to every relevant application without a human touching each one. The tradeoff is upfront setup cost: automation requires the role model and application integrations to already be defined correctly, or it automates the wrong access just as efficiently as the right access.
De-provisioning shows this tradeoff most starkly. Manual de-provisioning depends on someone remembering to file a ticket the day someone leaves, across every system that person had access to. Automated de-provisioning, triggered by the same HR event that triggers onboarding, closes that gap by design rather than by diligence.
Implementation roadmap
1. Define scope. Identify which systems, data, and identity populations the access control program needs to cover. Include non-human identities and service accounts here, not just employees; they're frequently left out of scope entirely and often carry broader access than any single human role.
2. Assess current-state risk. Inventory existing access across in-scope systems and look for the patterns that cause the most damage: excessive permissions relative to role, orphaned accounts with no clear owner, and manual processes with no consistent approval trail.
3. Design the role model. Build RBAC roles, or ABAC attribute rules, around actual job functions rather than historical access patterns. This step is where most of the long-term value gets created or lost. A role model built on "what people currently have" just formalizes existing over-permissioning instead of fixing it.
4. Automate provisioning and de-provisioning. Tie access grants and removals to identity lifecycle events wherever the underlying systems support it. Start with the highest-risk applications, financial systems, core infrastructure, before extending automation to lower-risk tools.
5. Establish a recertification cadence. Set a review schedule matched to risk: more frequent for privileged and financially sensitive access, less frequent for lower-risk systems. Build the review to produce a retrievable record automatically, not one assembled by hand each cycle.
6. Monitor, measure, and adjust. Track how often recertification finds excess access, how long de-provisioning takes after a termination, and how many exceptions get requested against the role model. These numbers indicate whether the underlying design is holding up or drifting.
Who should own each building block
Access control programs tend to fail at handoffs, not within any single team's part of the work. A simple ownership split helps avoid that.
- IT and security teams own role design, provisioning automation, and monitoring infrastructure.
- Application owners are accountable for what "correct access" looks like inside their specific system, since IT alone often can't judge whether a given permission set makes sense for a business process.
- HR owns the lifecycle events that should trigger provisioning and de-provisioning, hires, terminations, and role changes.
- Compliance or internal audit owns the recertification schedule and confirms reviews are actually happening, not just documented as a policy.
The most common gap sits between HR's lifecycle event and IT's access change. A termination processed in the HRIS on Friday doesn't automatically mean access gets revoked the same day, unless that handoff was deliberately automated rather than left to a manual notification.
Common implementation pitfalls
Role sprawl. Roles get created for one-off situations and never retired, until the role model has more roles than it has meaningful distinctions between them. A role model this fragmented is nearly as hard to review as no role model at all.
Provisioning templates that over-grant by default. A new-hire template built to avoid follow-up requests often bundles in more access than the role needs, on the theory that it's easier to grant broadly upfront. This is the most common practical violation of least privilege, and it's introduced at the design stage, not through later drift.
Disconnected provisioning across applications. Access granted correctly in the core HR and IT systems, but handled inconsistently in smaller SaaS tools adopted outside central IT. These tools often escape the same rigor even though they can carry equivalent risk.
No automated de-provisioning trigger. Access removal depending entirely on a manually filed ticket is the single most cited root cause behind stale access findings, regardless of how well the rest of the program is designed.
Recertification treated as a formality. Reviews that get rubber-stamped without genuine scrutiny defeat the purpose of the control. If a reviewer approves every access grant without exception, quarter after quarter, that pattern itself is often a sign the review isn't doing meaningful work.
How Zluri supports access control implementation
Building the access model described above depends on knowing what actually exists across the SaaS estate first, which is where most implementations stall. Zluri starts from discovery rather than from a declared inventory, surfacing applications and identities through eight parallel discovery methods (SSO and identity providers, direct integrations, finance and expense data, browser extensions, CASBs, MDMs, HRMS, and directories) cross-referenced against a library of over 240,000 known applications. That inventory, including non-human identities and service accounts, becomes the actual scope the access control program gets designed against, rather than the scope IT assumed existed.
From there, role and attribute-based provisioning can apply conditions like department, designation, and location, so a role model reflects real job function distinctions instead of one-size-fits-all templates. Recommended app and action suggestions update dynamically as those attributes change, reducing the chance a provisioning template quietly over-grants by default.
Automated, lifecycle-triggered provisioning and de-provisioning close the manual-ticket gap directly: an HRMS update can fire a playbook that provisions a new hire's access automatically, and the same trigger on termination revokes it without depending on someone remembering to file a request. Movers, role or department changes, can chain a de-provisioning playbook into an onboarding playbook for the new role in a single automation.
Recertification runs as scheduled, recurring access reviews at the application, group, or user level, producing a documented record of what was reviewed and what action followed, so the review itself generates the evidence an auditor or an internal risk owner would ask for later, instead of that evidence being reconstructed after the fact.
Frequently Asked Questions
What's the difference between RBAC and ABAC?
RBAC ties access to a defined job role, with all users in that role sharing the same entitlement bundle. ABAC factors in additional attributes like department, location, or data classification, allowing finer-grained decisions than role alone can capture.
Is least privilege a type of access control?
No. Least privilege is a governing principle, not a control mechanism. RBAC, ABAC, and other models are the mechanisms used to enforce it; least privilege is the standard those mechanisms should be measured against.
Why does manual de-provisioning cause so many access control problems?
Manual de-provisioning depends on someone remembering to file a request the day an employee leaves or changes roles, across every application they had access to. Any missed step leaves access active with no current business justification, which is one of the most commonly cited ITGC access findings.
How often should access recertification happen?
Cadence should match risk. High-risk and privileged access typically warrants quarterly review, while lower-risk systems can run on a longer cycle. What matters most is that the chosen cadence is followed consistently, not just defined on paper.
Should non-human identities be included in the access control program?
Yes. Service accounts, API keys, and automation identities often carry broad, standing access and are easy to leave out of both provisioning and recertification processes if the program is designed around human users only.
What's the biggest mistake organizations make when designing access controls?
Building the role model around existing access patterns instead of actual job requirements. This formalizes whatever over-permissioning already exists rather than correcting it, and it tends to resurface as recurring recertification findings later.
.svg)
