Business Impact Analysis
Relevant source files
The following files were used as context for generating this wiki page:
Business Impact Analysis (BIA) in Horizon is a specialized module designed to identify and evaluate the criticality of IT assets and business functions. It enables organizations to map dependencies, assess the potential consequences of system disruptions, and develop comprehensive recovery strategies. By integrating BIA with the core Configuration Management Database (CMDB), the system provides a data-driven approach to business continuity and disaster recovery planning.
The primary scope of the BIA module includes managing a registry of critical systems, mapping system-to-system dependencies, documenting recovery procedures, and maintaining contact information for key personnel. This module works in tandem with the Asset Inventory and Vulnerability Management modules to provide a holistic view of organizational risk.
Sources: README.md:92-97, IMPLEMENTATION_PLAN.md:434-439
Core Components and Capabilities
The BIA system is structured around four primary pillars: system classification, dependency mapping, recovery planning, and impact assessment.
Key Features
| Feature | Description |
|---|---|
| Critical System Registry | Classification of systems based on business criticality (Critical, High, Medium, Low). |
| Dependency Mapping | Visualization of system dependencies and identification of potential impact cascades. |
| Recovery Planning | Documentation of Recovery Time Objectives (RTO), Recovery Point Objectives (RPO), and procedures. |
| Impact Scoring | Calculation of financial and operational impacts of system outages. |
Sources: README.md:92-97, IMPLEMENTATION_PLAN.md:448-452
Data Architecture and Schema
The BIA module relies on a series of relational tables within the PostgreSQL database to manage complex business relationships and recovery metrics.
Database Entities
The following table describes the primary entities defined for the BIA module:
| Entity | Description |
|---|---|
business_functions | High-level organizational functions supported by IT systems. |
critical_systems | Registry of systems linked to assets/software with assigned criticality levels. |
system_dependencies | Mapping of relationships between different systems for impact analysis. |
recovery_contacts | Directory of personnel responsible for system recovery. |
recovery_plans | Formalized procedures for restoring services. |
recovery_tests | Logs of disaster recovery drills and outcomes. |
Sources: IMPLEMENTATION_PLAN.md:434-445
Criticality Classification
Systems are categorized into five distinct levels of criticality to prioritize recovery efforts:
- Critical: Essential systems where failure causes immediate mission stoppage.
- High: Important systems with high operational impact.
- Medium: Systems with moderate impact.
- Low: Systems with minimal impact on core operations.
- Non-Critical: Ancillary systems.
Sources: IMPLEMENTATION_PLAN.md:449-450
Dependency Mapping and Impact Cascades
The BIA module provides a graph-based view of how systems interact. This allows administrators to visualize "impact cascades," where the failure of a low-level dependency might compromise a high-level business function.
The diagram shows the relationship between business functions and their underlying critical system dependencies.
Sources: README.md:94, IMPLEMENTATION_PLAN.md:454-458
Recovery Management Logic
The system tracks specific time-based objectives and procedures required for business continuity.
Metrics and Documentation
- Recovery Time Objective (RTO): The maximum allowable duration to restore a system after failure.
- Recovery Point Objective (RPO): The maximum age of files that must be recovered from backup storage for operations to resume.
- Maximum Tolerable Outage (MTO): The upper limit of time a business can survive without the system.
Sources: IMPLEMENTATION_PLAN.md:451-452
Recovery Workflow
The workflow for recovery management involves documenting procedures, assigning contacts, and scheduling regular reviews of the BIA status.
The sequence illustrates the lifecycle of recovery planning and validation.
Sources: IMPLEMENTATION_PLAN.md:440-445, IMPLEMENTATION_PLAN.md:460-464
Error Handling and Validation
Like all Horizon modules, BIA operations utilize the core error crate for consistent failure reporting. If a user attempts to access a non-existent critical system or submits invalid RTO/RPO values, the system returns structured AppError responses.
// Example of a NotFound error implementation for BIA resources
pub fn system_not_found(id: &str) -> AppError {
AppError::NotFound(NotFound::new("CriticalSystem").with_identifier(id))
}
Sources: crates/error/src/codes.rs:43-52, AGENTS.md:91-100
API responses are wrapped in a generic ApiResponse structure, ensuring that BIA data is accompanied by relevant metadata such as request IDs and timestamps.
Sources: crates/error/src/response.rs:100-115
Summary
The Business Impact Analysis module provides the intelligence layer for Horizon’s CMDB. By classifying assets through the Critical System Registry, mapping System Dependencies, and formalizing Recovery Management, Horizon ensures that organizations can prioritize their security and maintenance efforts based on actual business risk. This data-driven approach facilitates compliance with industry standards and enhances organizational resilience.
Sources: README.md:27-35, IMPLEMENTATION_PLAN.md:26-31