Employee Role Change Checklist

1. Purpose

The Employee Role Change Checklist provides a structured process for managing security requirements when an employee changes role, department, responsibilities, location, reporting line, or level of system access.

The objective is to ensure that:

Previous access is reviewed
New access is appropriately authorized
Excess access is removed
Sensitive responsibilities are reassessed
Security responsibilities are updated
Required training is completed
Privileged access is controlled
Information access remains appropriate
Evidence of the role change is maintained

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
Changes job title
Receives substantially different responsibilities
Moves into a management role
Moves into a security-sensitive role
Receives privileged access
Receives production access
Receives access to customer information
Receives access to personal data
Moves to a finance/HR/compliance role
Moves into an IT/cloud/DevOps role
Moves into a security role
Changes employment location where access requirements change
Changes from temporary to permanent employment
Changes reporting responsibility
Transfers between business units
Takes on additional responsibilities
No longer requires previously assigned access

3. Employee Role Change Information

Field	Details
Employee Name
Employee ID
Current Role
New Role
Current Department
New Department
Current Manager
New Manager
Role Change Date
Effective Date
Reason for Change
Role Risk Level
Reviewer
HR Owner
IT Owner
Security Reviewer
Assessment Status

4. Role Change Type

Select applicable change:

☐ Department transfer
☐ Promotion
☐ Demotion
☐ Internal transfer
☐ Change in responsibilities
☐ Management responsibility change
☐ Security role change
☐ IT role change
☐ Cloud/DevOps role change
☐ Privileged role assignment
☐ Production access assignment
☐ Temporary role assignment
☐ Project-based role change
☐ Location change
☐ Reporting-line change
☐ Other: ______________________

5. Role Change Request

Document the proposed change.

Current Role

New Role

Business Reason

Effective Date

Expected Duration

If the change is temporary:

Temporary Role End Date: __________________

6. Business Need Assessment

Confirm why the new role requires different responsibilities or access.

☐ Business need documented
☐ New responsibilities identified
☐ New systems identified
☐ New information identified
☐ New access requirements identified
☐ Role criticality assessed
☐ Business owner identified
☐ Manager approval obtained

Business Justification

7. Role Risk Assessment

Assess whether the new role creates additional security risk.

Consider:

☐ Sensitive information access
☐ Customer information access
☐ Personal data access
☐ Financial information access
☐ Source-code access
☐ Production access
☐ Database access
☐ Cloud administration
☐ Privileged access
☐ Security-system access
☐ Payment-system access
☐ Regulatory responsibilities
☐ Approval authority
☐ Segregation-of-duties impact

Role Risk

☐ Low
☐ Medium
☐ High
☐ Critical

Risk Assessment

8. Existing Access Review

Review all access associated with the employee’s previous role.

☐ User accounts identified
☐ SaaS applications identified
☐ Cloud accounts identified
☐ VPN access identified
☐ Database access identified
☐ Source-code access identified
☐ CI/CD access identified
☐ Production access identified
☐ Privileged access identified
☐ Shared resources identified
☐ Physical access identified

9. Access to Be Removed

Identify access no longer required.

System	Existing Access	Remove?	Removal Date	Evidence

Access Removal Confirmation

☐ Completed
☐ Not Applicable
☐ Pending

10. New Access Requirements

Document access required for the new role.

System	Environment	Required Access	Privileged	Business Need

Access should follow:

Least privilege
Need-to-know
Role-based access
Segregation of duties
Approved business requirements

11. Access Authorization

Before provisioning new access:

☐ Business owner approval
☐ New manager approval
☐ System owner approval where required
☐ Security approval where required
☐ Privileged access approval where required
☐ Risk assessment completed

No new sensitive or privileged access should be granted solely because an employee has changed roles.

12. Role-Based Access

Verify that the new role is mapped to an approved access profile.

