Employee Role Change Checklist

1. Purpose

The Employee Role Change Checklist provides a structured process for securely managing changes to an employee’s role, responsibilities, department, employment status, or level of system access.

The objective is to ensure that:

Access required for the new role is identified
Unnecessary previous access is removed
Privileged access is appropriately controlled
Information access matches the new responsibilities
Conflicting access is identified
Security responsibilities are updated
Required training is completed
Cloud, production, source-code, database, and SaaS access are reviewed
Business ownership is transferred where required
Evidence of the role change is retained

Core Principle

Identify Change → Assess Risk → Review Existing Access → Approve New Access → Remove Unnecessary Access → Provision Required Access → Update Responsibilities → Validate → Record → Monitor

2. When to Use

Use this checklist when an employee:

☐ Changes department
☐ Receives a promotion
☐ Moves to another position
☐ Changes responsibilities
☐ Receives additional system access
☐ Loses responsibilities
☐ Moves into a management role
☐ Moves into a security-sensitive role
☐ Receives privileged access
☐ Receives production access
☐ Receives cloud/AWS access
☐ Receives source-code access
☐ Moves from technical to non-technical work
☐ Moves from non-technical to technical work
☐ Changes employment status
☐ Takes a temporary assignment
☐ Returns from extended leave
☐ Changes location or working arrangement
☐ Other: __________________________

3. Employee Role Change Information

Field	Details
Employee Name
Employee ID
Current Role
New Role
Current Department
New Department
Current Manager
New Manager
Change Type
Effective Date
Risk Level
Checklist ID
HR Owner
Manager
IT Owner
Security Reviewer
Completion Date

4. Role Change Type

☐ Promotion
☐ Internal transfer
☐ Department transfer
☐ Change of responsibilities
☐ Temporary assignment
☐ Management change
☐ Technical role change
☐ Security role change
☐ Privileged role assignment
☐ Project assignment
☐ Return from leave
☐ Employment-status change
☐ Other: __________________________

5. Role Change Risk Assessment

Assess whether the new role introduces additional security risk.

Information Risk

☐ Customer data
☐ Personal data
☐ Financial information
☐ Confidential information
☐ Restricted information
☐ Source code
☐ Security information
☐ Credentials/secrets

Access Risk

☐ Privileged access
☐ Production access
☐ AWS/cloud access
☐ Database access
☐ Source-code access
☐ CI/CD access
☐ Security-tool access
☐ Administrative access

Business Risk

☐ Critical business process
☐ Customer-facing responsibility
☐ Financial responsibility
☐ Security responsibility
☐ Regulatory responsibility
☐ Business continuity responsibility

Risk Level

☐ Low
☐ Medium
☐ High
☐ Critical

Risk Rationale

6. Role Definition

Document the new role.

Current Role:

New Role:

New Responsibilities:

Responsibilities Removed:

Effective Date:

The role description should clearly identify responsibilities that affect information security.

7. Existing Access Review

Review all access currently held by the employee.

☐ Corporate identity
☐ Email
☐ VPN
☐ MFA
☐ SSO
☐ AWS/cloud
☐ GitHub/GitLab/Bitbucket
☐ CI/CD
☐ Production systems
☐ Databases
☐ SaaS applications
☐ CRM
☐ Finance systems
☐ HR systems
☐ Security tools
☐ Monitoring systems
☐ Ticketing systems
☐ Password manager
☐ Physical access
☐ Other systems

Existing Access Review

System	Existing Access	Required in New Role?	Action
		☐ Yes ☐ No
		☐ Yes ☐ No
		☐ Yes ☐ No

8. Remove Unnecessary Previous Access

Before granting new access, identify access that is no longer required.

☐ Previous department access reviewed
☐ Previous project access reviewed
☐ Previous application access reviewed
☐ Previous privileged access reviewed
☐ Previous production access reviewed
☐ Previous cloud access reviewed
☐ Previous source-code access reviewed
☐ Previous customer access reviewed
☐ Previous supplier access reviewed
☐ Unnecessary access removed

