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
  • Control Statement
  • Context
  • Scope
  • Ownership
  • Guidance
  • Additional control information and project tracking
  • Policy Reference
  • Framework Mapping
  1. Security and Compliance
  2. Security Controls

BC.1.0.2 - Business Continuity Plan: Roles and Responsibilities

Control Statement

Business contingency roles and responsibilities are assigned to individuals and their contact information is communicated to authorized personnel.

Context

Establishing defined roles and responsibilities reduces organization confusion in the event of disruption. Knowing who the DRI are and how to contact them empowers faster communication, reduced response times, makes for easier and more substantive triage, and ultimately, more speedy recovery from disruption.

This control is a subset of the Business Continuity plan. The purpose of this control is to ensure that IllumiDesk is able to return to its daily operations as quickly as possible after an unforeseen event. Hence the main idea here is to identify key staff, such that: resources are protected, customer inconvenience minimized and specific responsibilities are assigned in the context of a quick recovery. This plan will clearly define the Roles and responsibilities of individuals within IllumiDesk who will be responsible, accountable, consulted and informed.

Scope

Roles and Responsibilities should be defined for the following environments and systems:

  • BC plan for my.illumidesk.com

  • Processes and procedures that support business operations and above environments

Ownership

  • Business Operations owns this control.

Guidance

As part of the establishment of a BC plan: One of the key areas is to identify individuals who will be designated to be the key personnel responsible for the restoration activities. A high level BC roles & responsibilities section should include the following listed below:

  • The BC plan roles & responsibilities section will detail the names of the assigned individuals, their roles, plan of action during disaster, what they are responsible to recover along with their contact information.

  • This has to be reviewed and approved by the respective managers and senior management for correctness.

  • Distribute copies of this contingency plan to all the defined key contingency personnel

  • Coordinate the contingency planning activities with incident handling activities and review the contingency plan for each information system under consideration.

  • Update the plan based on personnel leaving the organization, information system ownership changes, or environment of operation changes and problems encountered during the implementation, execution, or testing.

  • Protect the plan from unauthorized disclosure and modification.

In a much detailed level, the BC plan - roles & responsibilities should include:

  • Designation of appropriate teams to implement the strategy. Each team should be trained and ready to deploy in the event of a disruptive situation requiring plan activation.

  • The specific types of teams required, The size of each team, specific team titles, hierarchy designs are all based on the systems taken into consideration.

  • Personnel should be chosen to staff these teams based on their skills and knowledge. Ideally, teams would be staffed with the personnel responsible for the same or similar operation under normal conditions.

  • Team members must understand not only the BCDR plan purpose, but also the procedures necessary to execute the recovery strategy. Teams must be sufficient in size to remain viable if some members are unavailable to respond or alternate team members may be designated.

  • Team members should be familiar with the underlying goals and procedures of other teams to facilitate inter-team coordination.

  • Plan for an alternate team - personnel from different geographic areas should be chosen, to eradicate the possibility of disaster occurring in the area where all team members reside. As an alternative, hiring contractors or vendors can be done and such personnel have to be coordinated and trained.

  • Team leader disseminates information to team members and approves decisions on behalf of the team. An alternate to act as the leader to be designated, if the primary leader is unavailable.

  • Each team will be managed by a Management Team, to provide overall guidance in lieu of a major system disruption or emergency. This team is responsible for activating the contingency plan, facilitating communications among other teams and supervising the execution of contingency plan operations, tests and exercises.

  • These teams are in turn managed by a senior management official, who has the ultimate authority to activate the plan, and to make decisions regarding spending levels, acceptable risk, and interagency coordination.

  • The plan should also detail the order of succession as to who assumes responsibility for the contingency plan execution in the event that the highest authority is unavailable or unable to do so.

Additional control information and project tracking

Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the Business Continuity Plan: Roles and Responsibilities issue.

Policy Reference

Framework Mapping

  • SOC2 CC

    • CC7.5

    • CC9.1

  • SOC2 Availability

    • A1.2

PreviousIllumiDesk Handbook listing of DR for DatabasesNextBC.1.03 - Continuity Testing

Last updated 1 year ago