Identity Governance and Administration

This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. Requirements and standards evolve, and you should consult with a qualified compliance professional about your specific situation.

Identity governance keeps access correct as the organization changes. When people are hired, they need access. When they move between roles, their access should follow. When they leave, access should be revoked immediately. In most organizations without formal governance, this happens informally and incompletely. Someone tells IT that a new person started, IT manually creates an account and adds the person to some groups, then when they leave, access revocation is incomplete because nobody tracks everything that was provisioned. The result is access entropy: accounts accumulating, permissions drifting, orphaned accounts with elevated privileges remaining active for years, creating persistent security risk.

Onboarding: Access Provisioning for New Employees

Onboarding is the first critical moment in the access lifecycle. A new employee arrives on day one and needs systems access. Without formal onboarding, the traditional flow is ad hoc: the hiring manager tells IT about the new person verbally or via email, IT manually creates accounts in various systems, then manually adds the person to appropriate groups. Something probably gets missed. Maybe they don't get email on day one. Maybe they get added to the wrong group. Maybe they can't access the systems they need to do their job on day one because nobody was clear about what they need.

Proper onboarding follows a formal process. HR or a recruiting system notifies an identity management workflow system that a new employee is starting on a specific date with a specific role. The system uses the role and other attributes to determine what access is needed. It either provisions accounts automatically or creates provisioning requests for human approval. The key is that access provisioning is deliberate, not ad hoc. Nothing gets missed because the process is designed to catch it.

The workflow might look like: HR enters new employee information with their role, the identity system looks up what applications and systems that role needs, it provisions accounts automatically in systems that support it or creates requests for systems that need manual provisioning, emails go out to the appropriate team leaders for approval, accounts get created, and credentials are delivered to the new employee. By the time the person sits down on day one, their access is ready. More importantly, there's a record of what was provisioned—this becomes critical later when they leave and you need to know what to revoke.

Some organizations use identity provisioning systems that can create accounts across multiple systems in parallel. Others have manual workflows but with clear checklists and responsibility assignments. The method varies but the principle is the same: formalize onboarding so nothing gets missed and so you have documentation of what was provisioned.

Role Assignment and Approval Processes

During onboarding, the new employee gets assigned to appropriate roles. This should happen through a formal request-and-approve workflow, not through informal chat messages or casual conversation. The request should specify the role, the business reason, and the start date. Someone—usually the manager or a team lead—approves the request. This creates a record: who requested it, who approved it, when, and why.

This formality matters. Approval processes prevent simple mistakes and potential abuse. If anyone could assign themselves to any role, people would give themselves more access than they actually need. If the process is formal and documented, there's accountability. If something goes wrong later—maybe someone misused access—the audit trail shows who made the decision. If someone claims they should have had access and you need to prove they didn't, the audit trail tells the story.

The approval hierarchy should match the sensitivity of access. For most roles, manager approval is sufficient. For sensitive roles, additional approval might be required. A compliance officer should approve requests for financial system access. A security person should approve requests for system administrator roles. Someone from HR should approve requests for access to personnel records. The approval process creates gates that prevent inappropriate access decisions.

The key is that documented approval creates accountability. When there's a record of who approved what and when, people take the decision seriously. They can't just approve everything because someone was friendly or because they didn't want to be difficult—there's a record of their approval decisions.

Access Reviews: Regular Validation of Access

At least annually, organizations should conduct access reviews. Someone—usually the employee's manager—reviews what access the person has and confirms whether they still need it. This catches several recurring problems that plague organizations without reviews. Access for old projects that ended is usually discovered: the engineer still has access to the archived project's code repository even though the project shipped two years ago. Access from previous roles is caught: someone moved from customer support to engineering but still has access to the customer database. Access that was granted "temporarily" but never revoked is discovered: someone was given emergency access to production databases for an incident response three months ago and nobody revoked it.

In practice, many organizations conduct reviews but do them poorly. They give managers a spreadsheet showing "employee X has access to systems A, B, C, D, E" and ask if it's still needed, but don't explain what each system does or why the employee might have access. Reviews become rubber-stamp exercises where managers approve everything without thinking. This defeats the purpose.

Better reviews show context. "Employee X has access to the payroll system because they're in HR and need to run reports and verify data. Do they still need access? Yes/No." This gives managers something meaningful to evaluate. They can make an informed decision about whether the access is still necessary.

Reviews should be periodic—at least annually but quarterly is better for organizations where people move between roles frequently. Reviews should require active approval, not passive approval. "Approve unless you object within two weeks" becomes theater where everything gets approved by default. "Review and actively approve or revoke" creates actual decision points.

The review process is unglamorous and tedious, but it's the real mechanism that prevents access entropy. When you conduct thorough reviews, you almost always find unnecessary access that can be removed. This reduces risk, simplifies your access control, and catches problems before they become incidents.

Offboarding: Removing Access When People Leave

When someone leaves the organization, all their access should be revoked immediately. In practice, this fails frequently. An employer ends someone's employment on Friday evening, but doesn't notify IT until Monday morning. By then the person might have accessed systems over the weekend, taken data, or caused damage. Some access gets revoked but others don't—that shared project folder still has their credentials, the contractor still has VPN access from six months ago, their email account was disabled but their database access remains.

