Skip to content
FrontRunnerHC, Inc. Library

Business Continuity & Disaster Recovery Standard

Organization: FrontRunnerHC, Inc. (FRHC)
Parent Policy Reference: Summit Technology Holdings – Business Continuity & Disaster Recovery Policy Framework Reference: Secure Controls Framework – Business Continuity & Disaster Recovery (BCD)

1. Purpose

Section titled “1. Purpose”

This standard defines how FrontRunnerHC (FRHC) implements the enterprise-wide Business Continuity & Disaster Recovery requirements established by Summit Technology Holdings, LLC (STH). It documents the controls and practices used to maintain resilient operations and ensure that critical business functions can be sustained and restored following disruptive events.

2. Applicability

Section titled “2. Applicability”

This standard applies to all FRHC systems, applications, personnel, and facilities required to maintain continuity of essential services, including those supporting PatientRemedi (both v1 and v2) and Credit Balance. It also applies to third parties with whom FRHC has contractual continuity obligations.

3. Standard

Section titled “3. Standard”

3.1 Business Continuity Management System

Section titled “3.1 Business Continuity Management System”

FRHC maintains a Business Continuity & Disaster Recovery (BCDR) framework designed to preserve business-critical functions during and after disruptive events. The framework is aligned with the enterprise BCMS established by STH.

FRHC has defined the following recovery objectives:

  • RTO: 24 Hours
  • RPO: 4 Hours

These objectives are used to design recovery strategies, backup schedules, and testing activities.

  • Parent Policy Mapping: STH BCDR Policy, Section 3.1
  • SCF Mapping: BCD-01 (Business Continuity Management System (BCMS))

3.2 Critical Assets

Section titled “3.2 Critical Assets”

FRHC has identified its essential business functions and the systems that support them. Critical applications include FRHC production platforms and supporting services required to deliver core functionality to users. These applications include the following:

  • PatientRemedi v1
  • PatientRemedi v2
  • Credit Balance

Supporting infrastructure, including both physical and cloud-hosted servers, storage, network connectivity, and system interconnections, is documented in architecture and continuity planning documentation. Dependencies on third-party cloud providers and vendors are identified and incorporated into recovery planning.

  • Parent Policy Mapping: STH BCDR Policy, Section 3.2
  • SCF Mapping: BCD-02 (Identify Critical Assets)

3.3 Contingency Training

Section titled “3.3 Contingency Training”

Personnel with defined business continuity and disaster recovery responsibilities participate in contingency training at least annually. Training is conducted using table-top exercises that walk through:

  • Disaster declaration and escalation
  • Activation of backup and recovery services
  • Restoration of primary systems and services

Training activities are used to identify gaps and to recommend updates to continuity plans.

  • Parent Policy Mapping: STH BCDR Policy, Section 3.3
  • SCF Mapping: BCD-03 (Contingency Training)

3.4 Contingency Plan Testing

Section titled “3.4 Contingency Plan Testing”

FRHC tests its BCDR plans at least annually through table-top exercises and/or technical recovery simulations. Testing validates the organization’s ability to meet defined RTO and RPO objectives.

The results of testing and any naturally occurring disruptive events are documented in contingency testing records and used to drive corrective actions.

  • Parent Policy Mapping: STH BCDR Policy, Section 3.4
  • SCF Mapping: BCD-04 (Contingency Plan Testing & Exercises)

3.5 Root Cause Analysis & Lessons Learned

Section titled “3.5 Root Cause Analysis & Lessons Learned”

Following any test or activation of BCDR plans, FRHC documents the execution of recovery activities. A review is conducted to identify issues, perform root cause analysis (RCA), and capture lessons learned.

Identified corrective actions are tracked and incorporated into plan updates as appropriate.

  • Parent Policy Mapping: STH BCDR Policy, Section 3.5
  • SCF Mapping: BCD-05 (Contingency Plan Root Cause Analysis (RCA) & Lessons Learned)

3.6 Ongoing Contingency Planning

Section titled “3.6 Ongoing Contingency Planning”

FRHC reviews and updates its business continuity and disaster recovery plans at least annually and whenever significant changes occur, including:

  • Changes in personnel with continuity responsibilities
  • Changes to infrastructure, applications, or hosting environments
  • Changes to vendors or service providers
  • Material changes to threat conditions or business operations

Updates incorporate the results of testing and real-world incidents.

  • Parent Policy Mapping: STH BCDR Policy, Section 3.6
  • SCF Mapping: BCD-06 (Ongoing Contingency Planning)

3.7 Alternate Storage Site

Section titled “3.7 Alternate Storage Site”

FRHC leverages both Azure and AWS cloud infrastructure to support disaster recovery and alternate processing. Production databases for PatientRemedi v1 and Credit Balance applications run on physical hardware located at the Evocative Data Center in the Boston, MA area. Production databases for PatientRemedi v2 applications run on Amazon Aurora PostgreSQL clusters deployed in a Multi-AZ configuration within the us-east-1 (N. Virginia) region.

For PatientRemedi v1 and Credit Balance, monthly full backups are created and copied to an Azure file store in the US-EAST2 (Virginia) region.

For PatientRemedi v2, daily database snapshots are created via a centralized AWS Backup plan and automatically copied to the us-east-2 (Ohio) region.

In both cases, these provide a geographically separated offsite backup that provide protection from regional disruptions affecting the primary environments.

