Access Management Policy Template


Company Name	[Company Name]
Effective Date	[Date]
Version	[Version Number, e.g., 1.0]
Policy Owner	[CISO/IT Director]
Document Classification	Confidential / Internal Use Only
Parent Policy	Information Security Policy

Purpose

This policy establishes the requirements for managing access to [Company Name]'s information systems, applications, data, network resources, and physical facilities. Its purpose is to ensure that access is granted based on the principle of least privilege and business need-to-know, that user identities are uniquely established and authenticated, and that access activities are logged and monitored. This policy aims to protect the confidentiality, integrity, and availability of all company assets, including sensitive corporate data, Personally Identifiable Information (PII), Intellectual Property (IP), and Cardholder Data (CHD), while meeting regulatory obligations, including PCI DSS 4.0.1.

Scope

This policy applies to all individuals requiring access to [Company Name]'s information resources, including employees, contractors, consultants, temporary staff, and third-party service providers. It covers access to all company-owned or managed systems, applications (cloud-based and on-premises), databases, network devices, source code repositories, physical facilities housing relevant systems (including the Cardholder Data Environment - CDE), and data, regardless of location. This policy addresses the entire lifecycle of access, from initial provisioning through modification, periodic review, and revocation.

Roles and Responsibilities

Role/Group	Key Responsibilities
Executive Management	Provide overall sponsorship and ensure resources for the access management program; Establish acceptable risk tolerance for access control.
CISO/IT Director	Own and approve this policy; Oversee the design, implementation, and operation of access control mechanisms; Ensure overall compliance.
Information Security Team	Develop and maintain access control standards and procedures; Define security roles; Conduct security reviews of access requests; Monitor for access violations; Manage MFA solutions; Participate in access reviews.
IT Operations/System Administrators	Implement and manage access control technologies (e.g., AD, IAM tools, VPN, PAM solutions); Provision, modify, and revoke access based on approved requests; Manage system/service accounts.
Human Resources (HR)	Manage employee onboarding, role changes, and offboarding processes; Provide authoritative source for user identity information; Notify IT/Security promptly of employment status changes.
System/Application/Data Owners	Define access requirements and roles for their specific resources; Approve access requests based on need-to-know; Participate in periodic access reviews for their resources.
Managers/Supervisors	Request appropriate access for their direct reports based on job duties; Review and approve access requests; Participate in periodic access reviews for their team members.
Users	Comply with this policy and associated standards (e.g., password complexity, acceptable use); Protect their credentials; Report lost/stolen credentials or suspected unauthorized access immediately.
Compliance/Audit Team	Periodically review access management processes, controls, and records for compliance and effectiveness.

Policy Requirements

1. User Account Management Policy

Unique Identification: Every individual requiring access to company systems must be assigned a unique User ID. Generic or shared accounts for interactive use are prohibited. Service accounts must be uniquely identifiable, documented, secured, and used only for their intended non-interactive purpose.
Account Provisioning: User accounts shall only be created upon receipt of a documented and approved request, typically initiated via HR onboarding or a manager request through the designated IT Service Management (ITSM) system. Access granted must align with the user's defined role and business need-to-know.
Account Modification: Changes to user access privileges (e.g., due to role change, transfer) must follow a documented request and approval process, ensuring privileges are adjusted according to the new role's requirements (least privilege).
Account Disablement/Revocation: User accounts must be promptly disabled or revoked upon notification of termination, resignation, extended leave, or change in status making access unnecessary. This process must be triggered by HR notifications and completed within defined service level agreements (SLAs) (e.g., within 24 hours of notification). All associated access mechanisms (physical, logical, remote) must be revoked.
Inactive Accounts: User accounts inactive for a specified period (e.g., 90 days) must be automatically disabled or flagged for review and potential disablement.
Vendor/Third-Party Accounts: Access for third parties must be provisioned based on contractual requirements, limited to specific systems and timeframes needed, use unique credentials, and be reviewed regularly. Accounts must be promptly disabled upon contract termination or completion of the required access period.

2. Authentication