Access Removed

System	Access Removed	Date	Verified By

9. New Access Requirements

Document the access required for the new role.

System	Environment	Access Required	Privileged	Business Justification
			☐
			☐
			☐

Access should be limited to what is necessary for the employee’s new responsibilities.

10. Manager Approval

The manager should confirm that the requested access is required.

☐ New role confirmed
☐ Responsibilities confirmed
☐ Access requirements reviewed
☐ Existing access reviewed
☐ Unnecessary access identified
☐ New access justified
☐ Access level appropriate
☐ Privileged access justified where applicable

Manager: __________________________

Approval Date: ____________________

Comments:

11. Segregation of Duties

Determine whether the new role creates conflicting responsibilities.

Consider combinations such as:

Request and approve
Develop and deploy
Create and authorize payments
Administer and audit
Configure and independently review
Approve and execute
Security administration and security assurance

☐ No conflict identified
☐ Potential conflict identified
☐ Compensating control required
☐ Exception approved

Conflict Details

12. Privileged Access

If the new role requires privileged access:

☐ Business justification documented
☐ Specific permissions identified
☐ Manager approval obtained
☐ System-owner approval obtained
☐ Security approval obtained where required
☐ Named account used
☐ MFA enabled
☐ Least privilege applied
☐ Privileged access logging enabled
☐ Access review frequency defined
☐ Expiry defined where practical

Privileged Access

System	Privilege	Justification	Approved By	Review Frequency

13. AWS / Cloud Access

If the new role requires cloud access:

☐ AWS account identified
☐ IAM role identified
☐ Required permissions defined
☐ Previous AWS permissions reviewed
☐ Unnecessary permissions removed
☐ New permissions approved
☐ MFA enabled
☐ Privileged access controlled
☐ Production permissions separately assessed
☐ Cloud logging enabled where appropriate
☐ Access verified

AWS Access

AWS Account	Role/Permission	Environment	Action

14. Production Access

If the new role requires production access:

☐ Business requirement documented
☐ Production systems identified
☐ Access scope defined
☐ Named account required
☐ MFA enabled
☐ Privileged access reviewed
☐ Logging enabled
☐ Access approval obtained
☐ Emergency access requirements considered
☐ Periodic review defined

Production access should not be granted simply because the employee previously had access or because the new role is senior.

15. Source-Code Access

For development or engineering role changes:

☐ Repository access reviewed
☐ New repositories identified
☐ Previous repositories reviewed
☐ Organization membership updated
☐ Branch permissions reviewed
☐ Code-owner responsibilities updated
☐ CI/CD access reviewed
☐ Deployment permissions reviewed
☐ Code-signing access reviewed
☐ Personal access tokens reviewed

16. Database Access

If database access changes:

☐ Databases identified
☐ Read/write requirements identified
☐ Production access assessed
☐ Administrative access assessed
☐ Direct database access justified
☐ Previous permissions removed where unnecessary
☐ New permissions approved
☐ Database activity logging enabled where appropriate

17. SaaS Applications

Review applications affected by the role change.

Application	Previous Role	New Access	Action

Consider:

☐ CRM
☐ ERP
☐ HR systems
☐ Finance systems
☐ Project-management tools
☐ Security platforms
☐ Customer-support tools
☐ Collaboration tools
☐ Password managers
☐ Marketing systems
☐ Analytics platforms

18. Physical Access

Review physical access associated with the new role.

☐ Office access reviewed
☐ Restricted-area access reviewed
☐ Data-center access reviewed
☐ Secure-area access reviewed
☐ New access approved
☐ Previous unnecessary access removed
☐ Access card updated where necessary
☐ Physical-access responsibilities updated

19. Information Access

Determine what information the employee should access in the new role.

Information Type	Classification	Previous Access	New Access	Action