☐ Standard role defined
☐ Role permissions documented
☐ Required applications identified
☐ Required data identified
☐ Required systems identified
☐ Excess permissions removed
☐ Access profile approved

13. Privileged Access Assessment

If the new role requires privileged access:

☐ Privileged access justified
☐ Named account required
☐ MFA enabled
☐ Administrative access restricted
☐ Privileged account separated where appropriate
☐ Logging enabled
☐ Monitoring established
☐ Access review frequency defined
☐ Expiry defined where appropriate

Privileged Access

14. Production Access Assessment

If production access is required:

☐ Business justification documented
☐ Production systems identified
☐ Access scope defined
☐ Named account used
☐ MFA enabled
☐ Privileged access controls applied
☐ Activity logging enabled where appropriate
☐ Emergency access requirements considered
☐ Access review defined

15. AWS / Cloud Access

For employees moving into cloud-related roles:

☐ AWS account(s) identified
☐ IAM role identified
☐ IAM group reviewed
☐ Permissions reviewed
☐ Administrator access assessed
☐ Root account access prohibited unless specifically authorized
☐ MFA enabled
☐ Access keys reviewed
☐ Temporary credentials considered
☐ CloudTrail/logging applicable
☐ Production access reviewed

16. Source-Code Access

For developers, DevOps, security engineers, or technical roles:

☐ Repository access reviewed
☐ Repository ownership identified
☐ Branch permissions reviewed
☐ Pull-request permissions reviewed
☐ Administrative permissions reviewed
☐ CI/CD permissions reviewed
☐ Deployment permissions reviewed
☐ Secrets access reviewed
☐ Unnecessary previous access removed

17. Database Access

Where applicable:

☐ Database identified
☐ Required access defined
☐ Read/write requirement assessed
☐ Administrative access assessed
☐ Production database access assessed
☐ Sensitive-data access assessed
☐ MFA/authentication requirements applied
☐ Logging/monitoring applied where appropriate

18. SaaS Application Access

Review business applications such as:

HR systems
Finance systems
CRM
Ticketing systems
Project management
Collaboration platforms
Security platforms
Compliance platforms
Cloud consoles

☐ Previous role access removed
☐ New role access approved
☐ Administrative access reviewed
☐ Sensitive information access reviewed
☐ MFA enabled where applicable

19. Segregation of Duties

Determine whether the new role creates a conflict with existing responsibilities.

Consider combinations such as:

Request and approve
Create and approve
Develop and independently approve production deployment
Create supplier and approve payment
Create employee and approve payroll
Configure security control and independently validate the control

☐ SoD reviewed
☐ No conflict identified
☐ Conflict identified and controlled
☐ Exception/risk acceptance required

SoD Assessment

20. Information Classification Review

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

☐ Public
☐ Internal
☐ Confidential
☐ Restricted

Information Access

21. Sensitive Information Access

Where applicable:

☐ Customer data
☐ Personal data
☐ Financial information
☐ Employee information
☐ Source code
☐ Security information
☐ Authentication information
☐ Confidential business information
☐ Intellectual property

Confirm that access is appropriate for the new role.

22. Security Screening Review

Determine whether the role change requires additional screening.

Consider:

☐ Privileged role
☐ Security-sensitive role
☐ Financial responsibility
☐ Regulatory responsibility
☐ Production administration
☐ Sensitive customer information
☐ Security administration

☐ Existing screening sufficient
☐ Additional screening required
☐ Screening exception required
☐ Not applicable

23. Security Training Review

Determine whether additional training is required.

☐ General security awareness current
☐ Role-specific training required
☐ Privileged-user training required
☐ Privacy training required
☐ Secure development training required
☐ Cloud-security training required
☐ Incident-response training required
☐ Compliance training required
☐ Customer-specific training required

Training Requirements

24. Security Responsibilities Update

Update the employee’s security responsibilities.