Password Standards: All passwords must meet minimum complexity requirements (length, character types) and be changed periodically, as defined in the [Company Name] Password Standard. Passwords must be stored securely using strong, industry-accepted hashing or encryption methods. Default vendor passwords must be changed before systems are placed into production.
Multi-Factor Authentication (MFA): MFA must be implemented and required for:
- All remote access to the network from untrusted networks.
- All administrative access (privileged access) to any system, including cloud environments.
- All user access into the Cardholder Data Environment (CDE).
- Access to other critical systems or data as determined by risk assessment. MFA implementation must use strong authentication factors from different categories (e.g., something you know, something you have, something you are).
Session Management: System sessions must automatically lock after a period of inactivity (e.g., 15 minutes). Users must re-authenticate to resume sessions. For remote access, sessions should automatically terminate after a defined period of inactivity.

3. Authorization and Access Control

Principle of Least Privilege: Access rights granted to users must be limited to the minimum necessary to perform their assigned job duties. Default access must be "deny-all".
Role-Based Access Control (RBAC): Access shall primarily be managed through RBAC where feasible. Roles are defined based on job function and responsibilities, and access permissions are assigned to roles rather than directly to individual users.
Access Request and Approval: All requests for new access or modification of existing access must be formally documented (e.g., via ITSM ticket), justified by business need, and approved by the relevant System/Application/Data Owner and/or the user's manager before being implemented by IT/System Administrators. Requests for privileged access or access to sensitive data (including CDE) require additional scrutiny and approval from Information Security or designated authority.
Segregation of Duties: Access controls shall be implemented to enforce segregation of duties where appropriate, preventing individuals from having excessive control or the ability to perform conflicting actions without oversight (e.g., developing code vs. deploying code, creating vendors vs. paying vendors).

4. Role Assignment Policy

Role Definition: Business roles and corresponding system access roles shall be clearly defined and documented, based on job functions and responsibilities across the organization. Definitions must specify the access permissions associated with each role.
Role Assignment Matrix (RAM): A Role Assignment Matrix (or equivalent documentation) shall be maintained, mapping job titles/functions to the standard system access roles required for those positions. This matrix serves as a baseline for provisioning access. (See Appendix Appendix Appendix A for template/guidance).
Role Management: The creation, modification, and retirement of roles must follow a defined process involving stakeholders (e.g., Business Owners, HR, IT, Security) and be formally approved. Roles must be reviewed periodically for continued necessity and appropriateness of assigned permissions.
Assignment Process: Users are assigned roles based on their job title and function as documented in the RAM and confirmed by their manager during the access request process. Deviations from standard role assignments require explicit justification and approval.

5. CDE Access Control Policy

Strict Need-to-Know: Access to the Cardholder Data Environment (CDE) and systems within it is strictly limited to personnel whose job function explicitly requires such access.
Explicit Approval: All access to the CDE must be explicitly requested, justified based on specific job duties related to CHD, and approved by authorized management and Information Security.
Documentation: A list of personnel with access to the CDE, along with their roles and justification, must be maintained and reviewed regularly (at least quarterly).
MFA Requirement: All interactive user access into the CDE must be authenticated using MFA.
Least Privilege within CDE: Even for authorized users, access within the CDE must be restricted to the specific systems, data, and functions necessary for their role. Administrative access within the CDE is highly restricted.
Physical Access Control: Physical access to systems within the CDE (e.g., servers in data centers) must be strictly controlled, monitored, and limited to authorized personnel with a documented need.

6. Privileged Access Management (PAM)

Identification: Accounts with elevated or administrative privileges on systems, applications, databases, or network devices must be clearly identified and inventoried.
Limited Use: Privileged accounts must only be used for tasks explicitly requiring elevated permissions. Standard user accounts must be used for routine activities (e.g., email, web browsing).
Unique & Named: Privileged access must be assigned to unique, named user accounts, not shared/generic administrative accounts.
MFA: MFA is mandatory for all privileged access.
Secure Management: Privileged account credentials must be vaulted and managed through a dedicated PAM solution where feasible, enabling features like credential rotation, session monitoring, and just-in-time access.
Review: Privileged access rights and account activity must be reviewed frequently (e.g., quarterly) by Information Security and relevant system owners.

7. Access Reviews

User Access Reviews: Managers, in conjunction with System/Application/Data Owners, must review the access rights of their direct reports and access granted to their resources at least quarterly (or more frequently for critical systems/CDE). Reviews must verify that access levels remain appropriate for current job roles and adhere to least privilege.
Privileged Access Reviews: Access rights associated with privileged accounts must be reviewed at least quarterly by Information Security and the relevant owner.
Documentation: All access reviews must be formally documented, including reviewer sign-off, date, scope, findings, and any remediation actions taken (e.g., access revocations). Records must be retained for audit purposes.

