Writing Policy & Standards

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 blame for your rules.