Formal offboarding processes prevent this. HR or a recruiting system notifies the identity system that an employee is terminating. The system automatically revokes or schedules revocation of all access. Email and file access get revoked immediately. Application access gets revoked through the identity system. VPN and physical access need separate coordination with other teams. The process is formal, documented, and ideally automated so it happens consistently.

The complexity here is that you often don't have a complete inventory of where someone has access. The shared server account that two people use? Probably forgotten. The SaaS tool that someone uses but IT doesn't directly manage? Might not be revoked. That SSH key that was deployed to servers? Might still be active. The cloud storage account that was created but never formally provisioned? Might still exist. Complete access inventory and centralized access control make offboarding reliable. Without them, offboarding becomes incomplete.

The security implication of poor offboarding is significant. Accounts that remain active after people leave are exploitable. An attacker who compromises an old account has legitimate access to systems. An employee who left on bad terms could still access systems and cause damage. Contractors or vendors whose engagements end can still access resources. Slow or incomplete offboarding leaves open doors.

Compliance and Audit Trail Requirements

Identity governance only works if you can prove it happened. Regulators and auditors want to see that access decisions were made by appropriate people, that reviews happened regularly, that revocation was timely. This requires comprehensive logging: who requested access, who approved it, when, and why. When was access revoked and why. Without audit trails, you can't answer basic questions about your access control.

Many organizations struggle to answer simple questions: Who approved this person's access to this system? Why does this account still exist? When was their access last reviewed? Without audit trails, these questions are unanswerable. With proper logging, you can answer them quickly. You can show an auditor that access was approved by appropriate people, that reviews happened, that revocation occurred when it should have.

The audit trail serves multiple purposes beyond compliance. It's forensic information if something goes wrong. If someone misuses access, the logs show who accessed what, when, and what they did. It's a deterrent—people behave differently when they know access decisions are logged. It's institutional memory—years later, you can understand why a decision was made. It's evidence—it proves governance happened.

The practical implication is that logging needs to be automatic and comprehensive. Manual audit trails—log books, spreadsheets, emails—create gaps and inconsistencies. Formal identity governance platforms log access requests, approvals, provisioning, reviews, and revocation automatically as they happen. This creates reliable audit trails that you can trust.

Tooling and Process Automation

What onboarding, offboarding, and reviews look like depends partly on tooling. Manual processes using spreadsheets, email requests, and verbal approvals don't scale well and create audit trail gaps. Formal identity governance platforms automate provisioning, approval workflows, access reviews, and offboarding. They maintain audit trails automatically. They enforce policies—preventing someone from getting access to systems that would create conflicts of interest.

But tooling doesn't solve governance alone. The best identity governance tools won't help if you don't use them correctly. If your role definitions are bad, automating role assignment just automates bad decisions faster. If managers approve access reviews without reading them, automating the approval workflow doesn't improve anything. If you don't actually revoke access when tooling tells you to, having the tool doesn't help.

Tools are necessary but not sufficient. You need both good processes and supporting tools. The tool helps scale processes, enforce consistency, maintain audit trails, and prevent mistakes. But the processes—the business logic of who should approve what, when reviews should happen, what revocation looks like—are human decisions.

Scaling Governance as Organization Grows

Governance that works with 50 employees often breaks with 500. Manual processes become impossible to manage. Email approval cycles become bottlenecks that slow onboarding. Spreadsheet-based access reviews become unwieldy with hundreds of employees and thousands of access decisions. As you grow, you need tools and more formalized processes.

The progression that typically works is: start with formal but manual processes, add tooling to automate common flows, add policies to prevent common mistakes, and evolve as the organization scales. At 50 people, a manager can approve access requests by email and you can track onboarding in a spreadsheet. At 200 people, you need a workflow system that automates approvals. At 500 people, you need policy automation that prevents obviously bad decisions. At 2000 people, you might add delegation—managers can approve access for their team within defined guardrails—but with systems that prevent policy violations.

The key is that governance needs to evolve as the organization scales. What works at one size breaks at the next size up. Successful organizations anticipate this and evolve their processes and tooling as they grow rather than waiting until governance breaks.

Closing Beat

You now understand that identity governance spans the entire lifecycle—onboarding, role assignment, review, and offboarding—and that formal processes prevent errors and create accountability. You understand that approval creates visibility, that reviews catch drift, and that offboarding needs to be fast and complete. You understand that audit trails are non-negotiable for compliance and that tools support good processes.

When you're building identity governance, start with formal processes first—you can automate later. Make sure managers understand that access reviews are real security work and require thoughtful answers. Build your audit trail from the beginning because retrofitting compliance into systems that didn't log decisions is nearly impossible. Invest in tools as you scale, but remember that tools support processes—they don't create good governance from bad processes. That's how governance actually works in practice.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about identity governance as of its publication date. Standards and best practices evolve — consult a qualified compliance professional for guidance specific to your organization.