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
  • Business Impact Analysis
  • Purpose
  • The Business Impact Analysis is composed of the following:
  • Conclusion
  • Plan update and protect from disclosure
  1. Security and Compliance
  2. Security Controls
  3. BC.1.04 - Business Impact Analysis

Business Impact Analysis in the handbook

Business Impact Analysis

The Business Impact Analysis (BIA) is developed as part of the Business Continuity Plan process.

Purpose

The purpose of the BIA is to identify and prioritize system components by correlating them to mission critical processes that support the functioning of IllumiDesk. Using this information to characterize what would be the impact to IllumiDesk, if any of these systems were to be unavailable.

The Business Impact Analysis is composed of the following:

  1. Determine data classification and approved operating System usage: IllumiDesk data and system resources can more clearly be linked to mission critical business processes by way of classifying them based on sensitivity. These priority levels can be established for sequencing recovery activities and resources. Additionally, the existence of an approved set of operating systems platforms will facilitate ease of management and quick turnaround and repair when they are non-functional.

    • IllumiDesk's Data Classification policy covers all aspects of this requirement:

    • Approved Operating Systems

  2. Determine mission critical business processes and recovery criticality: In this step, IllumiDesk's mission critical business processes / systems are identified and the impact of a system disruption to those processes is determined along with outage impacts and estimated downtime. The downtime reflects the maximum, that an organization can tolerate while still maintaining the mission.

    • This is covered in the P1, P2, P3: Outages and their immediate impact on IllumiDesk customer/user operations

  3. Identify resource requirements: Realistic recovery efforts require a thorough evaluation of the resources required to resume business processes and related interdependencies as quickly as possible. Examples of resources that should be identified include software, data files, system components, and vital records.

    • The Backup and Recovery process in IllumiDesk is robust enough to satisfy the above requirement as it relates to IllumiDesk.com.

  4. Determine alternate storage and strategies: Identify any alternate strategies in place to meet expected RTOs. This includes backup or spare equipment and vendor support contracts. IllumiDesk alternate storage process, serves to securely store data in an alternate location from source data

  5. Identify recovery priorities for system resources based on standards: Adherence to IllumiDesk's agreed upon RTO/ RPO: Apart from determining the RTO and RPO, BIA also defines Maximum Tolerable Downtime (MTD)

  • The Maximum Tolerable Downtime (MTD) - represents the total amount of time senior management are willing to accept for a mission/business process outage or disruption and includes all impact considerations. Determining MTD is important because it could leave continuity planners with imprecise direction on (1) selection of an appropriate recovery method, and (2) the depth of detail which will be required when developing recovery procedures, including their scope and content.

  1. Delegation and defining the process: Designate each incident as critical or non-critical based on the business priority. Compile a list of personnel who must be in place to perform these functions. In times of an occurence of an incident, a detailed step-by-step approach about how to communicate it to the group, how it is performed, who performs it, and the operational mode of action taken.

The following links show the process carried out at IllumiDesk to cater to this requirement:

  • Impact values for assessing category impact

  • Security issue triage process

  • Security Incident issues are tagged with the incident label and are further tagged with S1 S2 S3 S4 labels to determine the severity and accordingly work on resolution]

  • Support team contact information - Quick Reference

  • On-Call Runbooks - Incident response runbooks for on-call engineers. .

  • Support Team function in the handbook.

Conclusion

The most important part of the Business Impact Analysis is to weigh the exactness of all findings. Communicate the findings to the respective department managers or key personnel to ensure that the assumptions made are in fact accurate and realistic. Once the accuracy of the documented findings has been established and agreed to by all parties, these BIA findings are submitted to IllumiDesk's e-group for approval.

Plan update and protect from disclosure

The BIA report will be updated based on changes to the organization, information system, or environment of operation and problems encountered during the implementation, execution, or testing. This plan will be protected from unauthorized disclosure and modification. Finally, all the Business Impact Analysis data will be stored in a safe place for future reference in the event of a disaster.

PreviousBC.1.04 - Business Impact AnalysisNextData Protection Impact Assessment (DPIA) Policy

Last updated 1 year ago