Escolar Documentos
Profissional Documentos
Cultura Documentos
Powered by SingleHop
Page 1 of 9
Table of Contents
1. Overview .........................................................................................................................3
1.1 Purpose ........................................................................................................................3
2. <Name of Critical System> Description ........................................................................5
3. BIA Data Collection ........................................................................................................5
3.1 Determine Process and System Criticality ....................................................................5
3.1.1 Outage Impacts .........................................................................................................6
3.1.2 Estimated Downtime .................................................................................................7
3.1.3 Estimated Cost of Downtime .....................................................................................8
3.2 Identify Resource Requirements ...................................................................................8
Powered by SingleHop
Page 2 of 9
1. Overview
This Business Impact Analysis (BIA) is developed as part of the contingency planning process
for all critical <Insert Company Name> services. This BIA was prepared on <DATE> and
performed for the <Insert Company Name> Disaster Recovery Plan effective for FY <YEAR>.
Testing was performed to validate procedure laid out for the <NAME OF PLAN OR PROJECT>.
Este Business Impact Analysis (BIA) se desarrolla como parte del proceso de planificación de
contingencia para todos los servicios críticos de Contact Car S.A.S. Esta BIA se se realizó para
el Plan de recuperación de desastres de Contact Car S.A.S. vigente para <2017>. Las pruebas
se realizaron para validar el procedimiento establecido para <NOMBRE DEL PLAN O
PROYECTO>.
1.1 Purpose
The purpose of the BIA is to identify and prioritize system components by correlating them to the
mission/business process(es) the system supports, and using this information to characterize
the impact on the process(es) if the system were unavailable.
This document is used to build the <Insert Company Name> Information System Contingency
Plan (ISCP) and is included as a key component of the ISCP. It also may be used to support
the development of other contingency plans associated with the system, including, but not
limited to, the Disaster Recovery Plan (DRP), Cyber Incident Response Plan, or Business
Continuity plan.
Powered by SingleHop
Page 3 of 9
El objetivo del BIA es identificar y priorizar los componentes del sistema correlacionándolos con
el (los) proceso (s) de la misión / negocio que el sistema soporta y utilizando esta información
para caracterizar el impacto en el / los proceso (es) si el sistema no estuvo disponible.
El BIA se compone de los siguientes tres pasos:
2. Identificar los requisitos de recursos. Los esfuerzos de recuperación realistas requieren una
evaluación exhaustiva de los recursos necesarios para reanudar los procesos de misión /
negocio y las interdependencias relacionadas lo más rápido posible. Los ejemplos de recursos
que deben identificarse incluyen instalaciones, personal, equipo, software, archivos de datos,
componentes del sistema y registros vitales.
Powered by SingleHop
Page 4 of 9
2. <Name of Critical System> Description
<INSERT SYSTEM DIAGRAM HERE>
Powered by SingleHop
Page 5 of 9
3.1.1 Outage Impacts
The following impact categories represent important areas for consideration in the event of a
disruption or impact to <INSERT COMPANY NAME> services.
Impact category:
The table below summarizes the impact on each mission/business process if <Insert Company
Name> Services were unavailable, based on the following criteria:
Powered by SingleHop
Page 6 of 9
3.1.2 Estimated Downtime
Working directly with mission/business process owners, departmental staff, managers, and
other stakeholders, estimate the downtime factors for consideration as a result of a disruptive
event.
• Maximum Tolerable Downtime (MTD). The MTD represents the total amount of time
leaders/managers 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.
• Recovery Time Objective (RTO). RTO defines the maximum amount of time that a
system resource can remain unavailable before there is an unacceptable impact on
other system resources, supported mission/business processes, and the MTD.
Determining the information system resource RTO is important for selecting appropriate
technologies that are best suited for meeting the MTD.
• Recovery Point Objective (RPO). The RPO represents the point in time, prior to a
disruption or system outage, to which mission/business process data must be recovered
(given the most recent backup copy of the data) after an outage.
The table below identifies the MTD, RTO, and RPO (as applicable) for the organizational
mission/business processes within <Insert Company Name>.
Mission/Business Process MTD RTO RPO
Powered by SingleHop
Page 7 of 9
3.1.3 Estimated Cost of Downtime
<Provide a description of each impacted system and an estimated cost of an hour – day of
downtime for each system>
Powered by SingleHop
Page 8 of 9
It is assumed that all identified resources support the mission/business processes identified in
Section 3.1 unless otherwise stated.
System
Priority Resource/Component Recovery Time Objective
Powered by SingleHop
Page 9 of 9