Joiner-Mover-Leaver (JML) Procedure

1. Purpose

The Joiner-Mover-Leaver (JML) Procedure defines how the organization manages information security access and responsibilities when a person:

• Joins the organization
• Changes role or responsibilities
• Leaves the organization

The objective is to ensure that users receive the right access when needed, have unnecessary access removed when their role changes, and lose organizational access when their employment or engagement ends.

Core Principle

Join → Provision → Review → Move → Adjust → Leave → Revoke → Verify → Evidence

---

2. Scope

This procedure applies to:

• Employees
• Contractors
• Consultants
• Interns
• Temporary workers
• Third-party personnel
• Other authorized users

It covers:

• Corporate accounts
• Identity/SSO
• Email
• SaaS applications
• AWS/Azure/GCP
• Source-code repositories
• Databases
• VPN/remote access
• Security systems
• Customer systems
• Physical access
• IT assets
• Information and data
• Privileged access
• API keys, tokens, certificates and SSH keys

---

3. Definitions

Joiner

A person who is newly authorized to work for or on behalf of the organization.

Mover

A person whose role, department, project, responsibilities, or level of access changes.

Leaver

A person whose employment, contract, engagement, or authorization ends.

Privileged Access

Access that allows administrative, security-sensitive, configuration, or high-impact activities.

---

4. JML Lifecycle

Joiner

HR/Contract Notification → Role Definition → Access Requirements → Approval → Provision → Verify → Record

Mover

Role Change → Review Existing Access → Remove Unnecessary Access → Approve New Access → Provision → Verify → Record

Leaver

Exit Notification → Identify Access/Assets → Revoke Access → Collect Assets → Transfer Responsibilities → Verify → Update Records → Close

---

5. Roles and Responsibilities

Role	Responsibility
HR/People Team	Notify joiner/mover/leaver events
Manager	Define business role and required access
System/Application Owner	Approve system access
Data Owner	Approve sensitive information access where required
IT/IAM	Provision and revoke accounts/access
Security/ISMS	Review security-sensitive and privileged access
Asset Owner	Confirm organizational assets
Finance/Procurement	Address financial/vendor-related matters where applicable
Employee/Contractor	Return assets and protect organizational information
Internal Audit	Independently verify JML controls

---

6. Joiner Procedure

Step 1 – Receive Joiner Notification

HR or the responsible business function provides:

• User name
• Employee/contractor ID
• Department
• Job title
• Manager
• Employment/engagement type
• Start date
• Expected end date, if applicable
• Business role

For contractors and third parties, the contract/SOW should also be considered.

---

7. Define the Joiner’s Role

The manager identifies the standard business role.

Example:

Customer Support Agent

rather than:

“Give access to all customer systems.”

The role should be mapped to the organization’s Access Control Matrix.

---

8. Identify Required Access

Determine:

• Applications
• SaaS platforms
• Email
• Collaboration tools
• Cloud environments
• Source-code repositories
• Databases
• VPN
• Customer systems
• Physical facilities
• Security tools

Access should be based on actual job responsibilities.

---

9. Submit Access Requests

Required access should be requested through the approved User Access Request process.

Each request should identify:

• User
• System
• Role
• Access level
• Business purpose
• Data classification
• Environment
• Start date
• Expiry date where applicable

---

10. Joiner Approval

Obtain appropriate approval before provisioning.

Typical flow:

Manager → System/Application Owner → Data Owner/Security where required

Privileged and high-risk access should receive additional review.

---

11. Provision Joiner Access

IT/IAM provisions approved access.

Check:

• Correct user identity
• Correct account
• Correct role
• Least privilege
• MFA enabled
• Required security controls configured
• Logging enabled where required
• Temporary access expiry configured where applicable

---

12. Joiner Security Onboarding

Before or shortly after access is provided, complete appropriate security awareness activities.

Topics may include:

• Information Security Policy
• Acceptable Use
• Password/MFA
• Information Classification
• Information Transfer
• Incident Reporting
• Remote Working
• AI Acceptable Use
• Data Handling
• Phishing/Social Engineering

Training should be appropriate to the user’s role.

---

13. Joiner Asset Allocation

Where applicable:

• Laptop
• Mobile device
• Security key
• Access card
• Headset
• Monitor
• Other IT equipment

Record assigned assets in the Information & Asset Inventory or appropriate asset register.

Use the IT Asset Handover Form where applicable.

---

14. Joiner Verification

After onboarding:

• Required accounts created
• Required access provisioned
• MFA enabled
• Access matches approved request
• No unnecessary privileged access
• Assets assigned
• Security training completed
• Evidence recorded

---

15. Mover Procedure

A mover event occurs when a person:

• Changes department
• Changes job role
• Changes manager/responsibilities
• Changes project
• Takes on additional responsibilities
• Loses responsibilities
• Moves into or out of a privileged role

---

16. Mover Notification

HR or the manager should notify the relevant IT/IAM and system owners.

Record:

