Introduction
As someone transitioning from software development into GRC (Governance, Risk, and Compliance), you quickly discover that Identity and Access Management (IAM) sits at the center of everything. It's not a siloed IT task—it's the control plane of your organization's entire security posture.
This guide breaks down the core IAM concepts every GRC professional needs to master, without pretending you need to become an Active Directory administrator.
TL;DR: IAM = Authentication + Authorization + Lifecycle Management. Your job as GRC isn't to configure it, but to validate that the processes follow design principles like Least Privilege and Separation of Duties.
1. Design Principles That Matter
Before touching any tool, ground yourself in these foundational principles:
Principle of Least Privilege
Users and systems get only the permissions necessary for their function—no more, no longer than needed. This directly reduces blast radius when credentials are compromised.
Separation of Duties (SoD)
No single person controls a complete critical workflow. Example: The person authorizing a payment shouldn't be the same person executing it. In IAM terms: don't allow one admin to create AND approve privileged access without independent review.
GRC Question to Ask: "If one account gets compromised, what can they actually damage?"
2. The IAM Lifecycle Framework
IAM isn't just about logging in. It spans the full identity lifecycle:
| Phase | What Happens | GRC Focus Area |
|---|---|---|
| Onboarding | New user identity created | Are role-based permissions aligned with job function? |
| Active Use | Daily authentication/authorization | Is MFA enforced where appropriate? Are privileges reviewed? |
| Role Change | User transitions internally | Old privileges revoked? SoD still maintained? |
| Offboarding | User leaves organization | All access removed within defined SLA? Audit trail preserved? |
3. Authentication vs. Authorization: Know the Difference
Authentication (Who are you?)
Verifying identity through factors:
- Something you know → Password, PIN (weakest alone)
- Something you have → Hardware token, smartphone (MFA)
- Something you are → Biometrics (fingerprint, iris, face scan)
⚠️ GRC Risk Note: Biometrics are irrevocable. If stolen, you cannot reset your fingerprint like a password. Policies must account for this permanent exposure risk.
Authorization (What can you do?)
Once authenticated, what resources can the user access?
- ACL (Access Control Lists) → Binary allow/deny rules tied to resources
- RBAC (Role-Based Access Control) → Permissions assigned to roles, not individuals
- ABAC (Attribute-Based Access Control) → Dynamic decisions based on context (time, location, device, sensitivity)
4. NIST Password Guidelines: What Changed?
Old school security culture told us:
- ❌ Force password changes every 90 days
- ❌ Require special characters and numbers
- ❌ Lock accounts after minor failures
NIST now recommends:
- ✅ Minimum length (8+ chars) over arbitrary complexity
- ✅ Remove mandatory expiration periods (they cause weak patterns)
- ✅ Screen passwords against breach databases
- ✅ Lock only after multiple confirmed failed attempts
Source: NIST SP 800-63B
5. Active Directory & PAM: The Real Risks
Active Directory (AD)
Even if you don't administer AD, understand these risks:
- Who has "Domain Admin"? This is the crown jewels.
- How does cross-domain trust work?
- Is there integration with cloud identities (Entra ID / Azure AD)?
PAM (Privileged Access Management)
Admin accounts are the highest-value targets. Your control requirements:
| Control | Why It Matters |
|---|---|
| Minimize privileged accounts | Fewer targets = lower risk surface |
| Just-In-Time (JIT) access | Elevated rights only when needed |
| Session recording | Audit trail for forensic investigations |
| Vault management | No one knows admin passwords—they're retrieved securely |
| Separate browsing accounts | Admins shouldn't browse email/web with privileged session |
6. What GRC Actually Does in IAM
Your value isn't in configuring ACLs. It's in:
- Mapping Processes → Ensure onboarding/offboarding timelines meet compliance
- Continuous Audit → Regular reviews prove privilege justification exists
- Risk Assessment → Weak authentication = high breach risk regardless of firewall strength
- Evidence Collection → Documenting controls for auditors (SOC2, ISO 27001, GDPR)
Conclusion
IAM bridges technical implementation and organizational governance. As a GRC professional, your job is to ask whether the IAM process supports business objectives while meeting security requirements—not to configure the tools yourself.
From code to compliance: You're moving from building mechanisms to validating that those mechanisms align with reality, risk appetite, and legal obligations.
References & Further Reading
- NIST SP 800-63 Digital Identity Guidelines
- OWASP Authentication Cheat Sheet
- CISA Identity and Access Management Best Practices
Top comments (0)