Identity and Access Management Policy Template

An identity and access management (IAM) policy is the short, approved document that says who may access what, how they prove who they are, and how access is granted, changed, reviewed and removed. Auditors read it first and then test whether you follow it. This template gives you the policy text with blanks to fill, a guidance note under each section, and the control each clause maps to in ISO/IEC 27001:2022 Annex A and NIST SP 800-53 Rev. 5 (control titles as in the current 5.2.0 catalog).

How to use this template

1. Replace every [bracketed field]. Delete clauses that do not apply rather than leaving them unfulfilled: an auditor tests what you wrote.
2. Keep the policy short and stable. Put tool settings, timeouts and step-by-step procedures in the supporting standards and procedures listed in section 12, which you can change without re-approving the policy.
3. Use "must" for requirements and "should" for recommendations, and use them consistently.
4. Get it approved by the owner named in the document control block, publish it where staff can find it, and review it at least yearly.

Companion templates: MFA and authentication standard, privileged access policy, service account and NHI policy, joiner-mover-leaver procedure, third-party access policy and the access review checklist.

Document control

1. Purpose

This policy sets the rules [ORGANIZATION] follows to make sure that only authorized identities can access its information and systems, with the least access needed, and that this access is removed promptly when it is no longer needed.

2. Scope

This policy applies to:

• All identities that access [ORGANIZATION] systems: employees, contractors, partners, vendors' staff, customers with administrative access to [ORGANIZATION] systems, and non-human identities (service accounts, API keys, OAuth applications, workload identities and AI agents).
• All systems that store or process [ORGANIZATION] information, whether on premises, in cloud infrastructure or in SaaS applications, including systems purchased outside IT.

Out of scope: [e.g., customer end-user accounts in the product, covered by the product security policy].

Guidance: name non-human identities and shadow SaaS explicitly. They are where policies most often have gaps. ISO 5.16 expects the lifecycle of every identity to be managed, not only staff.

3. Roles and responsibilities

4. Policy statements

4.1 Access control principles

1. Access must be granted on the basis of business need and least privilege.
2. Access must be granted to roles or groups rather than to individuals wherever the system supports it.
3. Incompatible duties defined in [SoD matrix] must not be held by one identity without an approved exception (separation of duties).
4. Each identity must belong to one accountable person or, for non-human identities, one named owner. Shared accounts are prohibited except as listed in [shared account register].

Maps to: ISO 5.15 Access control, 5.3 Segregation of duties; NIST AC-3 Access Enforcement, AC-5 Separation of Duties, AC-6 Least Privilege.

4.2 Identity lifecycle (joiner, mover, leaver)

1. Accounts must be created only from an approved request or an authoritative HR event.
2. Birthright access by role is defined in [role catalog]. Access beyond it requires approval from the system owner.
3. When a person changes role, access no longer needed for the new role must be removed within [__ business days].
4. When a person leaves, all access must be disabled within [__ hours], and immediately for involuntary departures and privileged users.
5. Accounts inactive for [__ days] must be disabled.

Maps to: ISO 5.16 Identity management, 5.18 Access rights, 6.5 Responsibilities after termination or change of employment; NIST AC-2 Account Management, AC-2(3) Disable Accounts, PS-4 Personnel Termination, PS-5 Personnel Transfer.

Guidance: AC-2(h) asks you to define how quickly account managers are told when users are terminated or transferred, and PS-4 asks you to define how quickly access is disabled. Put the numbers in the joiner-mover-leaver procedure so you can tighten them without re-approving the policy. See user lifecycle management.

4.3 Authentication

1. Workforce access to [ORGANIZATION] systems must go through the corporate identity provider using single sign-on, unless the system is listed in [SSO exception register].
2. Multi-factor authentication is required for all workforce access.
3. Phishing-resistant MFA is required for privileged access, remote administrative access and [other high-risk populations], and is the target for all users by [date].
4. Passwords, where still used, must follow the MFA and authentication standard. Periodic forced password changes are not required except on evidence of compromise.
5. Credential recovery and MFA reset must verify identity at a level at least as strong as the credential being replaced.

Maps to: ISO 5.17 Authentication information, 8.5 Secure authentication; NIST IA-2 Identification and Authentication (Organizational Users), IA-2(1) and IA-2(2) Multi-factor Authentication to Privileged and Non-privileged Accounts, IA-5 Authenticator Management.