8. Remote Access Policy

Approved Methods: Remote access to [Company Name]'s internal network must only occur through company-approved, secure, and encrypted mechanisms (e.g., corporate VPN solution). Direct connections from the internet to internal systems are prohibited unless explicitly approved and secured (e.g., via DMZ architecture).
Authentication: All remote access sessions must be authenticated using MFA.
Endpoint Security: Devices used for remote access must meet company security standards (e.g., up-to-date OS, endpoint protection software, disk encryption). Personal devices require specific approval and security validation.
Need-Based Enablement: Remote access capabilities should only be enabled for users with a documented business need. Vendor remote access must be enabled only when required for support and disabled immediately afterward.
Session Controls: Remote access sessions must have inactivity timeouts. Split-tunneling is prohibited for VPN connections accessing sensitive environments like the CDE.
Data Handling: Copying, moving, or storing sensitive data (especially CHD) onto local devices during remote access sessions is prohibited unless explicitly authorized for a specific business need and secured according to all relevant policies.
Monitoring: Remote access connections must be logged and monitored.

9. Logging and Monitoring

Access control systems, directories, and critical applications/systems must generate audit logs for access-related events, including: successful/failed login attempts, access grants/revocations, privileged actions, and administrative changes to access controls.
Logs must include User ID, timestamp, event type, success/failure indication, and affected resource.
Logs must be protected from tampering and retained according to the company's data retention policy (at least one year for audit, minimum 3 months readily available).
Logs related to access must be reviewed regularly (automated alerts for critical failures, periodic reviews for trends/anomalies).

Enforcement

Failure to comply with this Access Management Policy may result in disciplinary action, up to and including termination of employment or contract, in accordance with established HR policies and contractual agreements.
Unauthorized access attempts or misuse of access privileges will be investigated and may lead to access revocation and disciplinary/legal action.
Exceptions to this policy require a documented business justification, formal risk assessment identifying potential impacts and compensating controls, and written approval from the CISO/IT Director. Approved exceptions must be reviewed at least annually.

Revision History