• Current role
• New role
• Effective date
• Previous department
• New department
• Previous access
• New access requirements

---

17. Review Existing Access

Before adding new access:

Current Role → Existing Access → New Role → Required Access

Identify:

• Access to remove
• Access to retain
• Access to add
• Privileged access changes
• SoD conflicts
• Production access changes

---

18. Mover Access Adjustment

Example

An employee moves from:

Engineering → Customer Support

Review and potentially remove:

• Source-code write access
• CI/CD administration
• AWS development access
• Engineering collaboration tools

Add approved:

• Customer support platform
• CRM access
• Support collaboration tools

---

19. Mover Approval

New access should follow the normal User Access Request process.

The manager/system owner should confirm:

• Business need
• Appropriate permissions
• Least privilege
• Data access
• Production access
• Privileged access
• SoD

---

20. Mover Verification

After changes:

• Old access removed where no longer required
• New access provisioned
• Privileged access reviewed
• MFA remains enabled
• Application roles verified
• Cloud roles verified
• Source-code access verified
• Access records updated
• Evidence retained

Important

Do not simply add new permissions to an existing account. Review and remove permissions that are no longer required.

---

21. Leaver Procedure

A leaver may include:

• Resignation
• Termination
• Contract expiry
• Project completion
• Supplier personnel replacement
• End of temporary engagement
• Retirement
• Other authorization termination

---

22. Leaver Notification

HR or the responsible business owner should notify IT/IAM and relevant stakeholders.

The notification should include:

• User name
• User ID
• Department
• Manager
• Last working/engagement date
• Effective termination time
• Immediate termination requirement, if applicable
• Systems/assets involved

For high-risk or involuntary termination, access may need to be revoked at the time specified by authorized management/HR rather than waiting for the end of the working day.

---

23. Identify All User Access

Review:

• Email
• SSO/identity provider
• SaaS applications
• AWS/Azure/GCP
• Source-code repositories
• Databases
• VPN
• Security platforms
• Customer systems
• File-sharing platforms
• Production systems
• Privileged accounts
• API keys
• SSH keys
• Tokens
• Certificates
• Physical access

---

24. Revoke Digital Access

Disable or revoke:

• Corporate account
• SSO
• Email
• VPN
• SaaS
• AWS/cloud
• Source code
• Database
• Security platforms
• Customer systems
• API keys
• SSH keys
• Tokens
• Active sessions where appropriate

Important

Disabling the corporate email account alone does not constitute complete offboarding.

---

25. Privileged Access Revocation

For privileged users, specifically verify:

• AWS administrator access
• IAM administration
• Database administration
• Security administration
• Source-code administration
• CI/CD administration
• Identity administration
• Backup administration
• Secrets-management access

Update the Privileged Access Register.

---

26. Asset Return

Collect organizational assets such as:

• Laptop
• Desktop
• Mobile
• Tablet
• Security keys
• USB devices
• Access cards
• Office keys
• SIM cards
• Monitors
• Other assigned equipment

Use the Asset Return Checklist and IT Asset Handover Form where applicable.

---

27. Information and Data Handover

Before closing the leaver process:

Identify business information owned or managed by the departing user.

Examples:

• Customer records
• Project files
• Source code
• Contracts
• Reports
• Security documentation
• Emails
• Business records
• Credentials/secrets under their responsibility

Transfer ownership to an authorized person.

Do not simply delete business information without considering retention and business requirements.

---

28. Source-Code and Development Handover

For developers:

• Repository access revoked
• Open pull requests reviewed
• Code ownership transferred
• Deployment responsibilities transferred
• CI/CD access revoked
• SSH keys reviewed
• Personal access tokens revoked
• Project secrets reviewed
• Outstanding technical responsibilities transferred

---

29. AWS/Cloud Offboarding

For users with cloud access:

• SSO access revoked
• IAM roles removed
• IAM groups removed
• Access keys revoked
• Temporary credentials invalidated where applicable
• SSH keys reviewed
• Production access removed
• Cross-account access removed
• Cloud console access removed
• Privileged access register updated
• Relevant logs/evidence retained

---

30. SaaS Offboarding

Review all critical SaaS applications.

Examples:

• Microsoft 365/Google Workspace
• GitHub
• Jira
• CRM
• HR platform
• Finance system
• Customer support
• Security tools
• Cloud management platforms

For each:

Disable → Revoke → Transfer Ownership → Verify → Record

---

31. Physical Access

Where applicable, revoke:

• Building access card
• Office keys
• Server-room access
• Data-center access
• Security tokens
• Physical storage access

Confirm with Facilities/Security where applicable.

---

32. BYOD and Remote Workers

For personally owned devices:

• Remove organizational accounts
• Revoke organizational access
• Remove managed application access where applicable
• Revoke certificates/tokens
• Remove corporate profiles where applicable
• Confirm organizational information is returned/deleted where required
• Consider privacy requirements before performing device actions

---

33. Confidentiality and Information Protection

Leavers remain subject to applicable contractual and confidentiality obligations.