Guidance: the password and phishing-resistance language follows NIST SP 800-63B-4, which prohibits periodic password change requirements and requires a phishing-resistant authenticator at AAL3. Clause 5 exists because help desk resets are how attackers got into MGM Resorts; see help desk social engineering.

4.4 Privileged access

1. Administrative tasks must be performed with a separate privileged account, not the user's everyday account.
2. Privileged access must be granted just in time and expire after [__ hours] where the platform supports it. Standing privileged access must be listed and justified in [privileged access register].
3. Privileged sessions on [tier 0 systems] must be recorded or logged at the command level.
4. Emergency (break-glass) accounts must exist, be protected and monitored as set out in the privileged access policy.

Maps to: ISO 8.2 Privileged access rights; NIST AC-6(2) Non-privileged Access for Nonsecurity Functions, AC-6(5) Privileged Accounts, AC-6(9) Log Use of Privileged Functions, AC-2(2) Automated Temporary and Emergency Account Management.

4.5 Access to information and source code

1. Access to [confidential data categories] must be restricted to the roles listed in [data access matrix].
2. Write access to source code repositories and build pipelines must be limited to [engineering roles] and reviewed [quarterly].

Maps to: ISO 8.3 Information access restriction, 8.4 Access to source code; NIST AC-3 Access Enforcement.

4.6 Access reviews

1. System owners must review user access to [in-scope systems] every [3 / 6 / 12] months, and privileged access every [3] months.
2. Reviewers must make an explicit decision for each entitlement. Access marked for removal must be removed within [__ days] and the removal verified.
3. Evidence of each review (reviewer, date, decisions, remediation) must be retained for [__ years].

Maps to: ISO 5.18 Access rights; NIST AC-2(j) account review, AC-6(7) Review of User Privileges.

Guidance: use the access review checklist. An access review with zero revocations usually means reviewers are approving without looking; see mover entitlement accumulation.

4.7 Non-human identities

1. Every service account, API key, OAuth application, workload identity and AI agent must have a named human owner and be recorded in [NHI inventory].
2. Non-human identities must not be used by people for interactive sign-in.
3. Credential types, maximum lifetimes and rotation follow the service account and NHI policy.

Maps to: ISO 5.16 Identity management, 5.17 Authentication information; NIST IA-9 Service Identification and Authentication, IA-5(7) No Embedded Unencrypted Static Authenticators.

4.8 Third-party access

1. Contractors, partners and vendor staff must have individual accounts sponsored by an [ORGANIZATION] employee, with an end date no later than [__ days] from approval.
2. Integrations that access [ORGANIZATION] data must be approved by [security] before connection.

Maps to: ISO 5.19 Information security in supplier relationships; NIST PS-7 External Personnel Security, AC-20 Use of External Systems. Details in the third-party and contractor access policy.

4.9 Logging and monitoring

1. Authentication events, administrative actions and changes to access must be logged and the logs retained for [__ months].
2. Alerts must be raised for [break-glass use, MFA method changes, new admin grants, impossible travel].

Maps to: ISO 8.15 Logging, 8.16 Monitoring activities; NIST AU-2 Event Logging, AC-2(12) Account Monitoring for Atypical Usage.

5. Exceptions

1. Exceptions must be requested in [system] with the business reason, the compensating control, the risk owner and an expiry date no later than [__ months].
2. Exceptions are approved by [role] for [risk level] and by the policy owner above it.
3. Expired exceptions lapse automatically; renewal requires a new request.

Guidance: an undated MFA exemption list is one of the most common audit findings. Keep the register short and dated.

6. Compliance and enforcement

Compliance with this policy is measured through [metrics: MFA coverage, SSO coverage, leaver SLA, review completion] and reported [quarterly] to [committee]. Violations may result in access removal and disciplinary action in line with [HR policy].

7. Related standards and procedures

Control mapping summary

ISO/IEC 27001:2022 is a paid standard; control titles above are as published in its Annex A. The NIST control catalog is free in the CPRT browser and as OSCAL.

Related

• Identity controls for ISO 27001
• SOC 2 for identity
• IAM audit preparation guide
• Identity governance program guide
• What is IAM
• IAM maturity assessment