Business Continuity Plan Guidance

The following article contains guidance explaining portions of the Business Continuity Plan that we frequently see questions around, explaining what the sections mean.

Guidance statements will appear in bold and enclosed in brackets “[ ]” below the statements of the policy. Additionally, an example of a completed Business Continuity Plan is also available: https://help.drata.com/en/articles/6232796-example-business-continuity-plan

__________________________________________________________________

This policy establishes procedures to recover [COMPANY NAME] following a disruption in conjunction with the Disaster Recovery Plan.

[COMPANY NAME] policy requires that:

[BCP/DR tests may include tabletop exercises, technical failover simulations, or live incident walkthroughs. Testing methods should be risk-based and aligned with the organization’s operational complexity.]

This Policy is maintained by the [COMPANY NAME] Security Officer and Privacy Officer. All executive leadership shall be informed of any and all contingency events.

[These roles and responsibilities can be updated as needed and the text listed here is simply a suggestion for commonly used roles related to the BCP. Succession roles should reflect real internal leadership structure and include alternates. Ensure that those named have authority and knowledge to activate and execute the BCP.]

The following order of succession ensures that decision-making authority for the [COMPANY NAME] Business Continuity Plan is uninterrupted. The CEO is responsible for ensuring the safety of personnel and the execution of procedures documented within this Plan. The Head of Engineering is responsible for the recovery of [COMPANY NAME] technical environments. If the CEO or Head of Engineering is unable to function as the overall authority or chooses to delegate this responsibility to a successor, the Business Operations Lead shall function as that authority or choose an alternative delegate.

[These roles and responsibilities can be updated as needed and the text listed here is simply a suggestion for commonly used roles related to the BCP.]

The following teams have been developed and trained to respond to a contingency event affecting [COMPANY NAME] infrastructure and systems.

[If your organization is fully remote, remove references to physical offices and clarify that HR is responsible for tracking changes in remote work locations, especially during large-scale outages.]

Members of the above teams must maintain local copies of the contact information of the Business Continuity Plan succession team. Additionally, the team leads must maintain a local copy of this policy in the event Internet access is not available during a disaster scenario.

[These team roles are illustrative and should be tailored to your actual personnel structure. Ensure all assigned team leads understand their roles and have access to offline copies of the BCP.]

[COMPANY NAME]'s strategies for operational resilience take a holistic approach to the company and its business process and are developed with consideration of acceptable limits regarding the company's risk appetite and tolerance. These strategies are developed through:

The BIA will determine the criticality of business activities to ensure operational resilience and business continuity during and after a disruption. The BIA will help identify and prioritize system components by correlating them to the business processes that the system supports. It will allow for the characterization of the impact on the processes if the system becomes unavailable. The BIA has three steps:

[This section explains the purpose and steps of a Business Impact Analysis (BIA), which assesses how critical each business process/activities is to the organization. It helps identify which systems and resources are most essential to keep operations running during and after a disruption, and prioritizes recovery efforts based on business impact.]

In the event a [COMPANY NAME] facility is not functioning due to a disaster, employees will work from home or locate to a secondary site with Internet access, until the physical recovery of the facility impacted is complete.

[COMPANY NAME]’s software development organization has the ability to work from any location with Internet access and does not require an office provided Internet connection.

[For fully remote companies, replace this section with language confirming that all personnel are equipped to work remotely with secure internet access.]

[COMPANY NAME] maintains a status page to provide real time updates and inform customers of the status of each service. The status page is updated with details about an event that may cause service interruption / downtime. [COMPANY NAME]’s status page:

<STATUS PAGE URL>

[You are not required to create a status page on your website. This is a best practice statement, and if you do not intend to implement one, you can delete this section.]

APPENDIX A

Business Impact Analysis

[For Appendix A. Please review the full example of the Business Impact Analysis, it can be found here: https://help.drata.com/en/articles/6232796-example-business-continuity-plan.]

System Description

<Provide a general description of system architecture and functionality. Indicate the operating environment, physical location, general location of users, and partnerships with external organizations/systems. Include information regarding any other technical considerations that are important for recovery purposes, such as backup procedures. Provide a diagram of the architecture, including inputs and outputs and telecommunications connections.>

[The System Description should be a high level description of the systems you want to cover. This may be your entire organization or may be limited to a specific application which you provide/deliver to customers.]

Data Collection

<Data collection can be accomplished through individual/group interviews, workshops, email, questionnaires, or any combination of these.>

[The Data Collection section covers how you collected the information to fill out this appendix. This may be through meetings, surveys, or even just a single person completing all sections of this appendix.]

STEP 1. Determine Process and System Criticality

Identify the specific business processes that depend on or support the information system, using input from users, managers, business process owners, and other internal or external points of contact.

[Business processes are key organizational functions, such as HR, Engineering, Finance, Sales, and Legal. You may break them down further (e.g., Recruiting, Payroll), but general groupings are sufficient for most BIA exercises.]

Impact categories and values characterize levels of severity to the company that would result for that particular impact category, if the business process could not be performed. These impact categories and values are samples and should be revised to reflect what is appropriate for the organization.

[You define the items labeled <CAT 1>, <CAT 2>, etc. These are potential types of impacts that an outage could create, such as Cost, Data Loss, Reputational Damage, etc.]

Downtime factors resulting from a disruptive event will be estimated by working directly with business process owners, departmental staff, managers, and other stakeholders. The following downtime categories will be considered:

[These values are determined by you. MTD should be longer than RTO or RPO. Oftentimes, business processes such as Sales, HR, etc. have very large MTD values and RTO and RPO values which are higher than customer-facing processes.]

STEP 2. Identify Resource Requirements

Identify the resources that compose <system name> in support of business processes, including hardware, software, and other resources such as data files.

[In this section for the Identify Resource Requirements, most organizations usually list the systems/components which support the services they deliver to customers. So the servers that run your customer-facing application, developer workstations, etc. You may list ALL systems/components across all business processes, however, most organizations do not go into that level of detail.]

Business-critical equipment and redundant equipment are identified. Redundant business-critical equipment is evaluated for independent location at a reasonable distance according to industry standards.

[In this section, you could list business-critical equipment/assets for your organization.]

STEP 3. Identify Recovery Priorities for System Resources

List the order of recovery for <system name> resources, and identify the expected time for recovering the resource following a “worst case” (complete rebuild/repair or replacement) disruption. A system resource can be software, data files, servers, or other hardware and should be identified individually or as a logical group.

Any alternate strategies in place to meet expected RTOs will be identified, including backup or spare equipment and vendor support contracts.

[In this section, you will rank the components for which order they should be recovered in, so the components in this table should match those listed above.]