Remind departing personnel of:

• Confidentiality obligations
• Intellectual property requirements
• Customer information protection
• Return of organizational information
• Restrictions on unauthorized use/disclosure
• Continuing contractual obligations where applicable

---

34. Leaver Verification

The responsible reviewer should verify:

• All critical accounts disabled
• Privileged access revoked
• Cloud access revoked
• SaaS access revoked
• Source-code access revoked
• API keys/tokens reviewed
• Physical access revoked
• Assets returned
• Information transferred
• Ownership transferred
• Asset register updated
• Access records updated
• Evidence retained

---

35. JML Completion Record

Field	Details
JML ID
User
Event Type	Joiner / Mover / Leaver
Effective Date
Manager
HR/Business Owner
IT/IAM Owner
Security Reviewer
Systems Reviewed
Access Changes
Assets
Information Handover
Privileged Access Reviewed	Yes / No
Completion Date
Exceptions
Evidence
Status	Open / Complete

---

36. Exceptions

If any JML activity cannot be completed:

Exception	Reason	Risk	Compensating Control	Owner	Due Date	Status

Exceptions should be:

• Documented
• Risk assessed
• Approved
• Assigned an owner
• Given a target date
• Tracked to closure

---

37. Emergency Leaver

For situations requiring immediate access removal:

Notification → Immediate Account Disablement → Revoke Sessions → Revoke Privileged Access → Revoke Cloud/SaaS Access → Revoke Credentials/Tokens → Collect Assets → Preserve Evidence → Investigate if Required → Complete Offboarding

The exact timing should follow authorized HR/management and security procedures.

---

38. JML Evidence

Maintain appropriate evidence such as:

Joiner

• HR onboarding record
• Access requests
• Approvals
• Provisioning records
• Asset handover
• Security training
• MFA configuration

Mover

• Role-change notification
• Access review
• Access removal
• New access approvals
• Provisioning evidence
• SoD review

Leaver

• HR exit notification
• Account-disable records
• Access revocation
• Cloud/IAM evidence
• SaaS revocation
• Asset return
• Data/ownership handover
• Credential/token revocation
• Final JML checklist

---

39. JML Control Matrix

Activity	Joiner	Mover	Leaver
Identity verification	✓	✓	✓
Role verification	✓	✓	✓
Access assessment	✓	✓	✓
Manager approval	✓	✓	Where required
System owner approval	✓	✓	—
Privileged access review	✓	✓	✓
MFA	✓	✓	Revoke
SaaS access	Provision	Modify	Revoke
Cloud access	Provision	Modify	Revoke
Source-code access	Provision	Modify	Revoke
Asset management	Assign	Transfer	Return
Information ownership	Assign	Transfer	Transfer
Security awareness	✓	As required	Exit reminder
Access verification	✓	✓	✓
Evidence	✓	✓	✓

---

40. Startup-Friendly JML Workflow

For a small SaaS company, keep the process simple:

JOINER

HR → Manager → Access Matrix → Approval → IT/IAM → MFA → Security Training → Verify

MOVER

Role Change → Review Existing Access → Remove Old Access → Approve New Access → Provision → Verify

LEAVER

HR → Identify Access → Disable/Revoke → Cloud/SaaS/Code → Collect Assets → Transfer Information → Verify → Close

---

41. Relationship with Other ISMS Documents

The JML Procedure connects directly with:

• Access Control Policy
• Access Control Matrix
• User Access Request
• User Access Review Checklist
• Privileged Access Register
• Access Revocation Checklist
• Employee Offboarding Checklist
• Contractor Offboarding Checklist
• Asset Return Checklist
• IT Asset Handover Form
• Information & Asset Inventory
• Asset Ownership Register
• Cloud Asset Inventory
• SaaS Application Register
• Information Classification Policy
• Segregation of Duties Policy
• Security Awareness Training
• Incident Response Plan
• Risk Register

Complete Lifecycle

Role → Access Need → Request → Approval → Provision → Review → Change → Revoke → Verify → Evidence

---

42. ISO 27001 Connection

The JML process supports applicable ISO/IEC 27001 requirements relating to:

• Identity management
• Authentication
• Access rights
• Access restriction
• Privileged access
• Segregation of duties
• Return of organizational assets
• Information classification
• Employee/contractor responsibilities
• Secure access lifecycle management

The exact controls applicable to the organization should be determined through its risk assessment and Statement of Applicability (SoA).

---

43. Final Audit Trail

An auditor should be able to select a user and trace:

Joiner

Who joined → What role → What access was needed → Who approved → What was provisioned → Was it verified?

Mover

What changed → What old access was removed → What new access was approved → What was provisioned → Was it verified?

Leaver

When did authorization end → What access existed → What was revoked → What assets were returned → What information was transferred → Was completion verified?

Final Principle

Give people the access they need when they join, reassess and adjust access when their role changes, and promptly revoke access and recover organizational assets when their authorization ends. Every JML event should leave a clear, verifiable audit trail.