☐ Job description updated
☐ Role-based security responsibilities updated
☐ Manager responsibilities updated
☐ Data-owner responsibilities updated
☐ Privileged-user responsibilities updated
☐ Incident responsibilities updated
☐ Business continuity responsibilities updated

25. Policy and Procedure Applicability

Determine whether additional policies/procedures apply.

☐ Information Security Policy
☐ Acceptable Use Policy
☐ Access Management Policy
☐ Cloud Security Policy
☐ Secure Development Policy
☐ Privacy Policy
☐ Incident Management Procedure
☐ Change Management Procedure
☐ Production Deployment Procedure
☐ Business Continuity Procedure
☐ Other: ______________________

26. Security Acknowledgement

Where required:

☐ Updated responsibilities communicated
☐ Applicable policies provided
☐ Employee acknowledgement completed
☐ New role responsibilities understood
☐ Additional confidentiality requirements acknowledged

Acknowledgement should demonstrate communication/review; it should not be treated as evidence that the employee is actually complying with the requirements.

27. Confidentiality Review

Determine whether the new role creates additional confidentiality obligations.

☐ Existing confidentiality agreement sufficient
☐ Additional confidentiality requirement
☐ Customer-specific confidentiality requirement
☐ Project-specific confidentiality requirement
☐ NDA update required

28. Physical Access

If the new role changes physical access requirements:

☐ Office access reviewed
☐ Secure-area access reviewed
☐ Server-room access reviewed
☐ Restricted-area access reviewed
☐ Previous access removed where unnecessary
☐ New access approved

29. Remote Working Access

If applicable:

☐ Remote access reviewed
☐ VPN access reviewed
☐ Device requirements reviewed
☐ MFA enabled
☐ Privileged remote access reviewed
☐ Security monitoring considered
☐ Additional restrictions applied where required

30. Company Assets

Determine whether the role change requires different assets.

☐ Laptop change
☐ Mobile device change
☐ Security token
☐ Hardware authentication device
☐ Specialized equipment
☐ Other: ______________________

Asset Changes

31. Service Accounts and Machine Access

If the employee manages technical systems:

☐ Service accounts identified
☐ Ownership updated
☐ Administrative responsibility transferred
☐ API credentials reviewed
☐ SSH keys reviewed
☐ Certificates reviewed
☐ Secrets access reviewed
☐ Previous owner removed where appropriate

Employee role changes should not result in undocumented ownership of service accounts or technical credentials.

32. Application and System Ownership

Where responsibilities change:

System/Application	Previous Owner	New Owner	Effective Date

☐ Ownership updated
☐ Documentation updated
☐ Escalation contact updated

33. Data Ownership Changes

Where the employee becomes an information or data owner:

☐ Data ownership defined
☐ Classification reviewed
☐ Access requirements defined
☐ Retention requirements understood
☐ Sharing requirements understood
☐ Security responsibilities communicated

34. Incident Response Responsibilities

Determine whether the new role changes incident responsibilities.

☐ Incident responder
☐ Incident manager
☐ Security escalation contact
☐ Business continuity contact
☐ System owner
☐ Customer communication role
☐ Regulatory escalation role

Updated Responsibility

35. Business Continuity Responsibilities

Where relevant:

☐ Critical process responsibility updated
☐ Recovery responsibility updated
☐ RTO/RPO responsibility understood
☐ Emergency contact updated
☐ DR responsibility updated
☐ Business continuity documentation updated

36. Change Implementation

Implement the approved role change.

☐ Previous access removed
☐ New access provisioned
☐ New permissions validated
☐ MFA verified
☐ Privileged access validated
☐ Production access validated
☐ Application access validated
☐ Physical access updated
☐ Ownership records updated

37. Access Validation

After provisioning, verify actual access.

System	Expected Access	Actual Access	Correct?	Reviewer

☐ Access matches approval
☐ Excess access identified
☐ Excess access removed
☐ Validation evidence retained

38. Role Change Security Testing

Where appropriate:

