Compliance Framework Alignment
ISO/IEC 27001:2022 — A.5.16 (Identity management) ISO/IEC 27001:2022 — A.5.18 (Access rights) SOC 2 — CC6.2 (Registration & authorisation of users) SOC 2 — CC6.3 (Role-based authorisation, modification & removal) PCI DSS v4.0.1 — Requirement 7 (Least privilege / RBAC) PCI DSS v4.0.1 — Requirement 8 (Identify & authenticate users) This procedure is drafted to help you meet the access-lifecycle requirements of the frameworks listed above; it is an editable template, not legal or certification advice, and should be reviewed against your own environment before use.
ACME TECHNOLOGIES PVT LTD ACCESS PROVISIONING (JOINER-MOVER-LEAVER) PROCEDURE
Effective Date [Effective Date]
Procedure Owner Head of Information Security (CISO )
Document Classification Internal
Review Cycle Annual, or on material change 1. Purpose and Scope
This procedure defines how Acme Technologies Pvt Ltd grants, changes and revokes access to information systems, applications, cloud services and data across the full identity lifecycle — commonly described as Joiner, Mover and Leaver (JML). Its purpose is to ensure that every person and non-person account is uniquely identified, that access is granted only on an approved need-to-know basis, and that access is removed promptly when it is no longer required. The procedure applies to all employees, contractors, temporary staff, interns and third parties, and to all environments that store, process or transmit organisational or regulated data, including any cardholder data environment (CDE).
2. Guiding Principles: Least Privilege and Need-to-Know
Access is granted on the principles of least privilege and need-to-know: an individual receives only the minimum access required to perform their assigned duties, and no more. Access control systems operate on a default-deny basis — access that is not explicitly authorised is denied. Duties that could enable fraud or error if combined are separated (segregation of duties); where separation is impractical, compensating controls such as independent review or logging are documented and applied. These principles govern every provisioning, modification and review decision described in this procedure.
3. Unique Identity and Authentication
Every user is assigned a unique identifier before any access is granted, so that all actions can be traced to a single accountable individual. Shared, group, generic or default accounts are prohibited for interactive use; where a shared operational account is technically unavoidable, its use is justified in writing, restricted, and its activity is attributable to a named owner. Authentication follows the organisation's authentication standard, including strong passwords or passphrases and multi-factor authentication (MFA) for remote access, administrative access and all access into the cardholder data environment. Non-person (service, system and application) identities are inventoried, owned by a named individual, and managed under the same lifecycle discipline as human accounts.
4. Role-Based Access and Access Profiles
Access is assigned through predefined role-based access profiles rather than ad-hoc, per-user grants wherever practical. Each profile maps a job function to the specific systems, applications and permission levels that function legitimately requires, and is approved by the relevant system or data owner before use. Role profiles are documented in an access matrix, version-controlled, and reviewed whenever a role's responsibilities change. Requests that fall outside an approved profile are treated as exceptions and require additional, documented justification and approval.
5. Joiner: Provisioning New Access
New access is initiated by a formal, recorded request that identifies the individual, the systems or data required, the business justification and the role profile requested. Each request is authorised by the requesting employee's line manager together with the relevant system or data owner before any credentials are issued or entitlements enabled. The registration and authorisation of the user is completed before system credentials are provided. Provisioning is performed only against the approved request; the individual is issued unique credentials, prompted to set a private secret, and enrolled in MFA where applicable. The approval record, the entitlements granted and the date of activation are retained as evidence.
6. Mover: Role and Access Changes
When an individual changes role, team, department or engagement, their access is re-evaluated rather than simply extended. The receiving line manager submits a change request; entitlements that are no longer required for the new role are removed, and any additional entitlements are requested and approved through the standard provisioning workflow described in Clause 5. Access is not accumulated across successive roles ('privilege creep'); the outcome of a mover event is an entitlement set that matches only the current role. All additions and removals arising from the change are recorded with their approvals and effective dates.
7. Leaver: De-Provisioning on Departure
On termination, resignation, end of contract or any other departure, all logical and physical access for the individual is revoked or disabled on the same business day as the effective leaving date. Human Resources or the engaging manager notifies the IAM/IT function of the leaving date in advance wherever possible; for involuntary or high-risk departures, access is disabled immediately upon instruction. De-provisioning covers all accounts and access paths, including directory accounts, application entitlements, remote access, privileged accounts, physical access tokens, and any shared secrets known to the individual, which are rotated. Completion of de-provisioning is recorded against each departing individual as evidence, and returned or disabled assets are logged.
8. Privileged and Administrative Access
Privileged access — including administrator, root, domain, database, hypervisor and equivalent high-impact entitlements — is granted only where a specific role requires it, is kept to the smallest feasible number of individuals, and is separated from each holder's standard day-to-day account. Privileged access is subject to stronger authentication (including MFA), enhanced logging, and, where available, just-in-time or time-bound elevation so that standing privilege is minimised. All grant, modification and removal of privileged access is explicitly approved by the relevant system owner and CISO , and privileged sessions and actions are monitored and retained for review.
9. Temporary, Time-Bound and Third-Party Access
Access granted for a fixed engagement, project, secondment or supplier task is provisioned with a defined expiry date and is automatically disabled or flagged for removal on that date. Temporary and third-party access follows the same approval, least-privilege and unique-identity requirements as permanent access, is limited to the specific systems the task requires, and is owned by an internal sponsor accountable for its ongoing appropriateness and timely removal.
10. Periodic Access Recertification
System and data owners formally review and recertify the access held by their users every quarter (at least once every ninety (90) days), and privileged access is reviewed at least as frequently. Each review confirms that every entitlement remains justified by a current business need and role, and identifies access to be removed or corrected. Where a regulated cardholder data environment is in scope, user accounts and access privileges are reviewed at least once every six months in line with PCI DSS. Every review produces a dated artefact recording who was reviewed, who approved continued access, and what changes were made; identified changes are actioned through the standard provisioning workflow and tracked to completion.
11. Break-Glass and Emergency Access
Where an urgent operational need requires access outside the normal approval workflow, a controlled break-glass procedure is used. Emergency credentials are pre-provisioned, stored securely, and released only on documented authorisation for a defined, time-limited purpose. Every break-glass use is logged in real time, its justification recorded, and the credentials are rotated and the access revoked immediately after use. All break-glass events are reviewed after the fact by CISO to confirm the invocation was legitimate and that no residual access remains.
12. Roles and Responsibilities
Line managers are accountable for requesting appropriate access, initiating mover changes and notifying HR/IT of departures. System and data owners approve access to their assets and perform recertification. The IAM/IT function executes provisioning, changes and de-provisioning against approved requests and maintains the access records. Human Resources provides timely joiner, role-change and leaver notifications. The Procedure Owner (CISO ) maintains this procedure, monitors adherence, and reports exceptions to management.
13. Evidence, Records and Retention
The following records are maintained to demonstrate the operation of this procedure and to satisfy audit requests. Records are retained for the period defined in the organisation's records-retention schedule and made available to internal and external auditors on request.
Lifecycle Event Evidence Retained Owner Joiner provisioning Approved access request, entitlements granted, activation date IAM / IT Mover / role change Change request, additions and removals, approvals IAM / IT Leaver de-provisioning Departure notice, revocation timestamp against SLA IAM / IT + HR Privileged access Approval record, session/activity logs System owner Recertification review Dated review artefact, approvals, actioned changes System / data owner Break-glass invocation Authorisation, activity log, post-use rotation record Procedure Owner
14. Review and Maintenance of this Procedure
This procedure is reviewed at least annually and additionally whenever there is a material change to the organisation's systems, structure, regulatory obligations or the frameworks referenced. Changes are approved by the Procedure Owner and communicated to all affected personnel. Non-compliance with this procedure may result in disciplinary action in accordance with the organisation's applicable policies.
Approved by
Head of Information Security
______________________
Title
CISO
______________________