Identity governance programs often start with a spreadsheet and a quarterly access review. Teams track who has access to what, check whether those assignments still make sense, and fix problems after auditors flag them.
What Identity Governance Actually Covers
Identity governance controls who gets access to what, for how long, and under what conditions. It spans provisioning, modification, revocation, and proving it all happened correctly.
This is broader than identity and access management alone. IAM handles the plumbing — authentication, directory services, single sign-on. Identity governance handles the decisions: which access is appropriate, whether it is being used, and what happens when it is not.
The distinction matters because many teams build strong IAM infrastructure and skip governance entirely. They can authenticate users and route logins through a central directory, but they cannot answer basic questions: who has standing admin access to production? Which service accounts have not been used in an extended period? Can we prove that last quarter's access review actually happened?
The Core Practices Teams Implement
Identity governance programs tend to converge on a small set of repeatable practices, regardless of organization size or industry.
Identity Lifecycle Management
Lifecycle management covers account creation, modification, and deletion across each in-scope system where users need access. In practice, this means a joiner-mover-leaver process that connects HR events to access changes.
When someone joins, their manager submits a request through a form or ticketing system. That request routes to the appropriate approvers based on role, department, or system. Access is provisioned automatically where possible and queued for manual provisioning where it is not.
When someone changes roles, the old access should be reviewed and new access granted. This is where most programs struggle. Role changes happen informally — a Slack message, a conversation with a manager — and the access review gets skipped. Later, the person still has access to systems from their previous role.
When someone leaves, access revocation should be immediate and complete. The practical challenge is that many organizations have many SaaS applications, and not all of them support automated deprovisioning. The result is a long tail of manual revocations that take days or extended periods.
The teams that do this well invest in a provisioning connector strategy: they identify which systems support SCIM or API-based provisioning, automate those first, and build manual runbooks for the rest. They do not try to automate everything at once.
Access Reviews and Certification
Access reviews are periodic exercises where managers or system owners confirm that each user's access is still appropriate. This is the common identity governance practice and the one likely to be audited.
The standard approach runs on a defined cadence. A review campaign is created, managers receive a list of their direct reports and their access, and they certify or revoke each assignment. The completion rate and findings become audit evidence.
The problems are well known. Review fatigue is real — managers click "approve all" without reading the list. The volume of access to review grows as new systems get onboarded. And the review itself does not fix problems; it only identifies them. The remediation work falls to a different team.
Teams that improve access review quality focus on a few things:
- Scoping. Do not review each in-scope system for each person. Prioritize high-risk systems and privileged access. A quarterly review of all SaaS apps for all employees produces noise. A monthly review of production admin access for the people who hold it produces signal.
- Context. Give reviewers the information they need: when the access was last used, what the role requires, and whether similar roles have the same access. A manager reviewing "Jane has admin access to AWS" is guessing. A manager reviewing "Jane has admin access to AWS; her role requires read-only; similar roles have read-only" can make a decision.
- Automation of remediation. When a reviewer revokes access, the system should execute the revocation automatically. If it requires a separate ticket, the finding sits in a queue and nothing happens.
Privileged Access Management
Privileged access management controls elevated access to critical systems: production infrastructure, financial databases, administrative consoles. This is the high-risk access in any organization and the area where governance failures have the direct consequences.
Practical privileged access management includes:
- Standing access removal. Nobody should have permanent admin access to production. Temporary elevated access, granted through a just-in-time workflow and time-boxed to a specific task, replaces standing privileges.
- Session recording. When someone uses privileged access, the session is recorded or logged. This provides audit evidence and incident investigation material.
- Break-glass procedures. For emergency situations where normal approval workflows would cause unacceptable delay, a break-glass process grants immediate access with mandatory post-incident review.
- Service account governance. Service accounts are the often neglected privileged access category. They often have broad permissions, no owner, no expiration, and no review. Teams that govern service accounts well maintain an inventory, assign owners, rotate credentials on a schedule, and review permissions on a defined cadence.
Segregation of Duties
Segregation of duties ensures that no single person can complete a high-risk transaction alone. The classic example: the person who can create a vendor in the accounting system should not also be the person who can approve payments to that vendor.
In governance automation, identity governance is enforced through role design and access conflict rules. The governance platform maintains a matrix of incompatible permissions and flags or blocks combinations that violate it.
The practical challenge is that segregation of duties rules create friction. A startup with a small team cannot segregate every duty. The approach that works is risk-based: identify a small set of transaction types where fraud or error would cause the most damage, and enforce separation for those. Accept that lower-risk processes will have combined roles.
Authentication Policy Governance
Authentication policy governance defines how users prove their identity across the organization. Password requirements, multi-factor authentication rules, session timeouts, and conditional access policies all fall under this practice.
The governance part is not setting the policies; it is ensuring they are consistent and enforced. Many organizations have a stated MFA policy but uneven enforcement. The web application enforces it. The legacy finance system does not.
Teams that govern authentication well maintain a policy baseline: a documented standard for MFA, password complexity, and session management, applied consistently across systems. They track exceptions and require explicit approval for each one with a documented remediation timeline.
The Comparison: How Teams Approach Identity Governance
| Practice | Spreadsheet-Based | Tool-Assisted | Fully Automated |
|---|---|---|---|
| Access reviews | Manager gets email list, replies with approve/revoke | Platform generates review campaigns, tracks completion | Risk-scored reviews with auto-revocation for low-risk access |
| Provisioning | IT ticket per request, manual execution in each system | Automated for top systems via connectors, manual for rest | SCIM/API provisioning for all systems, HR-driven triggers |
| Privileged access | Admin credentials shared via password manager | JIT access with approval workflow, session logging | Fully ephemeral credentials, policy-enforced time limits |
| Service accounts | Documented in spreadsheet, reviewed on a defined cadence | Inventory with assigned owners, credential rotation reminders | Automated rotation, usage monitoring, owner notifications |
Many teams are in the middle column. Fully automated identity governance requires meaningful integration investment and organizational maturity. Spreadsheet-based governance meets audit minimums but does not scale and catches problems late.
Where Programs Get Stuck
Identity governance programs follow a predictable trajectory. Understanding where they stall helps teams plan realistic timelines.
The inventory problem. Before you can govern access, you need to know what access exists. Many organizations do not have a reliable inventory of all systems, all accounts, and all access assignments. Building this inventory is unglamorous work — connecting to directories, APIs, and databases to enumerate accounts — but nothing else works without it.
The connector gap. Governance tools work well with systems that have modern APIs and support standards like SCIM. Legacy applications, homegrown tools, and niche SaaS products often do not. Every non-integrated system becomes a manual process, and manual processes degrade over time.
The approval bottleneck. Access requests and review certifications both require human decisions. When those decisions pile up — because managers are busy, or because the review volume is too high — the governance process stalls. The access request queue becomes the bottleneck, and workarounds fill the gap.
The remediation gap. Access reviews identify problems. Remediation fixes them. In many organizations, these are separate processes owned by different teams. The review team flags excessive access assignments. The remediation team has a backlog. The flagged access stays active while it waits.
The scope creep. Identity governance programs that try to cover each in-scope system, each access type, and each policy decision simultaneously run out of budget and momentum. The programs that succeed start narrow — privileged access, or joiner-mover-leaver for the high-risk systems — and expand incrementally.
How CASK Connects to Identity Governance
CASK handles the compliance evidence side of identity governance. When your access review produces findings, CASK captures the evidence — who reviewed what, what was revoked, what exceptions were approved — in a local, cited record.
The governance platform makes the decisions. CASK documents that those decisions happened, were reviewed, and were acted on. For teams that need to prove identity governance to an external auditor, CASK turns scattered review artifacts into structured, cited evidence.
Because CASK runs locally and keeps data on your machine, identity governance evidence stays under your control. No review results or access logs leave your environment.
Related Reading
For related context, see vendor offboarding access revocation, least privilege implementation, privileged access management, access certification campaigns, and access review.
FAQ
How often should access reviews happen?
The frequency depends on the risk level of the access being reviewed. Privileged access to production systems benefits from monthly or even continuous review. Standard application access works well on a quarterly cycle. The key is matching review frequency to risk, not running the same cadence for everything.
What is the difference between identity governance and identity management?
Identity management handles the technical operations: authenticating users, syncing directories, managing passwords. Identity governance handles the decisions: which access is appropriate, whether it is being used, and how to prove that to auditors. You need both, but they serve different purposes.
Can small teams implement identity governance?
Yes, but the scope should be narrow. A small team does not need a full governance platform with many connectors. Start with a documented access policy, a quarterly access review for your sensitive systems, and a joiner-mover-leaver checklist. Grow the program as the organization scales.
What makes access reviews effective rather than performative?
Three things: scope the review to high-risk access, give reviewers enough context to make real decisions, and automate the remediation so flagged issues actually get fixed. A review that produces many "approved" clicks and zero revocations is not a review.
How do service accounts fit into identity governance?
Service accounts are often the weakest link because they have broad access, no human owner, and no expiration. Effective governance treats service accounts as first-class identities: assign an owner, document the purpose, set expiration dates, review permissions periodically, and rotate credentials on a schedule.