☐ Login tested
☐ MFA tested
☐ Required application access tested
☐ Privileged access tested
☐ Production access tested
☐ Access restrictions tested
☐ Segregation-of-duties controls validated

Testing should be proportionate to the risk of the role.

39. Role Change Exceptions

Document any deviation.

Exception	Reason	Risk	Compensating Control	Expiry

Exceptions should be documented, risk-assessed, approved, monitored, and time-bound where appropriate.

40. Role Change Findings

Record issues identified during the review.

Finding ID	Area	Finding	Risk	Action	Owner	Due Date

41. Immediate Remediation

If inappropriate access is discovered:

☐ Access disabled
☐ Excess privilege removed
☐ Credentials revoked
☐ Tokens revoked
☐ Sessions terminated where necessary
☐ Secrets rotated where necessary
☐ Manager notified
☐ Security notified
☐ Incident assessment performed where required

42. Post-Change Monitoring

For higher-risk role changes:

☐ Access activity monitored
☐ Privileged activity reviewed
☐ Security events monitored
☐ Production activity reviewed where appropriate
☐ New responsibilities reviewed
☐ Additional access reviewed

43. Role Change Completion

Confirm:

☐ HR record updated
☐ Job description updated
☐ Manager updated
☐ Security responsibilities updated
☐ Access updated
☐ Previous access removed
☐ New access validated
☐ Training completed
☐ Policies communicated
☐ Acknowledgement completed where required
☐ System ownership updated
☐ Asset records updated
☐ Security review completed

44. Approval

Manager Approval

Name: ______________________________

Role: ______________________________

Signature/Approval: __________________

Date: ______________________________

IT / Access Owner Approval

Name: ______________________________

Date: ______________________________

Security Approval

Name: ______________________________

Date: ______________________________

HR Confirmation

Name: ______________________________

Date: ______________________________

45. Role Change Register

Maintain a record of completed role changes.

Employee	Previous Role	New Role	Effective Date	Risk	Access Reviewed	Completed

46. Review Triggers

An additional review should be considered when:

☐ Employee receives privileged access
☐ Employee receives production access
☐ Employee receives access to sensitive information
☐ Employee moves into a security role
☐ Employee moves into a financial role
☐ Employee becomes a system owner
☐ Employee becomes a data owner
☐ Employee receives cloud administration rights
☐ Employee receives source-code administration rights
☐ Employee receives regulatory responsibilities
☐ Major technology change occurs
☐ Security incident occurs

47. Metrics

Organizations may monitor:

Number of role changes
Percentage completed on time
Percentage with access review
Percentage with access removed
Number of excess-access findings
Number of privileged role changes
Number of overdue changes
Number of role-change exceptions
Average completion time
Number of SoD conflicts
Number of access-related incidents following role changes

48. AWS SaaS Startup Example

An AWS SaaS startup moves a Software Developer into a DevOps / Cloud Engineer role.

Previous Role

Developer

Typical access:

Git repository
Development environment
Jira
CI/CD read access

New Role

DevOps / Cloud Engineer

Potential additional access:

AWS IAM
Infrastructure-as-Code repository
CI/CD administration
Cloud monitoring
Production deployment

Role Change Assessment

Business Need: Cloud infrastructure management.

Risk: Higher than the previous role because the employee may receive infrastructure and production privileges.

Required Actions

☐ Review existing developer access
☐ Remove unnecessary access
☐ Assess privileged access
☐ Approve AWS access
☐ Enable MFA
☐ Use named IAM roles/accounts
☐ Restrict production access
☐ Review CI/CD permissions
☐ Review secrets access
☐ Review SoD
☐ Update security responsibilities
☐ Complete cloud-security training where required
☐ Validate actual access
☐ Record evidence

Audit Trail

Role Change → Risk Assessment → Existing Access Review → Access Removal → New Access Approval → AWS/IAM Provisioning → MFA → Access Validation → Responsibility Update → Monitoring → Evidence

