CISSP lens: Pick answers that align business risk, governance intent, and practical control execution.
Why this matters
IAM tools can create accounts and enforce policies, but without governance they lack direction. Identity governance ensures that access decisions align with business goals, risk appetite, and compliance requirements. It is where technology, policy, and oversight meet.
Core concept
Identity Governance and Administration (IGA) combines two related functions:
- Identity administration: The technical side, handling provisioning, de provisioning, and day to day access changes
- Identity governance: The management side, defining policies, reviewing access, and ensuring compliance
Governance versus administration
Think of governance as deciding what should happen and administration as making it happen.
- Governance sets access policies, segregation of duty rules, and review schedules
- Administration executes those policies by granting, changing, and revoking access
Both are necessary for a mature IAM program.
Access certification and attestation
Access certification campaigns ask managers, application owners, or data owners to review who has access to what and attest that it is still appropriate.
Good campaigns:
- Provide clear information about each entitlement
- Include context like last login time or usage statistics
- Focus attention on high risk access
They act as detective and corrective controls for privilege creep and policy violations.
Segregation of duties enforcement
Segregation of duties (SoD) prevents conflicts of interest and reduces fraud risk by ensuring no single person can control all steps in critical processes.
IGA tools can:
- Define SoD policies, such as preventing a user from having both vendor creation and payment approval rights
- Check new access requests against these policies to prevent violations
- Scan existing entitlements to detect and report conflicts
Role mining and role engineering
Building effective role based access control often starts with role mining, analyzing existing entitlements to identify patterns.
- Similar users should have similar access patterns
- Outliers may indicate special roles or misconfigurations
Role engineering then refines these findings into roles that support least privilege and are manageable over time.
Identity analytics and risk scoring
IGA platforms increasingly incorporate analytics:
- Risk scores for identities based on entitlements, behavior, and context
- Highlighting dormant accounts, excessive privileges, and unusual access patterns
These insights guide where to focus governance efforts.
CISSP lens
Domain cross-reference
For CISSP, IGA sits at the intersection of Domain 1 (governance) and Domain 5 (IAM).
Exam relevant themes:
- Governance provides policy and oversight. Administration provides technical execution.
- Access certification is a key governance control for complying with regulations and reducing privilege creep.
- SoD enforcement is critical for financial and regulated environments.
- Role mining and engineering support sustainable RBAC implementations.
You may see scenarios where audits find SoD violations or rubber stamped reviews. The right answer usually involves stronger identity governance, not just more technology.
Real world scenario
An external auditor reviewed a company's financial systems and found that more than 200 users had combinations of access rights that violated stated SoD policies. For example, some users could both create and approve vendor payments.
The company had RBAC in place, but there was no automated SoD checking during provisioning, and access reviews lacked context.
To address this, the organization implemented an IGA solution that:
- Defined SoD policies within the tool, aligned with audit requirements
- Blocked new access requests that would create SoD conflicts, unless approved as documented exceptions
- Scanned existing entitlements and generated reports of current violations for remediation
- Provided managers with clearer information during certifications, such as risk scores and usage data
Over time, SoD violations dropped, and audit findings shifted from major deficiencies to manageable issues.
The joiner-mover-leaver lifecycle
Most IGA failures cluster around three HR events. Mapping controls to each is the simplest mental model for both the exam and program design:
| Event | What should happen | What goes wrong without IGA |
|---|---|---|
| Joiner | Birthright access provisioned automatically from role and department; anything more is requested and approved | Manual tickets, copy-the-last-hire access cloning, day-one over-provisioning |
| Mover | Old entitlements removed as new ones are granted; SoD checks run on the combined result | Privilege accumulation: ten years, four roles, all four access profiles still active |
| Leaver | All access (accounts, tokens, delegations, non-human credentials they own) revoked on the HR trigger, with verification | Orphaned accounts, active badges, service accounts whose only owner has left |
The mover row deserves the most attention, because it is the least dramatic and therefore the least policed. Terminations get checklists; transfers get congratulations. Yet auditors find the worst SoD violations precisely in long-tenured staff who moved across finance, procurement, and IT, collecting entitlements at every stop.
Birthright vs requested access
A mature program splits all access into two buckets. Birthright access flows automatically from verified attributes: every employee gets email, every accountant gets the finance portal, no tickets and no approvals. Requested access is everything else: scoped, justified, approved by the resource owner, and ideally time-bound.
Getting the split right is a governance decision with a measurable payoff. Too little birthright access and the request queue drowns in noise, training reviewers to rubber-stamp. Too much and you have institutionalized over-provisioning. The tuning signal is the request data itself: if 95 percent of people in a role request the same entitlement within a month of starting, it belongs in the role definition - move it to birthright and save the review attention for the genuinely unusual. Conversely, any birthright entitlement that certification campaigns keep flagging for removal should be demoted to requested. This feedback loop - requests inform roles, certifications prune them - is what "role engineering as an ongoing process" actually means in practice.
Common mistakes
Deploying IAM tools without governance policies, hoping technology will solve access problems on its own.
Running access certifications as bulk email exercises that managers approve without real review.
Ignoring SoD during provisioning, treating it only as an annual audit exercise.
Treating role design as a one time project, instead of revisiting roles as business processes evolve.
Viewing identity governance only as a compliance requirement, rather than a tool for managing real risk.
Actionable checklist
- Define clear SoD policies for critical business processes and encode them in your IAM and IGA systems.
- Design access certification campaigns that are targeted and risk based, with manageable scopes and useful context for reviewers.
- Use role mining tools or reports to validate that your RBAC roles align with actual access needs and to identify candidates for new or refined roles.
- Implement preventive SoD checks during provisioning so that conflicts are caught before access is granted.
- Build dashboards and reports that show identity risk indicators, such as high risk entitlements, dormant accounts, and SoD violations.
- Review governance policies at least annually or after major organizational changes to ensure they still reflect business reality.
Key takeaways
- Identity governance sets the rules and oversight mechanisms that make IAM effective and audit ready.
- Access certification and SoD enforcement are central governance controls for managing risk and meeting compliance obligations.
- Role mining and engineering strengthen RBAC and help prevent privilege creep.
- IGA tools amplify existing processes but do not replace the need for clear policies and engaged stakeholders.
- Viewing identity governance as part of risk management, not just compliance, leads to more meaningful controls.
Exam-style reflection
Question: An auditor reports that managers approve almost all access during annual certifications without meaningful review. What governance change would most improve the effectiveness of these certifications
Answer: Move to more frequent, smaller, risk based certification campaigns that provide richer context, such as usage data and risk scores, and require explicit decisions on high risk entitlements. This encourages real review instead of rubber stamping and focuses attention where it matters most.
Keep learning: Access Control Administration.
This article is part of the CISSP Domain 5: Identity and Access Management study guide. Use the pillar to navigate every article in this domain.
