Overview
Technical consultants often ignore policy, viewing it as "paperwork." But in IAM, Policy is Code. A SailPoint workflow or an Okta Sign-On Rule is just a codified version of a written policy. If the written policy is vague ("Users should have strong passwords"), the configuration will be inconsistent. The consultant's role is to bridge the gap: helping the CISO write enforceable Standards that the engineer can copy-paste into the configuration console.
Methodology & Frameworks
The Policy Hierarchy
Don't mix these up.
- Policy: High-level, broad, executive intent. "We will protect user credentials." (Audience: Board/All Staff).
- Standard: Mandatory, measurable requirements. "Passwords must be 14 chars." (Audience: IT/Admins).
- Procedure: Step-by-step instructions. "How to click the button." (Audience: Helpdesk/Users).
- Guideline: Best practices (Optional). "You should use a password manager." (Audience: Users).
The "SMART" Standard
Every IAM Standard must be:
- Specific: Not "strong auth", but "MFA".
- Measurable: Can I write a script to audit this?
- Achievable: Do we have the tech to do it?
- Relevant: Does it reduce risk?
- Time-bound: "Revoke access within 24 hours."
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| Exceptions | Allow vs. Forbid | Allow with Expiration. | "No exceptions" is a lie. Create a formal "Risk Acceptance" process where a VP signs off on the risk for 6 months. |
| Granularity | One big PDF vs. Modular Docs | Modular. | "Access Control Standard," "Password Standard," "Privileged Access Standard." Easier to update. |
| NIST Alignment | NIST 800-63 vs. ISO 27001 | NIST 800-63. | NIST provides the most specific technical guidance for Identity (IAL/AAL/FAL). |
| Tone | Legalese vs. Plain English | Plain English. | "Users must..." is better than "It is heretofore required that..." |
Implementation Approach
Phase 1: Assessment
Activity: Gather existing policies. (Usually 5 years old and ignored). Check: Do they match reality? (e.g., Policy says "Password change every 90 days," but Okta is set to "Never").
Phase 2: Drafting (The Workshop)
Activity: "Policy as Code" workshop.
- "Okay, CISO, you want 'Least Privilege'. What does that mean for the Sales team?"
- Draft the logic: "IF Department=Sales THEN Access=Salesforce."
Phase 3: Ratification
Activity: Get the signatures.
- Without a signature, it's just a suggestion.
- Publish it to the Intranet.
Phase 4: Operationalization (Enforcement)
Activity: Configure the tool to match the text.
- Audit: Run a report showing non-compliance.
- Remediate: "We are changing the config to match the policy on Date X."
Deliverables
- Access Control Policy: Who gets what.
- Authentication Standard: Password length, MFA rules.
- Identity Lifecycle Standard: Timelines for onboarding/offboarding.
- Privileged Access Standard: Rules for Admins (Vaulting, Rotation).
- Risk Acceptance Form: The "Get Out of Jail Free" card (with a paper trail).
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| The "Shelfware" Policy | High | Low | Policy is written but nobody reads it or follows it. | "I didn't know we had a policy for that." |
| Unenforceable Rules | Med | High | "All passwords must be memorized." (Impossible). | Review drafts with Engineers. "Can we actually enforce this?" |
| Conflicting Policies | Med | Med | HR policy says "Term in 30 days," Security says "Term in 24 hours." | Facilitate a meeting between HR and Security to align. Security usually wins. |
| Exception Black Hole | Low | High | Exceptions are granted and never reviewed. | Set auto-expiration on all exceptions. |
KPIs / Outcomes
- Policy Coverage: % of systems that technically enforce the written standard.
- Exception Count: Number of active risk acceptances (Lower is better).
- Review Cycle: % of policies reviewed in the last 12 months.
- Audit Findings: Number of findings related to "Policy vs. Practice" gaps.
Consultant's Notebook (Soft Skills)
The "Rubber Stamp" Trap
- Clients will ask: "Do you have a template? Can we just use that?"
- Danger: If they sign a template they haven't read, they are liable for things they aren't doing.
- Response: "I have a template, but we must read every line together. If you sign it, you must do it."
Policy as a Shield
- When a user complains ("Why do I have to use MFA?"), teach the Helpdesk to blame the Policy.
- "I'd love to help you, Bob, but the 'Access Control Standard v2.0' requires it. Here is a link."
- It depersonalizes the conflict. It's not the admin being mean; it's the Law.
Version Control
- Treat Policy like Code.
- Use Git or SharePoint versioning.
- "Who changed the password length from 12 to 8?"
- You need a
git blamefor your rules.
