An IAM policy template is only useful if it's enforceable. This guide covers what every IAM policy needs to include, what makes policies fail in practice, and includes a free downloadable template your team can implement immediately.
The average enterprise has an IAM policy. In many cases, it was written during a compliance audit, approved by a security committee, and filed in a shared drive where it has remained largely untouched since. It says the right things: least privilege, MFA required, periodic access reviews, timely deprovisioning. What it lacks is the specificity to be actionable and the enforcement architecture to be meaningful.
The gap between a policy that exists and a policy that governs is the difference between a document and a program. Documents state principles. Programs define who does what, by when, through which mechanism, and how violations are detected and remediated. The policy template below is designed to be a program document, not a principles statement.
It includes nine sections that cover the full scope of access governance. Each section includes the policy language, the operational requirement it creates, and the evidence it produces for audit purposes. A downloadable version is available at the bottom of this article.
What an IAM Policy Needs to Do
Before building the policy, it's worth being precise about what a functioning IAM policy is for. It serves three purposes simultaneously:
Operational guidance: telling the people who provision, review, and revoke access exactly what the rules are, so decisions are consistent rather than ad hoc. A policy that requires "appropriate access" without defining what appropriate means for each role produces inconsistent provisioning that accumulates risk.
Enforcement foundation: giving the tools and automation that implement access control a documented basis for their configuration. If your IAM platform enforces MFA for all administrative access, the policy should be the document that specifies that requirement, so the configuration reflects a decision rather than a default.
Audit evidence: demonstrating to internal auditors and external compliance reviewers that access control requirements were defined, implemented, and operated. The policy is the baseline against which your provisioning logs, deprovisioning records, and access review completion evidence are measured.
A policy that serves all three purposes is substantively different from one that serves only the third. The template below is designed for all three.
The 9 Sections Every IAM Policy Needs
Section 1: Purpose, Scope, and Definitions
Why it matters: Scope defines what the policy governs. A policy with an unclear scope produces arguments about whether a given system, identity type, or access scenario falls under its requirements. These arguments typically resolve in favor of the exception, which is where risk accumulates.
What to include:
The purpose statement should be specific: this policy governs how the organization manages identities, controls access to systems and data, and verifies that access remains appropriate over time. Not "to protect our assets" but "to ensure that every identity in the environment holds only the access required for their current function, that access is reviewed periodically, and that access is revoked promptly when the relationship that justified it changes."
Scope should explicitly name what is in scope (all production systems, all SaaS applications used for business purposes, all identity types including service accounts and API credentials) and what is not in scope (if anything). The default should be inclusive: if it's not explicitly excluded, it's in scope.
Definitions should include: identity (human and non-human), privileged access, least privilege, access review, SoD, provisioning, deprovisioning, orphaned account. Shared vocabulary prevents the interpretation gaps that produce compliance failures.
Section 2: Roles and Responsibilities
Why it matters: Policies that assign responsibilities to "the IT team" or "security" without specifying individuals or roles produce shared non-ownership. When the deprovisioning step fails because no one knew it was their job, "the IT team was responsible" is not a useful finding.
What to include:
Identity and Access Management team: owns the policy, maintains the access control configuration, runs access review cycles, manages provisioning and deprovisioning automation, produces compliance evidence.
System owners: responsible for defining what access their system requires and approving access to their systems through the review process. Not the IAM team's job to know what roles need access to every system; that knowledge lives with the owner.
HR / People Operations: provides the authoritative source for employee status changes (hires, role changes, departures). The IAM team's provisioning and deprovisioning automation depends on this data being accurate and timely.
Managers: responsible for approving access requests for their direct reports, participating in access reviews for their teams, and promptly notifying HR and IT when a team member's status changes.
All employees and contractors: responsible for using only the access granted to them, not sharing credentials, reporting suspected unauthorized access, and following the access request process for additional access needs.
Vendors and third-party service providers: responsible for following this policy as it applies to their access, which should be specified in their service agreements.
Section 3: Access Control Policy
Why it matters: This is the core of the policy. It defines the access model the organization uses and the rules for how access is granted, modified, and maintained.
What to include:
Access model: specify whether the organization uses RBAC (role-based access control), ABAC (attribute-based), PBAC (policy-based), or a combination. For most organizations, RBAC is the primary model. Define what a role is and who owns the role definitions.
Least privilege: every identity receives the minimum access required to perform their current function. Access is granted to roles, not individuals wherever possible. Individual exceptions require documented justification and a defined expiry.
Segregation of duties: no individual may hold access to both sides of a sensitive transaction. Specify the critical SoD pairs relevant to your organization: payment initiation and payment approval, journal entry creation and journal entry approval, access provisioning and access review. Define what happens when an SoD conflict is detected and the exception process for approved conflicts.
Access request process: all access beyond what is automatically provisioned by role must be requested through the defined access request workflow. Requests must include business justification and manager approval. Access granted through informal channels (email, direct application admin) without a request record is a policy violation.
Access to sensitive data: access to systems containing [define: personally identifiable information / protected health information / financial data / intellectual property] requires additional authorization beyond standard role-based access. Specify the additional approval step.
Section 4: Identity Lifecycle Management
Why it matters: This section operationalizes the joiner-mover-leaver model. Without specific requirements for each phase, the policy cannot produce consistent provisioning or reliable deprovisioning.
What to include:
Joiner (new user provisioning):
All new employees, contractors, and partners must be provisioned through the defined IAM workflow, triggered by an authoritative HR or contract management system event. Provisioning must occur no later than the user's start date. Access is provisioned based on the role defined in the HR system. Access beyond the standard role definition requires a separate access request, approved prior to the start date.
Shared or generic accounts may not be used for individual employee provisioning. Each identity must be individually attributable.
Mover (role and status changes):
When a user changes role, department, or scope of work, their access must be updated within [define: 5 business days] of the effective date of the change. New role access is provisioned; access no longer appropriate for the new role is revoked. Access from previous roles does not carry forward by default. Exceptions require documented justification.
Leaver (access termination):
Upon departure (voluntary or involuntary), all access must be revoked across all systems within [define: 24 hours for standard users / immediate for privileged access holders] of the effective departure date. Deprovisioning must cover all applications the user accessed, not only those managed through the primary IdP. An offboarding record must exist documenting the applications deprovisioned and the timestamps of revocation.
For contractors and temporary workers, access must be terminated at the end of the contracted term. Access grants for contractors must include an explicit end date; indefinite contractor access is not permitted.
Section 5: Authentication Standards
Why it matters: Authentication requirements set the floor for how access is verified. Without specific standards, "strong authentication" means different things to different people and different systems.
What to include:
Password policy: minimum length [define: 12 characters], complexity requirements, prohibition on reuse of the last [define: 12] passwords, maximum age [define: 90 days or on indication of compromise]. Passwords may not be shared. Service accounts must use unique passwords not used by any other account.
Multi-factor authentication: MFA is required for:
- All access to production systems
- All remote access (VPN, cloud console, remote desktop)
- All privileged and administrative access
- All access to systems containing sensitive data as defined in Section 3
- All access by contractors and third parties
MFA methods: authenticator apps and hardware tokens are acceptable. SMS-based MFA is acceptable only where stronger methods are not available and must be accompanied by a documented risk acceptance. Email-based MFA codes are not acceptable for systems containing sensitive data.
Session management: sessions must time out after [define: 15 minutes] of inactivity for administrative access; [define: 4 hours] for standard user access. Re-authentication is required after session timeout. Concurrent sessions from different devices or locations for the same user account must trigger a risk notification.
Legacy systems: systems that cannot support MFA or strong authentication must be documented as exceptions, subject to compensating controls (network segmentation, enhanced monitoring, more frequent access review), and included in the roadmap for remediation or decommissioning.
Section 6: Privileged Access Management
Why it matters: Privileged accounts represent the highest-value targets in any identity environment. Standard access control requirements are necessary but not sufficient for accounts with administrative, infrastructure, or directory-level access.
What to include:
Definition of privileged access: all accounts with the ability to modify system configurations, access or modify any user's data without authorization, manage other user accounts, or access production infrastructure. This includes: directory administrators, cloud infrastructure administrators, database administrators, security tool administrators, and any service accounts with equivalent capabilities.
Privileged account requirements:
- All privileged accounts must be individually attributable. No shared privileged accounts.
- Privileged access must be used only for the specific tasks that require it. Standard work (email, productivity tools, web browsing) must be performed from a standard user account, not a privileged account.
- All privileged access sessions must be logged, with the log retained for a minimum of [define: 12 months].
- Privileged accounts must be reviewed monthly. Access must be recertified by the account holder's manager.
- Privileged account deprovisioning on departure is immediate, not within-24-hours.
Just-in-time access: where technically feasible, privileged access should be granted on a time-limited, task-specific basis rather than as persistent access. Persistent privileged access must be documented and justified.
Section 7: Remote Access and Vendor Access
Why it matters: Remote and vendor access extend the identity perimeter beyond the organizational boundary. The same access control principles apply, but the risk profile differs because the organization has less visibility into the endpoint and the user's operating environment.
What to include:
Remote access:
All remote access to organizational systems requires VPN or equivalent encrypted connectivity and MFA. Personal devices used for remote access must meet minimum security standards: current OS version, active endpoint protection, screen lock. Organizational data may not be stored on personal devices unless through an approved, managed application.
Users may not use remote access to access systems beyond what their role requires. Remote access logs must be retained for a minimum of [define: 90 days].
Vendor and third-party access:
Third-party vendors may only be granted access to the specific systems required to perform their contracted services. All vendor access must be provisioned through the standard IAM workflow, not granted directly by the requesting team. Vendor access must include an explicit end date tied to the contract term.
Vendors may not share access credentials. Each individual at a vendor organization who requires access must have their own, individually attributable account.
Vendor access is subject to access review at least semi-annually, or at contract renewal, whichever occurs first.
All vendor access agreements must include language requiring compliance with this policy. Vendor access may be revoked immediately if a security incident or policy violation is identified.
Section 8: Access Review Requirements
Why it matters: Access reviews are the mechanism by which the policy's least-privilege requirement is enforced on an ongoing basis. Without specific requirements for frequency, scope, and remediation, access reviews become checkbox exercises.
What to include:
Frequency:
- Standard user access: quarterly review of all access, with the review covering every application in the IAM inventory, not only IdP-managed applications.
- Privileged access: monthly review.
- Contractor and vendor access: at contract renewal and on any scope change, minimum semi-annual.
- Access to sensitive data systems (as defined in Section 3): quarterly.
Scope: access reviews must cover the complete identity inventory, including non-SSO application accounts, service accounts, and contractor identities. An access review that covers only the IdP's catalog does not satisfy this requirement.
Review process: access reviews are conducted by access owners (system owners or the account holder's direct manager, not the account holder themselves). Reviewers certify that access is still appropriate and required. For flagged access, reviewers must indicate either that access should be revoked, or provide a written justification for retention.
Remediation: access flagged for revocation during an access review must be revoked within [define: 14 business days] of the review completion. The remediation completion must be documented as part of the access review record.
Review records: all access reviews must produce a completion record documenting the review date, population reviewed, reviewer identity, decisions made, and remediation evidence. These records must be retained for a minimum of [define: 3 years] for compliance purposes.
Section 9: Exceptions, Violations, and Enforcement
Why it matters: A policy without an exception process produces workarounds. A policy without a violation process has no teeth. Both undermine the policy's function as a governance document.
What to include:
Exception process: requests to operate outside the requirements of this policy (extended access beyond standard role, shared account for a documented business reason, delay in deprovisioning for transition purposes) must be submitted to the IAM team with business justification, manager approval, and a defined end date. Exceptions are approved by [define: CISO / IT Director]. All exceptions must be documented, dated, and included in the next access review cycle for reassessment.
Policy violations: access granted or used outside the requirements of this policy is a policy violation. Violations are investigated by the IAM team and reported to the relevant manager and HR. Depending on severity, violations may result in immediate access revocation, formal disciplinary action, or escalation to the security incident response process.
Deliberate circumvention of access controls (sharing credentials, using another user's account, accessing systems beyond authorized scope) is a serious policy violation subject to disciplinary action up to and including termination and, where applicable, legal action.
Policy review and maintenance: this policy is reviewed annually and updated whenever significant changes occur in the organization's technology environment, regulatory requirements, or identity risk profile. The IAM team owns the review process. Policy updates require approval from [define: CISO / Security Committee / Executive sponsor].
Effective date and version control: all versions of this policy must be retained. The current effective date and version number must appear on the document.
How Zluri Helps Enforce This Policy
A policy document defines what should happen. Zluri makes it happen.
Zluri is an identity security platform whose four IGA modules (Access Management, Access Requests, Access Reviews, and Segregation of Duties) translate each section of this policy into operational automation and enforcement.
Section 4 (lifecycle management) runs through automated provisioning and deprovisioning workflows triggered by HRMS and SSO events, covering 300+ applications through over 1,500 granular workflow actions. Joiner provisioning fires on the hire date. Mover access updates fire on role change. Leaver deprovisioning covers every application in the identity inventory, not just what the IdP manages.
Section 3 (access control) and Section 8 (access reviews) run through Zluri's Access Reviews module, which operates at application, group, and user level. Reviews run on the schedule the policy defines. Completion records and remediation evidence are generated automatically.
Section 6 (privileged access) is supported by Zluri's continuous monitoring layer, IRIS, which flags privileged accounts with anomalous activity, inactive privileged sessions, and missing review records.
Section 3's SoD requirements run through the Segregation of Duties module, which continuously monitors cross-application permission combinations against the SoD ruleset and surfaces conflicts for remediation.
IVIP, Zluri's identity visibility layer, ensures that access reviews and deprovisioning automation cover the complete identity inventory through 8 discovery methods, not only what the IdP's catalog contains. The policy requirement that reviews cover "all applications in the IAM inventory, including non-SSO application accounts" is only satisfiable with a discovery capability that finds those accounts.
Implementation runs 2 to 3 months, producing a policy enforcement architecture that generates audit evidence continuously as a byproduct of normal operations.
Download the IAM policy template below, then book a demo to see how Zluri enforces it
Frequently Asked Questions
What should an IAM policy include?
A complete IAM policy covers nine areas: purpose and scope, roles and responsibilities, access control policy (including the access model, least privilege, and SoD requirements), identity lifecycle management (joiner, mover, leaver requirements), authentication standards, privileged access requirements, remote and vendor access, access review requirements, and exception and enforcement procedures. The downloadable template below covers all nine.
What is the difference between an IAM policy and an IAM policy template?
An IAM policy is the organization's specific governing document, customized to its environment, risk profile, and compliance requirements. An IAM policy template is the starting framework: the structure and sections that any IAM policy needs, with placeholder language for the organization-specific decisions (SLA timelines, frequency requirements, approval chains). This article provides the template; your organization provides the decisions.
How often should an IAM policy be reviewed?
Annual review is the standard, with interim updates triggered by significant changes: a new compliance requirement, a material change in the technology environment, a security incident that revealed a policy gap, or a significant change in the organization's workforce structure. The policy itself should specify its review cadence and version control requirements.
Is an IAM policy required for SOC 2 or ISO 27001?
Both frameworks require documented access control policies as part of their control requirements. SOC 2 expects evidence that a policy exists, that it has been communicated to relevant personnel, and that actual access management practices reflect the policy. ISO 27001 Annex A requires an access control policy (A.5.15 in the 2022 version) with management approval. Neither framework requires a specific policy format; both look for documented requirements that are implemented in practice. See the IAM compliance guide for a framework-by-framework breakdown.
What makes an IAM policy enforceable?
An IAM policy is enforceable when it specifies concrete requirements (specific SLA timeframes, specific authentication methods, specific review frequencies) rather than principles (access should be appropriate, authentication should be strong). Enforceability also requires three operational elements: automation that implements the policy's requirements without relying entirely on human execution, monitoring that detects when requirements are not met, and a defined violation response process. A policy document without these elements is aspirational rather than operational.
What is the difference between an IAM policy and an IAM checklist?
The policy is the governing document that defines the rules. The checklist is the verification tool that confirms whether the rules are being followed. The policy says "deprovisioning must occur within 24 hours of departure." The checklist asks "can you show deprovisioning timestamps for every departure in the past quarter confirming the 24-hour SLA was met?" Both are necessary; neither substitutes for the other. See Zluri's IAM audit readiness checklist for the verification tool.
.svg)