Verify that access aligns with:

Business need
Information classification
Role responsibilities
Least privilege
Need-to-know
Regulatory requirements
Customer requirements

20. Security Responsibilities

Update the employee’s security responsibilities.

☐ Security responsibilities reviewed
☐ Policy responsibilities updated
☐ Incident-reporting responsibility updated
☐ Business continuity responsibility updated
☐ Supplier-security responsibility updated
☐ Risk-management responsibility updated
☐ Asset ownership updated
☐ System ownership updated
☐ Security contact information updated

21. Training Requirements

Determine whether the new role requires additional training.

☐ General security awareness current
☐ Role-specific training identified
☐ Privileged-access training required
☐ Cloud security training required
☐ Secure-development training required
☐ Incident-response training required
☐ Privacy/data-protection training required
☐ AI-security training required
☐ Business continuity training required
☐ Regulatory training required

Training Required

Training	Required	Due Date	Completed
	☐		☐
	☐		☐

22. Screening Requirements

If the new role is significantly more sensitive:

☐ Role risk reassessed
☐ Screening requirements reviewed
☐ Additional verification required
☐ Authorization obtained
☐ Screening completed where required
☐ Screening evidence protected

Examples may include roles with:

Privileged access
Production access
Financial authority
Security administration
Sensitive personal data
Restricted information
Critical infrastructure responsibility

Screening should be lawful, proportionate, and appropriate to the role.

23. Confidentiality Requirements

Review whether the new role changes confidentiality obligations.

☐ Confidentiality requirements reviewed
☐ NDA/confidentiality agreement remains applicable
☐ Additional confidentiality requirements identified
☐ Customer confidentiality requirements reviewed
☐ Restricted information responsibilities communicated
☐ Intellectual-property responsibilities reviewed

24. Asset Ownership

Review assets assigned to the employee.

☐ Laptop
☐ Mobile device
☐ Security key
☐ Hardware token
☐ Development equipment
☐ Administrative workstation
☐ Other equipment

Asset Changes

Asset	Previous Responsibility	New Responsibility	Action

25. Customer and Supplier Responsibilities

If the role change affects external relationships:

☐ Customer responsibilities transferred
☐ Supplier responsibilities transferred
☐ Customer portal access reviewed
☐ Supplier portal access reviewed
☐ External administrator access reviewed
☐ Contact information updated
☐ Business owner updated

26. Business Continuity Responsibilities

If the employee has continuity responsibilities:

☐ BCP role reviewed
☐ Disaster recovery role reviewed
☐ Incident-response role reviewed
☐ Emergency contact information updated
☐ Recovery responsibilities updated
☐ Alternate person identified
☐ Key-person dependency assessed

27. Incident Response Responsibilities

If the new role participates in incident response:

☐ Incident-response role defined
☐ Escalation responsibility updated
☐ Incident communication responsibility updated
☐ Evidence-handling responsibility reviewed
☐ Emergency access reviewed
☐ Contact information updated
☐ Incident-response training completed

28. Access Provisioning

After approval:

☐ New account created where required
☐ Existing account permissions updated
☐ MFA configured
☐ Least privilege applied
☐ Privileged access separately approved
☐ Cloud access provisioned
☐ SaaS access provisioned
☐ Source-code access provisioned
☐ Production access provisioned only where approved
☐ Physical access updated

29. Access Validation

After changes are implemented:

☐ Employee can access required systems
☐ Employee cannot access unnecessary systems
☐ Privileges match approval
☐ MFA works
☐ Cloud permissions match approval
☐ Production permissions match approval
☐ Source-code permissions match approval
☐ SaaS permissions match approval
☐ Physical access matches role

Validation Result

☐ Successful
☐ Exceptions identified

Validation Evidence

30. Second-Person Verification

For sensitive or high-risk role changes, perform independent verification where practical.