49. Startup-Friendly Role Change Model

For a small startup, the process can remain lightweight while maintaining control.

Standard Role Change

Use:

Manager request
HR confirmation
Existing access review
New access approval
Excess access removal
New access provisioning
Access validation
Employee acknowledgement
Record completion

High-Risk Role Change

For cloud administrators, developers with production access, security personnel, finance administrators, or other sensitive roles, additionally perform:

Role risk assessment
Privileged access review
SoD review
Additional screening where appropriate
Role-specific training
Enhanced approval
Post-change monitoring

50. Common Mistakes

Avoid:

Adding new access without removing old access.
Treating a promotion as automatic approval for broader access.
Giving administrator access because someone has a senior title.
Failing to review SaaS applications.
Forgetting AWS/cloud access.
Forgetting source-code and CI/CD access.
Ignoring service-account ownership.
Ignoring segregation of duties.
Failing to update system ownership.
Failing to update security responsibilities.
Giving production access without separate authorization.
Treating HR records as evidence of access control.
Failing to validate actual access after provisioning.
Leaving temporary role access indefinitely.
Failing to record exceptions.
Failing to reassess risk after a significant role change.

51. Relationship With Other ISMS Documents

Document	Relationship
Employee Onboarding Checklist	Controls initial employee setup
Access Management Procedure	Controls access provisioning/revocation
Access Compliance Review Checklist	Reviews actual access
Role-Based Security Responsibilities Matrix	Defines role responsibilities
Employee Security Responsibilities	Defines employee obligations
Employee Security Acknowledgement	Records communication/acknowledgement
Employee Screening Policy	Defines screening requirements
Role-Based Screening Matrix	Determines screening by role/risk
Employee Offboarding Procedure	Controls employee exit
Privileged User Management Procedure	Controls privileged access
Security Awareness Procedure	Controls role-based security training
Asset Management Procedure	Controls employee assets
Incident Management Procedure	Handles security incidents
Segregation of Duties Matrix	Identifies conflicting responsibilities

52. ISO/IEC 27001 Connection

Employee role changes support the organization’s risk-based management of:

Access control
Identity and authentication
Privileged access
Information classification
Segregation of duties
Personnel security
Security awareness
Protection of information
Operational security
Cloud security
Incident responsibilities

The Employee Role Change Checklist is not itself a universally prescribed ISO/IEC 27001 document or form.

The organization should determine the appropriate process, approvals, evidence, and review frequency based on:

ISMS scope
Risk assessment
Statement of Applicability
Information and systems involved
Employee responsibilities
Legal/regulatory requirements
Customer requirements
Contractual obligations
Technology environment

53. Audit Evidence Checklist

Retain appropriate evidence such as:

☐ Role change request
☐ Manager approval
☐ HR confirmation
☐ Role risk assessment
☐ Existing access review
☐ Access removal evidence
☐ New access approval
☐ Privileged access approval
☐ SoD assessment
☐ New access provisioning evidence
☐ Access validation evidence
☐ Training evidence
☐ Security acknowledgement
☐ Updated role description
☐ Updated responsibilities
☐ Updated system ownership
☐ Screening evidence where applicable
☐ Exception approval
☐ Corrective actions
☐ Completion record

Do not retain unnecessary passwords, API keys, private keys, tokens, or other authentication secrets as evidence.

54. Final Employee Role Change Audit Trail

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

What changed?
Why did the employee’s role change?
What new responsibilities were assigned?
What information can the employee now access?
What systems can the employee now access?
What previous access was removed?
What new access was approved?
Does the role require privileged or production access?
Was segregation of duties considered?
Was additional screening required?
Was role-specific training completed?
Were security responsibilities updated?
Was actual access validated?
Who approved the change?
What evidence demonstrates completion?

Final Principle

An employee role change is not simply an HR event. It is an access, information, responsibility, and risk change that should be assessed and controlled accordingly.