Alternate processing capabilities are maintained through cloud infrastructures (Azure for PatientRemedi v1 and Credit Balance; AWS for PatientRemedi v2) that can be provisioned or restored within defined recovery objectives.

  • Parent Policy Mapping: STH BCDR Policy, Sections 3.7–3.8
  • SCF Mapping:
    • BCD-08 (Alternate Storage Site)
    • BCD-09 (Alternate Processing Site)

3.8 Telecommunications Services

Section titled “3.8 Telecommunications Services”

For PatientRemedi v1 and Credit Balance, the Evocative datacenter used by FRHC provides a data circuit supported by two vendors and managed entirely by Evocative. Border Gateway Protocol (BGP) is used to provide redundancy so that if the primary data circuit fails, the connection immediately fails over to the alternate vendor’s circuit, maintaining communication services.

For PatientRemedi v2, internet connectivity and telecommunications redundancy at the infrastructure level are provided and managed by AWS as part of the shared responsibility model. AWS maintains multiple redundant internet uplinks, diverse transit providers, and network path redundancy within and across Availability Zones, ensuring that no single telecommunications failure results in loss of connectivity to LX services.

  • Parent Policy Mapping: STH BCDR Policy, Section 3.9
  • SCF Mapping: BCD-10 (Telecommunications Services Availability)

3.09 Data Backups & System Recovery

Section titled “3.09 Data Backups & System Recovery”

For PatientRemedi v1 and Credit Balance, all production data and systems at the Evocative datacenter are backed up nightly (beginning after 6:00 PM Eastern Time) using Veeam Backup & Replication (VBR). Backup copies are stored locally on an HP StoreOnce appliance and are imutable. A monthly full backup is copied to Azure-hosted storage. All backup objects are compressed, deduplicated, and encrypted with AES-256. Backups are periodically restored to an alternate host to validate reliability and integrity, and restoration events are recorded in the Contingency Plan Testing Log.

For PatientRemedi v2, the database is running on a dedicated Amazon Aurora PostgreSQL cluster. Automated backups are managed via AWS backup services. Two layers of backup protection are maintained:

  • AWS Backup (daily snapshots): Each Aurora cluster has a dedicated AWS Backup plan that executes daily snapshots at 21:00 EDT (01:00 UTC). Snapshots are retained for 35 days and automatically copied to the us-east-2 (Ohio) region for offsite storage. All backup data is encrypted using AWS KMS.
  • Aurora native backup (continuous PITR): Aurora’s built-in continuous backup provides point-in-time recovery (PITR) with a 14-day retention window, enabling granular recovery to any second within the retention period.

Together, these layers support recovery strategies designed to meet the defined RTO and RPO objectives. Restoration from backups is periodically validated as part of contingency testing activities.

  • Parent Policy Mapping: STH BCDR Policy, Sections 3.10–3.11
  • SCF Mapping:
    • BCD-11 (Data Backups)
    • BCD-12 (Technology Assets, Applications and/or Services (TAAS) Recovery & Reconstitution)

4. Compliance & Governance

Section titled “4. Compliance & Governance”

FRHC maintains evidence supporting business continuity and disaster recovery controls, including contingency plans, training records, test logs, root cause analyses, backup configurations, and infrastructure documentation. Evidence is retained and made available to STH to support enterprise governance, audit, and compliance activities.

5. Enforcement

Section titled “5. Enforcement”

All users (employees, contractors, part-time and temporary workers) and those employed by others to perform work for the organization, or who have been granted access to IT assets or facilities, are covered by this standard and must comply with its associated policies, procedures, standards and guidelines.

Failure to comply with this standard and associated guidelines may result in suspension of use privileges or other disciplinary actions up to and including termination and/or legal action.

6. References

Section titled “6. References”

Parent Policy:

  • Summit Technology Holdings – Business Continuity & Disaster Recovery Policy

Regulatory Requirements:

  • HIPAA Security Rule:
    • 45 CFR §164.308(a)(7) – Contingency Plan
  • AICPA SOC 2 Trust Services Criteria:
    • Availability (A1.2, A1.3)
    • Security (CC7.4)

Framework Alignment:

  • BCD-01 – Business Continuity Management System
  • BCD-02 – Identify Critical Assets
  • BCD-03 – Contingency Training
  • BCD-04 – Contingency Plan Testing & Exercises
  • BCD-05 – Contingency Plan Root Cause Analysis (RCA) & Lessons Learned
  • BCD-06 – Ongoing Contingency Planning
  • BCD-08 – Alternate Storage Site
  • BCD-09 – Alternate Processing Site
  • BCD-10 – Telecommunications Services Availability
  • BCD-11 – Data Backups
  • BCD-12 – Technology Assets, Applications and/or Services (TAAS) Recovery & Reconstitution

7. Revision Tracking

Section titled “7. Revision Tracking”
RevDescriptionDateApproved
-Policy createdJuly 2020M Machin
1.0Updated to include LabXchange and PatientXchangeAugust 2021M Machin
2.0Formatting UpdateSeptember 2022WSI
3.0Updates to VBR & database backup & azure sync processApril 2024M Machin
3.1Final formatting complete. Updated and approved for 2024May 2024WSI
4.0Removed LX/PX references. Updated and approved for 2025May 2025M Machin
5.0Converted to StandardApril 2026M Machin
6.0Updated to include PatientRemedi v2, and reviewed/approved for 2026July 2026M Machin

Internal Use Only