☐ Access changes reviewed by second person
☐ Privileged access verified
☐ Production access verified
☐ Cloud access verified
☐ Source-code access verified
☐ Unnecessary previous access verified as removed
☐ Segregation-of-duties reviewed

Verifier: __________________________

Date: __________________________

Result: ☐ Approved ☐ Exceptions

31. Exceptions

Document any deviation from the approved role-change process.

Exception	Reason	Risk	Compensating Control	Owner	Due Date	Status

Exceptions should be formally approved according to the organization’s risk and exception-management process.

32. Role Change Completion Record

Activity	Completed	Verified By
Role change approved	☐
Risk assessed	☐
Existing access reviewed	☐
Unnecessary access removed	☐
New access approved	☐
New access provisioned	☐
Privileged access reviewed	☐
Cloud access reviewed	☐
Production access reviewed	☐
Source-code access reviewed	☐
SaaS access reviewed	☐
Information access reviewed	☐
Security responsibilities updated	☐
Training completed	☐
Physical access updated	☐
Business ownership updated	☐
Final validation completed	☐

33. Role Change Register

Maintain a record of significant role changes.

Employee ID	Old Role	New Role	Effective Date	Risk	Access Updated	Verified
					☐	☐
					☐	☐

34. Completion Criteria

The role change should not be marked Complete until:

☐ New role is formally approved
☐ Security risk has been assessed
☐ Existing access has been reviewed
☐ Unnecessary access has been removed
☐ New access has been approved
☐ New access has been provisioned
☐ Privileged access has been separately reviewed
☐ Cloud/AWS access has been reviewed
☐ Production access has been reviewed
☐ Source-code access has been reviewed
☐ Information access matches the new role
☐ Security responsibilities have been updated
☐ Required training has been identified/completed
☐ Segregation-of-duties risks have been assessed
☐ Physical access has been reviewed
☐ Business ownership has been transferred where required
☐ Access validation has been completed
☐ Exceptions have been documented
☐ Evidence has been retained

35. Final Approval

Employee: ______________________________

Previous Role: ______________________________

New Role: ______________________________

Manager: ______________________________

HR Representative: ______________________________

IT Representative: ______________________________

Security Reviewer: ______________________________

Effective Date: ______________________________

Completion Date: ______________________________

Status

☐ Complete
☐ Complete with Approved Exceptions
☐ Further Action Required

Comments

36. AWS SaaS Startup Example

A SaaS startup promotes a Software Engineer to Engineering Manager.

The employee previously had:

AWS development access
GitHub repository access
CI/CD access
Development database access
Jira
Slack

The new role additionally requires:

Team management
Production-read access
Security incident participation
AWS infrastructure visibility
Code-review responsibilities

Role Change Process

1. Manager → documents the new responsibilities.

2. Security → performs a risk assessment.

3. IT/Security → reviews existing development access.

4. Engineering → removes repositories and permissions no longer required.

5. Cloud Owner → approves the required AWS roles.

6. Security → verifies that production access is read-only unless elevated access is justified.

7. HR/Manager → updates the employee’s responsibilities.

8. Training → assigns incident-response and management/security training where required.

9. Reviewer → independently validates the final access configuration.

Audit Trail

Role Change → Risk Assessment → Existing Access Review → Remove Old Access → Approve New Access → Provision → Validate → Record

37. Startup-Friendly Role Change Model

A startup can implement a lightweight process:

1. Tell IT/Security

HR or the manager communicates the role change.

2. Compare Old vs New Role

Ask:

What access is no longer required?
What new access is required?

3. Remove Old Access

Do not simply add new permissions on top of existing permissions.

4. Approve New Access

Manager/system owner approves the business need.

5. Provision

IT grants only the required access.

6. Verify

Check AWS, GitHub, SaaS, production, database, VPN, and other relevant systems.

7. Record

Keep the approval and evidence.

This prevents access accumulation, where employees gradually collect permissions as they move through the organization.

38. Common Mistakes

Avoid:

Adding new access without reviewing old access.
Assuming promotions automatically justify administrator access.
Forgetting previous department permissions.
Forgetting AWS/cloud access.
Forgetting GitHub/GitLab access.
Forgetting production access.
Forgetting database permissions.
Forgetting SaaS applications.
Ignoring segregation-of-duties conflicts.
Granting broad access because someone is a manager.
Failing to update security responsibilities.
Failing to update BCP/incident-response responsibilities.
Failing to provide role-specific training.
Not reviewing physical access.
Not documenting approval.
Not validating the final permissions.
Allowing temporary access to become permanent.
Treating role changes as simple HR changes rather than security events.

39. Relationship With Other ISMS Documents

Document	Relationship
Human Resources Security Policy	Defines personnel-security requirements
Joiner-Mover-Leaver Procedure	Manages employee lifecycle changes
Access Management Procedure	Controls access changes
Employee Onboarding Checklist	Handles initial access
Employee Offboarding Policy	Handles termination
Privileged User Management Procedure	Controls privileged access
Cloud Access Review Checklist	Reviews cloud permissions
Source Code Access Review Checklist	Reviews development permissions
Role-Based Security Responsibilities Matrix	Defines responsibilities by role
Role-Based Security Training Matrix	Defines training requirements
Information Classification Policy	Determines information access
Segregation of Duties Matrix	Identifies conflicting responsibilities
Access Review Procedure	Performs periodic access validation
Risk Register	Tracks significant risks
Information Security Exception Register	Records approved deviations

40. ISO 27001 Connection

Employee role changes are relevant to the organization’s management of access rights, authentication, information protection, personnel responsibilities, privileged access, and segregation of duties.

The Employee Role Change Checklist is not itself a universally mandatory ISO 27001 form. The organization should establish appropriate processes based on:

ISMS scope
Risk assessment
Employee responsibilities
Information classification
System access
Privileged access
Legal/regulatory requirements
Customer requirements
Contractual requirements
Business requirements

A role change should therefore be treated as a potential security-relevant change, not merely an HR record update.

41. Final Audit Checklist

☐ Role change formally approved
☐ Previous role documented
☐ New role documented
☐ Effective date recorded
☐ Risk assessed
☐ Existing access inventoried
☐ Unnecessary previous access removed
☐ New access requirements documented
☐ Manager approval obtained
☐ System-owner approval obtained where required
☐ Privileged access assessed
☐ AWS/cloud access assessed
☐ Production access assessed
☐ Database access assessed
☐ Source-code access assessed
☐ CI/CD access assessed
☐ SaaS access assessed
☐ Information access assessed
☐ Segregation of duties assessed
☐ Security responsibilities updated
☐ Training requirements assessed
☐ Screening requirements assessed where applicable
☐ Physical access reviewed
☐ Customer/supplier responsibilities reviewed
☐ BCP/DR responsibilities updated
☐ Incident-response responsibilities updated
☐ New access provisioned
☐ Access validated
☐ Second-person verification completed where required
☐ Exceptions documented
☐ Evidence retained
☐ Role change closed

42. Final Audit Trail

For every significant employee role change, the organization should be able to demonstrate:

What changed?
When did the change become effective?
What was the employee’s previous role?
What is the new role?
What information does the new role require?
What access did the employee already have?
What access was no longer required?
What new access was required?
Who approved the new access?
Was privileged access assessed?
Was AWS/cloud access assessed?
Was production access assessed?
Was source-code/database/SaaS access assessed?
Were segregation-of-duties risks considered?
Were security responsibilities updated?
Was required training completed?
Was the final access configuration validated?
Who verified the change?
Were exceptions documented?
What evidence proves the change was completed correctly?

Final Principle

A role change is not complete when the employee receives a new title. It is complete when unnecessary access has been removed, required access has been appropriately approved and provisioned, security responsibilities have been updated, conflicts and risks have been addressed, and the final state has been verified and recorded.