Business Continuity Plan
Internal Use
Business Continuity Plan
Document Control
| Item | Details |
|---|---|
| Version | 1.1 |
| Cadence | Annual |
| Policy Owner | Chief Operating Officer |
| Approved By | Chief Executive Officer |
| DCF References | DCF-1, DCF-10, DCF-11, DCF-13, DCF-14, DCF-20, DCF-21, DCF-22, DCF-25, DCF-26, DCF-27, DCF-28, DCF-29, DCF-30, DCF-32, DCF-33, DCF-38, DCF-39, DCF-40, DCF-41, DCF-42, DCF-45, DCF-47, DCF-48, DCF-49, DCF-51, DCF-52, DCF-53, DCF-54, DCF-55, DCF-56, DCF-57, DCF-58, DCF-60, DCF-68, DCF-72, DCF-73, DCF-74, DCF-75, DCF-76, DCF-77, DCF-78, DCF-79, DCF-80, DCF-81, DCF-82, DCF-99, DCF-100, DCF-134 |
1. PURPOSE AND SCOPE
1.1 Purpose
This policy establishes procedures to recover Dispel following a disruption in conjunction with the Disaster Recovery Plan.
1.2 Scope
This policy applies to all Dispel business operations, personnel, facilities, and supporting technology required to continue or restore critical services following disruptive incidents. It covers preparation, response, and recovery activities coordinated with the Disaster Recovery Plan and related contingency plans.
Dispel relies on cloud-based infrastructure and distributed teams to deliver its services. A formal Business Continuity Plan (BCP) ensures critical services can continue or be restored following disruptive incidents, and works in concert with the Disaster Recovery Plan and related contingency documents.
1.3 Regulatory and Framework Alignment
| # | Framework / Standard | Relevant Control IDs | Alignment Notes |
|---|---|---|---|
| 1 | SOC 2 | CC5.3, CC6.1, CC7.2, CC7.5 | Supports Trust Services Criteria related to contingency planning, incident response, and continuity of operations. |
| 2 | ISO/IEC 27001 | A.5.29, A.5.30 | Supports Annex A controls for information security aspects of business continuity and incident management. |
| 3 | NIST SP 800-53 | CP-1, CP-2, CP-2(1), CP-2(2), CP-2(3), CP-2(5), CP-3, CP-3(1), CP-4, CP-4(1), CP-6, CP-6(1), CP-6(2), CP-6(3), CP-7, CP-7(1), CP-7(2), CP-7(3), CP-7(4), CP-8, CP-8(1), CP-8(2), CP-8(3), CP-8(4), CP-9, CP-9(1), CP-9(2), CP-9(3), CP-9(5), CP-9(8), CP-10, CP-10(2), CP-10(4) | Implements Contingency Planning (CP) family controls for business continuity planning, alternate sites, backup, and recovery. |
| 4 | IEC 62443 | 62443-3-3.SR7.1, 62443-3-3.SR7.2 | Aligns with industrial cybersecurity requirements for resilience and recovery of IACS and industrial/OT environments. |
| 5 | HIPAA | 164.308(a)(7) | Supports Security Rule contingency planning requirements when PHI is in scope. |
2. POLICY STATEMENTS
2.1 Management Commitment
Management Commitment Statement
Senior Management at Dispel is dedicated to the protection of our information assets, industrial control systems, and Protected Health Information (PHI). We assume full accountability for the effectiveness of our security program, ensuring it is integrated into all business processes and aligned with our strategic goals. To maintain compliance with ISO 27001, IEC 62443, HIPAA, and NIST 800-53, we formally commit to:
- Resource Provisioning: Providing the necessary financial, technical, and human resources to sustain a robust security posture.
- Risk-Based Governance: Approving security policies and overseeing a continuous risk management process that prioritizes both data privacy and operational safety.
- Operational Resilience: Supporting the security of industrial automation and control systems (IACS) to ensure safety and reliability.
- Continuous Oversight: Conducting regular management reviews to evaluate program performance, audit results, and opportunities for improvement.
2.2 Business Continuity Policy Statement
Dispel SHALL:
- A plan and process for business continuity, including the backup and recovery of systems and data, must be defined and documented.
- The Business Continuity Plan shall be simulated and tested at least once a year. Metrics shall be measured and identified recovery enhancements shall be filed to improve the process.
- Security controls and requirements must be maintained during all Business Continuity Plan activities.
3. REQUIREMENTS
3.1 Business Impact Analysis (BIA)
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:
- Determine business processes and recovery criticality. business processes supported by the system are identified and the impact of a system disruption to those processes is determined along with outage impacts and estimated downtime. The downtime should reflect the maximum that an organization can tolerate while still maintaining the mission.
- Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business processes and related interdependencies as quickly as possible. Examples of resources that should be identified include facilities, personnel, equipment, software, data files, system components, and vital records.
- Identify recovery priorities for system resources. Based upon the results from the previous activities, system resources can more clearly be linked to critical mission/business processes. Priority levels can be established for sequencing recovery activities and resources.
See Appendix A for the BIA breakdown.
3.2 Work Site Recovery
In the event a Dispel 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.
Dispel’s entire organization has the ability to work from any location with Internet access and does not require an office provided Internet connection.
APPENDICES
Appendix A: Business Impact Analysis
The full Business Impact Analysis — including system criticality, outage impacts, MTD/RTO/RPO targets, resource requirements, and recovery priorities — is maintained as a separate document:
Business Continuity Plan — Appendix A: Business Impact Analysis
4. ROLES AND RESPONSIBILITIES
4.1 Governance Roles
This Policy is maintained by the Dispel Security Officer and Privacy Officer. All executive leadership shall be informed of any and all contingency events.
4.2 Line of Succession
The following order of succession ensures that decision-making authority for the Dispel 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 Chief Technology Officer and Chief Operations Officer are responsible for the recovery of Dispel technical environments. If the CEO, CTO, and/or COO is/are unable to function as the overall authority or chooses to delegate this responsibility to a successor, the President shall function as that authority or choose an alternative delegate.
4.3 Response Teams and Responsibilities
The following teams have been developed and trained to respond to a contingency event affecting Dispel infrastructure and systems. Team descriptions and expectations in the existing text SHALL be considered part of this section.
5. PROCEDURES
Detailed business continuity procedures, including notification, activation, recovery, and reconstitution steps, SHALL be maintained in the Business Continuity Plan narrative above and any linked playbooks.
6. POLICY REVIEW AND MONITORING
Business continuity testing, metrics, and monitoring activities described in this document and related testing schedules SHALL be treated as compliance mechanisms for this policy. Results of tests and exercises SHALL be reviewed at least annually and after significant changes to systems or processes.
6.1 Accessibility
This policy SHALL be stored in Dispel’s policy repository and policy vault and be accessible to all covered personnel and relevant stakeholders.
7. EXCEPTIONS AND WAIVERS
Exceptions to this policy SHALL follow the organization’s standard exception process defined in
POLICY_TEMPLATE.md Section 7 and be documented, risk-assessed, time-bound, and formally
approved.
7.1 Enforcement
Non-compliance with this policy may result in disciplinary action, up to and including termination, and may require additional technical or process remediation.
8. DEFINITIONS
This policy relies on definitions maintained in the Information Security Policy and Procedure and other corporate glossaries. Terms specific to business continuity (e.g., RTO, RPO, MTD) SHALL be used consistent with those sources.
9. REFERENCES
- Business Continuity Plan (this document)
- Disaster Recovery Plan
- Information System Contingency Plan (ISCP)
- Incident Response Policy
- Applicable SOC 2, ISO 27001, FedRAMP, NIST SP 800-53, IEC 62443, and HIPAA guidance
10. DOCUMENT HISTORY
| Version | Date | Editor | Description of Changes |
|---|---|---|---|
| 1 | 01/13/2022 | Ethan Schmertzler | Initial Creation |
| 2 | 01/26/2022 | Ethan Schmertzler | Approved |
| 3 | 02/16/2022 | Ethan Schmertzler | Approved |
| 4 | 01/10/2025 | Stefan Kristensen | Approved |
11. APPROVAL SIGNATURES
| Role | Name | Signature | Date |
|---|---|---|---|
| Policy Owner (Chief Technology Officer) | |||
| Security Officer | |||
| Senior Management Representative |