Business continuity plan

Hall has a structured business continuity plan in place that in the event of vendor and service outages that could affect business operations.

This this plan identifies:

• key resources and needs to ensure that business may continue, perhaps in a limited capacity, in the event of a disaster
• information such as key suppliers and contingency plans for any service outages
• an alternative business location if the primary Hall office is unavailable

Incident response plan

Hall has a documented incident response plan that establishes the procedures to be undertaken in response to information security incidents.

This incident response plan includes:

• Escalation procedures
• Incident severity identification and classification
• Roles, responsibilities, and communication strategies in the event of a compromise
• Containment and remediation strategies
• Communication protocols, both internally and externally
• A retrospective analysis to determine the root cause and implement improvements to incident response procedures

Monitoring and alerting

Hall has continuous monitoring, logging, and alerting in place that will automatically escalate any issues. Depending on severity, these incidents may trigger an incident to dedicated on-call engineering 24 hours a day, 7 days a week, 365 days a year. Potential catalysts that may trigger an incident include:

• severe vulnerabilities
• vulnerabilities disclosed by a security researcher
• intrusion detections
• elevated errors, operational performance, and suspicious operations
• data breach discovery

Insurance

Hall carries and maintenances insurance policies in the amounts and for the occurrences for which insurance is typically carried by software companies of similar sizes and scales to Hall.

High availability infrastructure

Hall uses properly-provisioned, redundant infrastructure with multiple load balancers, web servers, and replicant databases in case of failure.

24 / 7 / 365 monitoring

We have continuous monitoring, logging, and alerting in place that will automatically escalate any issues to dedicated on-call engineering 24 hours a day, 7 days a week, 365 days a year.

Uptime and status

All updates regarding system uptime and status are posted to our status page. You can subscribe to be notified of updates affecting the status and uptime of the Hall service. Historical uptime and previous incidents can be viewed on this status page.

System maintenance

From time to time, Hall may undertake routine scheduled maintenance to perform required upgrades to the Hall service.

Scheduled maintenance is infrequent and we will provide at least 5 days notice before undertaking any scheduled maintenance. Scheduled maintenance notices are made available on our status page where you can subscribe to be notified of upcoming maintenance.

To minimize the affect of downtime during scheduled maintenance, we aim to perform maintenance during timeframes that are least likely to affect most customers.

Our window for scheduled maintenance is from Sunday midnight GMT to Sunday 3am GMT.

Disaster recovery plan

Hall has a structured disaster recovery plan that establishes procedures to recover service operations from a disruption resulting from a disaster. The types of disasters contemplated by this plan include natural disasters, political disturbances, man-man disasters, external human threats, and internal malicious activities.

Critical systems and services

From a disaster recovery perspective, Hall defines two categories of systems:

Non-critical systems

These are all systems not considered critical by the definition below. These systems, while they may affect the performance and overall security of critical systems, do not prevent critical systems from functioning and being accessed appropriately. Non-critical systems are restored at a lower priority than critical systems.

Critical systems

These systems host application servers and database servers or are required for the functioning of systems that host application servers and database servers. These systems, if unavailable, affect the integrity of data and must be restored, or have a process begun to restore them, immediately upon becoming unavailable.

Recovery time and recovery point objectives

Hall aims for zero data loss and high availability, however we also understand that systems can go wrong and that such targets usually unattainable or highly expensive. As a part of our business continuity plan, we set recovery time objectives (RTO) and recovery point objectives (RPO) that aim to strike a balance between cost and benefit.

RTO is the amount of time it takes to restore Hall during a period of unavailability. While we aim to keep this period of time as minimal as possible, there might be anticipated scenarios where it may take longer that expected. As a result, we advise a RTO within than 48 hours of failure.

RPO is the amount of time that an organisation accepts it may lose in a recovery operation. At Hall, we perform full database backups every 24 hours and we also keep the database transaction logs. This means in an ideal scenario we can restore our database to within minutes of when service is interrupted, resulting in minimal data loss if any. Failing that, we expect to be able to restore to a full database backup. As a result, we revise a RPO of 24 hours.

Testing and rehearsal

Hall performs coordinated testing and rehearsals of the disaster recovery plan annually. This includes a retrospective and tabletop reenactment in order to identify lessons learned and improvements to playbooks and operating procedures.

Backups

Hall has a documented backup policy that describes how often backups occur, backup storage, and maintenance.

Database backups

All data is backed up utilizing Amazon Web Services (AWS) Relation Database Service (RDS) backup solution. RDS data is automatically backed up daily, and backups and stored for 30 days. RDS backups are encrypted at rest.

File storage

All files are stored utilizing Amazon Simple Storage Service (S3) are backed up daily. All S3 backups are stored for 30 days. S3 backups are encrypted at rest.

Logging backups

The backup period for different types of logging is described in logging and monitoring.