Version	Date	Author	Change Details
1.0	[Date]	[Author Name]	Initial policy release
[Ver #]	[Date]	[Author Name]	[Summary of changes]

Approval

Name	Title	Signature	Date
[Exec Name]	[Executive Title, e.g., CIO]		[Date]
[CISO Name]	[CISO/IT Director Title]		[Date]

Appendix A: Role Assignment Matrix (RAM) - Guidance (using RACI concept)

A Role Assignment Matrix helps clarify responsibilities related to access management processes. While primarily used for projects, the RACI concept (Responsible, Accountable, Consulted, Informed) can be adapted to define roles in access control workflows.

Example RACI for Access Request Process:

Task / Decision	User	Manager	System Owner	IT Implementer	InfoSec	HR
Identify Need for Access	R	A	C	I	I	I
Submit Access Request	R	A	I	I	I	I
Approve Access (Need-to-Know)	I	A	R	I	C	I
Approve Access (Security Risk)	I	I	C	I	A/R	I
Provision Access in System	I	I	I	R	C	I
Notify User of Access Grant	I	I	I	R	I	I
Review User's Access (Quarterly)	C	A	R	I	C	C
Initiate Access Revocation (Term)	I	C	I	C	C	R/A
Execute Access Revocation	I	I	I	R	C	I

Key:

R = Responsible (Does the work)
A = Accountable (Owns the work/decision, ensures it's done)
C = Consulted (Provides input before decision/action)
I = Informed (Kept up-to-date after decision/action)

Note: This is illustrative. The actual matrix should be customized for [Company Name]'s specific processes.

A simpler matrix might just map Job Titles to required Access Roles (RBAC approach):

Job Title	Application A Role	Application B Role	Network Share Access	VPN Access	Admin Rights	CDE Access Role
Sales Representative	Sales User	View Only	Sales Dept Share	Yes	No	No
Finance Analyst	Finance User	Power User	Finance Dept Share	Yes	No	Finance Reader
IT System Admin	Admin	Admin	All Dept Shares	Yes	Yes (ServerX)	IT Admin CDE
Customer Support Tier 1	Support User	N/A	Support Share	No	No	No
Database Admin	N/A	N/A	IT Share	Yes	Yes (DB Servers)	DB Admin CDE

Appendix B: User Access Lifecycle Flow - Simplified

graph TD
    subgraph Onboarding
        A[HR Creates Employee Record] --> B{Manager Requests Access via ITSM}
        B --> C{System Owner Approves?}
        C -- Yes --> D{"InfoSec Approves (if needed)?"}
        C -- No --> E[Request Rejected/Modified]
        D -- Yes --> F[IT Provisions Access & Notifies User]
        D -- No --> E
    end

    subgraph Ongoing
        G{User Role Change?} -- Yes --> H{Trigger Modification Request}
        H --> B
        I[Quarterly Access Review by Manager/Owner] --> J{Access Still Required?}
        J -- No --> K{Trigger Revocation Request}
    end

    subgraph Offboarding
        L[HR Notifies IT/Sec of Termination] --> K
        K --> M[IT Revokes All Access]
        M --> N[Document Revocation]
    end

    F --> I
    J -- Yes --> I

Appendix C: Remote Access Security Standards - Checklist

VPN: Approved corporate VPN solution used exclusively.
Encryption: Strong, current encryption protocols enabled (e.g., TLS 1.2+ for SSL VPN, AES-256 for IPsec).
Authentication: MFA required for all VPN logins.
Client Security: Endpoint compliance checked (OS patch level, AV status, disk encryption) before connection allowed (using NAC or VPN client features).
Split Tunneling: Disabled for connections accessing CDE or sensitive internal resources.
Session Timeout: Automatic disconnect after defined inactivity period (e.g., 30 minutes).
Logging: Detailed connection logs (User ID, source IP, timestamp, duration) generated and sent to SIEM.
Access Control: VPN access granted based on role; network access policies applied to VPN connections.
Vendor Access: Separate profiles/groups for vendors; enabled only when needed; monitored sessions.

Appendix D: PCI DSS 4.0.1 Access Control Requirements Mapping

PCI DSS Requirement	Relevant Policy Section(s)	Key Controls Covered
Req 7 (Overall)**	Policy Req 3 (Authorization), 4 (Role Assignment), 5 (CDE Access)	Restrict access by business need-to-know, principle of least privilege, RBAC promoted.
7.1.1	Policy Req 3 (Authorization), 4 (Role Assignment), 5 (CDE Access)	Access limited based on job classification and function.
7.1.2	Roles & Responsibilities, Policy Req 4 (Role Assignment)	Definition and communication of access control roles and responsibilities.
7.1.3	Policy Req 3 (Authorization)	Default "deny-all" setting.
Req 8 (Overall)**	Policy Req 1 (User Account Mgmt), 2 (Authentication)	Assign unique IDs, authenticate access.
8.1.1	Policy Req 1 (Unique Identification)	Assign all users a unique ID.
8.2.1, 8.2.2	Policy Req 1 (User Account Mgmt)	Control addition/modification/deletion of user IDs; immediate removal of terminated users.
8.2.3, 8.2.4, 8.2.5, 8.2.6	Policy Req 2 (Password Standards, Session Mgmt)	Password complexity, history, change frequency, lockout thresholds, session locks.
8.3.1	Policy Req 2 (MFA)	Implement MFA for non-console administrative access.
8.3.2	Policy Req 2 (MFA), Policy Req 8 (Remote Access)	Implement MFA for all remote network access originating from outside the network.
8.3.3	Policy Req 2 (MFA), Policy Req 5 (CDE Access)	Implement MFA for all access into the CDE.
8.5.1	Policy Req 1 (Vendor/Third-Party Accounts)	Service providers with remote access use unique credentials per customer.
8.6.1	Policy Req 1 (User Account Mgmt - Shared Accounts)	Generic/shared user IDs are not used for interactive logins. Specific controls for service accounts implied.
10.2.2, 10.2.3	Policy Req 9 (Logging and Monitoring)	Log all actions by users with root/admin privileges; Log all access/authentication events.
12.3.8	Policy Req 2 (Session Management), Policy Req 8 (Remote Access)	Automatic disconnect of remote access sessions after inactivity period.
12.3.9	Policy Req 1 (Vendor/Third-Party Accounts), Policy Req 8 (Remote Access)	Enable third-party remote access only when needed, disable immediately after use.
12.3.10	Policy Req 8 (Remote Access - Data Handling)	Prohibit copying/moving/storing CHD locally via remote access unless authorized and secured.