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 members from each department are involved to ensure the assessment process is comprehensive, relevant, and endorsed.
Level’s Information Security team actively monitors for new risks and reviews existing risks annually at minimum.
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:
| Area | Mitigation |
|---|---|
| People |
|
| Process |
|
| Technology |
|
Table 1
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 Level is continually improving 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 Amazon Web Services (AWS) and MongoDB Atlas and are built for redundancy to ensure Service Level Agreements (SLA) are met or exceeded. This section describes the measures we implement to ensure that resilience.
Hosting services
Level utilizes AWS hosting facilities to provide our hosted software services in the North America AWS regions. AWS’s data centers and operations are highly decorated. Visit the AWS Compliance Programs page for more details.
Level’s database layers are provided by MongoDB Atlas and the Amazon Aurora Serverless service. MongoDB Atlas and AWS provide 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
Both MongoDB Atlas and Aurora Serverless store data separately from the DB instance that processes queries and keeps 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, the services 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 cis back online.
System recovery
Database services are continuously monitored for health. In the event of a database failure, the services will seamlessly switch to a new host.
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 has 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 and MongoDB Atlas.