Business Continuity Statement

Overview

Level Access (hereafter “Level”) has a low dependence on site and hardware to deliver its services which, whilst important, are not critical services for our clients. Regardless of this, Level views Business Continuity Management (BCM) as an important part of our ability to protect our staff and ensure we fulfill our responsibilities to clients.

Level maintains Communications and Recovery Plans to facilitate the management of any incident which has the potential to incur harm to staff or disrupt our business. Executive management is engaged and responsible for oversight of the firm’s BCM program to ensure its success.

This document describes Level’s overall approach to BCM, as well as the specific techniques used to ensure the resilience of our hosted software platform.

Approach

Level’s approach to Business Continuity Management falls into four phases.

Assess Risks and Impact

Continuity risks are identified through business impact assessments. Risks are documented, analyzed, and evaluated. Senior staff are involved from each department to ensure the assessment process is comprehensive, relevant and endorsed.

The information security team actively monitors for new risks and reviews existing risks at a minimum annually.

Select Recovery Strategies

Recovery strategies are developed to mitigate risks identified for treatment. Recovery strategies include both mitigations to reduce the likelihood and impact of incidents as well as plans and procedures to speed recovery and restoration when they do occur. Table 1 lists common recovery activities strategy activities.

Table 1
Area	Mitigation
People	Create and train response teams Predetermine methods for communicating during and after an event Assign responsibilities for key activities
Process	Mitigate key staffing issues through cross-training and role redundancy Document standard operating procedures and other key information Develop response plans and procedures
Technology	Build redundancy to handle unexpected changes in load Implement a backup plan based off recovery objectives Identify and mitigate single points of failure

Implement Strategies and Develop Response Procedures

Once recovery strategies have been validated with management, mitigations must be implemented and response procedures documented. This includes the creation of plans and trained response teams with pre-identified roles and responsibilities to enable rapid response to incidents when they occur.

Verify and Improve

Verification activities are conducted to ensure recovery strategies work effectively.

Both mitigations and procedures are tested using methods such as spot checks and scenario walk-throughs to ensure things are implemented correctly, functioning and up to date. The frequency of verification varies depending on the mitigation. For example, standard backups are typically tested once per quarter whereas plans are tested at least once per year.

Discrepancies and improvements noted during verification are documented and followed-up on to ensure we continually improve our resilience and response capabilities.

Platform Resilience

Level provides external software services for our customers hosted on our software platform. This software platform is hosted on AWS and built for redundancy to ensure SLAs are met or exceeded. This section describes the measures we implement to ensure that resilience.

Hosting Services

Level utilizes Amazon Web Services (AWS) hosting facilities to provide our hosted software services in the North America AWS regions. AWS’s data centers and operations are highly decorated. See the AWS Compliance Programs page for more details.

Level’s database layer is provided by the Amazon Aurora Serverless service under AWS. AWS provides multiple data centers commonly referred to as Availability Zones (AZ). Level utilizes multiple AZs in the development of our infrastructure to ensure redundant physical systems.

Failover

Aurora Serverless stores data separately from the DB instance that processes queries and keep multiple copies of data across multiple AZs. This provides geographic redundancy for storage and allows for automatic failover in the event of a fault at the storage layer. If the DB instance or the AZ it resides in becomes unavailable, AWS will automatically reprovision a new DB instance and switch to that instance.

The application layer also provides automatic failover and self-heals if infrastructure resources within an AZ fail. Resources will automatically rebalance when an AZ comes back online.

System Recovery

Aurora Serverless database hosts are continuously monitored for health. In the event of a database failure, Aurora Serverless will seamlessly switch to a new host. Aurora does not require crash recovery replay of database redo logs, greatly reducing recovery time.

Fault Tolerance and Healing

Each chunk of the database volume is replicated six ways, across three AZs. This provides for highly fault-tolerant storage while transparently handling the loss of multiple copies without affecting database availability. In addition, storage is self-healing. Data chunks and disks are continuously scanned for errors and replaced automatically.

Backup Process

For immediate recoveries, back-up data and retention are configured to allow restoration of the database state to any point in time during the thirty-five day retention period. These automated backups are stored in Amazon S3 which is designed to provide 99.999999999% durability of the backups. The AWS native services handle the backup process and they have no impact on database performance.

Upgrades

The upgrade process includes full backups of the system prior to database and major application upgrades, and validation that the upgraded system functions as expected.

Platform upgrades occur on a continuous basis for scheduled software releases and ad hoc for both normal or emergency patches.

External Dependencies

The Level software platform is not dependent on external data feeds or interfaces to function outside of AWS.