IllumiDesk Security Docs
  • IllumiDesk Team Handbook
  • People Group
    • Introduction
    • General Employment
    • Employment Status & Recordkeeping
    • Working Conditions & Hours
    • Employee Benefits
    • Employee Conduct
    • Timekeeping & Payroll
  • Security and Compliance
    • Security Controls
      • BC.1.01 - Business Continuity Plan
        • IllumiDesk Business Continuity Plan
        • IllumiDesk Disaster Recovery
        • IllumiDesk Reference Architectures
        • IllumiDesk Handbook listing of DR for Databases
      • BC.1.0.2 - Business Continuity Plan: Roles and Responsibilities
      • BC.1.03 - Continuity Testing
      • BC.1.04 - Business Impact Analysis
        • Business Impact Analysis in the handbook
        • Data Protection Impact Assessment (DPIA) Policy
        • Data Protection Impact Assessments or DPIAs
        • UX Department
        • Triage Operations - Communication about expected automation impact
        • NIST BCP with reference to BIA
      • CFG.1.01 - Baseline Configuration Standard
        • Laptop or Desktop System configuration
        • Configuring New Laptops
        • Security Best Practices
      • CFG.1.03 - Configuration Checks
        • Production Change Requests Policy
      • CM.1.01 - Change Management Workflow
      • CM.1.02 - Change Approval
      • CM.1.03 - Change Management Issue Tracker
      • CM.1.04 - Emergency Changes
      • DM.1.01 - Data Classification Criteria
        • Data Classification Policy
      • DM.2.01 - Terms of Service
        • Application Terms of Use
      • DM.4.01 - Encryption of Data in Transit
        • Deprecate support for TLS 1.0 and TLS 1.1
      • DM.7.03 - Data Retention and Disposal Policy
      • IAM.1.01 - Logical Access Provisioning
        • Access Requests
        • Access Management Process
      • IAM.1.02 - Logical Access De-Provisioning
        • Access Management Process
        • Logical Access Deprovisioning
        • Access Reviews
        • IllumiDesk Offboarding Guidelines
      • IAM.1.04 - Logical Access Review
        • Access Reviews
      • IAM.1.05 - Transfers: Access De-Provisioning
        • Access Control Policy and Procedures
        • Job Transfers
        • Access Change Request
      • IAM.1.06 - Shared Logical Accounts
        • Security Process and Procedures for Team Members
        • Access Management Process
      • IAM.1.08 - New Access Provisioning
        • Access Requests
        • Access Management Process
      • IAM.2.01 - Unique Identifiers
        • Unique Account Identifiers
        • Access Control Policy and Procedures
        • Section on shared accounts in Okta handbook page
        • Access Management Process
      • IAM.2.02 - Password Authentication
      • IAM.2.03 - Multi-factor Authentication
      • IAM.3.02 - Source Code Security
      • IAM.4.01 - Remote Connections
      • IAM.6.01 - Key Repository Access
      • IR.1.01 - Incident Response Plan
      • IR.1.03 - Incident response
      • IR.1.04 - Insurance Policy
      • IR.2.02 - Incident Reporting
      • NO.1.01 - Network Policy Enforcement Points
      • PR.1.01 - Background Checks
      • RM.1.01 - Risk Assessment
      • RM.1.02 - Continuous Monitoring
        • Security Compliance
      • RM.1.04 - Service Risk Rating Assignment
      • RM.1.05 - Risk Management Policy
      • RM.3.01 - Remediation Tracking
      • SDM.1.01 - System Documentation
      • SG.1.01 - Policy and Standard Review
      • SG.2.01 - Information Security Program Content
      • SG.5.03 - Security Roles and Responsibilities
        • Incident Management Roles and Responsibilities
      • SG.5.06 - Board of Director Bylaws
        • Governance Documents
      • SG.5.07 - Board of Directors Security Program Content
        • Audit Committee Agenda Planner
      • SLC.1.01 - Service Lifecycle Workflow
      • SLC.2.01 - Source Code Management
      • SYS.1.01 - Audit Logging
      • SYS.2.01 - Security Monitoring Alert Criteria
      • SYS.2.07 - System Security Monitoring
      • TPM.1.01 - Third Party Assurance Review
      • TPM.1.02 - Vendor Risk Management
      • TRN.1.01 - General Security Awareness Training
        • Security Awareness Training
      • TRN.1.02 - Code of Conduct Training
      • VUL.1.01 - Vulnerability Scans
      • VUL.1.03 - Approved Scanning Vendor
      • VUL.2.01 - Application & Infrastructure Penetration Testing
      • VUL.3.01 - Infrastructure Patch Management
      • VUL.3.02 - End of Life Software
      • VUL.4.01 - Enterprise Protection
      • VUL.5.01 - Code Security Check
      • VUL.6.01 - External Information Security Inquiries
  • VPAT Version 2.3
Powered by GitBook
On this page
  1. Security and Compliance
  2. Security Controls
  3. IAM.1.05 - Transfers: Access De-Provisioning

Access Change Request

Access Change Requests are logged when a team member no longer requires access to a currently provisioned system or no longer requires the same level of access (downgraded access from admin to user etc). Refer to For People Ops Analysts: Processing Promotions & Compensation Changes section of the IllumiDesk handbook for additional information.

It is important to note that while Okta has provisioning/deprovisioning automation in place, this is not a complete/accurate reflection of access provisioning and deprovisioning. Okta has been configured to assign integrated/implemented applications based on a user's role/group. This makes applications accessible via Okta but users may still have the ability to access the systems directly. Refer to Okta Application Stack for a list of applications set up in Okta.

What this means is:

  1. A IllumiDesk Team member gets transferred to a different role.

  2. The team member's profile in BambooHR is changed.

  3. This profile change automatically triggers a change in his Okta profile accordingly.

  4. This, in turn, results in the team member getting assigned to new applications based on his new department and role.

  5. Simultaneously all old applications that are not relevant to his new role get revoked/unassigned.

  6. Additionally, the Okta administrator gets an Email from Okta, that there has been a change to a User profile - (Email Subject line: 1 existing user updated). Okta automation already happens in the background, this email is informational only.

While this application automation will take place in Okta, "true" system provisioning and deprovisioning will still need to be manually completed within the impacted systems via an Access Change Request.

PreviousJob TransfersNextIAM.1.06 - Shared Logical Accounts

Last updated 1 year ago