Business Continuity and Disaster Recovery

2025.8

The Matrak Contingency Plan establishes procedures to recover Matrak following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the Matrak Security Officer and Privacy Officer.

Policy Statements

Matrak policy requires that:

(a) A plan and process for business continuity and disaster recovery (BCDR), including the backup and recovery of systems and data, must be defined and documented.

(b) BCDR shall be simulated and tested at least once a year. Metrics shall be measured and identified recovery enhancements shall be filed to improve the BCDR process.

(c) Security controls and requirements must be maintained during all BCDR activities.

Controls and Procedures

BCDR Objectives and Roles

Objectives

The following objectives have been established for this plan:

Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:
- Notification/Activation phase to detect and assess damage and to activate the plan;
- Recovery phase to restore temporary IT operations and recover damage done to the original system;
- Reconstitution phase to restore IT system processing capabilities to normal operations.
Identify the activities, resources, and procedures needed to carry out Matrak processing requirements during prolonged interruptions to normal operations.
Identify and define the impact of interruptions to Matrak systems.
Assign responsibilities to designated personnel and provide guidance for recovering Matrak during prolonged periods of interruption to normal operations.
Ensure coordination with other Matrak staff who will participate in the contingency planning strategies.
Ensure coordination with external points of contact and vendors who will participate in the contingency planning strategies.

Example of the types of disasters that would initiate this plan are natural disaster, political disturbances, man made disaster, external human threats, and internal malicious activities.

Matrak defined two categories of systems from a disaster recovery perspective.

Critical Systems. These systems host production application servers/services and database servers/services or are required for functioning of systems that host production applications and data. 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.
Non-critical Systems. These are all systems not considered critical by definition above. 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. These systems are restored at a lower priority than critical systems.

Line of Succession

The following order of succession to ensure that decision-making authority for the Matrak Contingency Plan is uninterrupted. The Chief Technology Officer (CTO) is responsible for ensuring the safety of personnel, the execution of procedures documented within this Matrak Contingency Plan, and the recovery of Matrak technical environments. If the CTO is unable to function as the overall authority or chooses to delegate this responsibility to a successor, the CEO shall function as that authority or choose an alternative delegate. To provide contact initiation should the contingency plan need to be initiated, please use the contact list below.

Brett Hodgkins, CTO: brett@matrak.com.au
Shane Hodgkins, CEO: shane@matrak.com.au

Response Teams and Responsibilities

The following personnel are responsible for responding to a contingency event affecting Matrak infrastructure and systems:

Engineering Team is responsible for recovery of the Matrak hosted environment, all applications, web services, platform and their supporting infrastructure in the Cloud. The team is also responsible for testing re-deployments and assessing damage to the environment. The team reports to the CTO.
Product Manager assists in coordinating customer communication and prioritizing system recovery based on business impact.
CTO is responsible for overall incident coordination, assessing and responding to cybersecurity related incidents according to Matrak Incident Response policy and procedures, and ensuring the physical safety of personnel.

All personnel must maintain local copies of the contact information of the BCDR succession team. Additionally, the CTO must maintain a local copy of this policy in the event Internet access is not available during a disaster scenario.

All executive leadership shall be informed of any and all contingency events. Current members of Matrak leadership team include the CEO, CTO.

General Disaster Recovery Procedures

Notification and Activation Phase

This phase addresses the initial actions taken to detect and assess damage inflicted by a disruption to Matrak. Based on the assessment of the Event, sometimes according to the Matrak Incident Response Policy, the Contingency Plan may be activated by the CTO.

The notification sequence is listed below:

The first responder is to notify the CTO. All known information must be relayed to the CTO.
The CTO is to contact the Response Teams and inform them of the event. The CTO or delegate is responsible to begin assessment procedures.
The CTO is to notify team members and direct them to complete the assessment procedures outlined below to determine the extent of damage and estimated recovery time. If damage assessment cannot be performed locally because of unsafe conditions, the CTO is to following the steps below.
- Damage Assessment Procedures:
- The CTO is to logically assess damage, gain insight into whether the infrastructure is salvageable, and begin to formulate a plan for recovery.
- Alternate Assessment Procedures:
- Upon notification, the CTO is to follow the procedures for damage assessment with the Response Teams.
The Matrak Contingency Plan is to be activated if one or more of the following criteria are met:
- Matrak will be unavailable for more than 48 hours.
- On-premise hosting facility or cloud infrastructure service is damaged and will be unavailable for more than 24 hours.
- Other criteria, as appropriate and as defined by Matrak.
If the plan is to be activated, the CTO is to notify and inform team members of the details of the event and if relocation is required.
Upon notification from the CTO, group leaders and managers are to notify their respective teams. Team members are to be informed of all applicable information and prepared to respond and relocate if necessary.
The CTO is to notify the hosting facility partners that a contingency event has been declared and to ship the necessary materials (as determined by damage assessment) to the alternate site.
The CTO is to notify remaining personnel and executive leadership on the general status of the incident.
Notification can be message, email, or phone.

Recovery Phase

This section provides procedures for recovering Matrak infrastructure and operations at an alternate site, whereas other efforts are directed to repair damage to the original system and capabilities.

Procedures are outlined per team required. Each procedure should be executed in the sequence it is presented to maintain efficient operations.

Recovery Goal: The goal is to rebuild Matrak infrastructure to a production state.

The tasks outlines below are not sequential and some can be run in parallel.

Contact Partners and Customers affected to begin initial communication - DevOps
Assess damage to the environment - DevOps
Create a new production environment using new environment bootstrap automation - DevOps
Ensure secure access to the new environment - Security
Begin code deployment and data replication using pre-established automation - DevOps
Test new environment and applications using pre-written tests - DevOps
Test logging, security, and alerting functionality - DevOps and Security
Assure systems and applications are appropriately patched and up to date - DevOps
Update DNS and other necessary records to point to new environment - DevOps
Update Partners and Customers affected through established channels - DevOps

Reconstitution Phase

This section discusses activities necessary for restoring full Matrak operations at the original or new site. The goal is to restore full operations within 24 hours of a disaster or outage. If necessary, when the hosted data center at the original or new site has been restored, Matrak operations at the alternate site may be transitioned back. The goal is to provide a seamless transition of operations from the alternate site to the computer center.

Original or New Site Restoration
- Repeat steps 5-9 in the Recovery Phase at the original or new site / environment.
- Restoration of Original site is unnecessary for cloud environments, except when required for forensic purpose.
Plan Deactivation
- If the Matrak environment is moved back to the original site from the alternative site, all hardware used at the alternate site should be handled and disposed of according to the Matrak Media Disposal Policy.

Testing and Maintenance

The CTO shall periodically review and update the Contingency Plan to ensure it remains current with Matrak's infrastructure and organizational changes. This review process will also serve as training for personnel involved in the plan's execution.

Work Site Recovery

Matrak operates as a remote-first company with desks available at The Commons QV co-working space in Melbourne. In the event this facility is not functioning due to a disaster, employees will continue to work from home or locate to alternative sites with Internet access. Any facility-related recovery shall be coordinated with The Commons management.

Matrak's organization has the ability to work from any location with Internet access and does not require a specific office facility to maintain operations.

Application Service Event Recovery

A follow up root-cause analysis details (RCA) will be available to customers upon request after the event has transpired for further details to cause and remediation plan for the future. Event Service Level

Short (hours)

Experience a short delay in service.
Matrak will monitor the event and determine course of action. Escalation may be required.

Moderate (days)

Experience a modest delay in service where processes in flight may need to be restarted.
Matrak will monitor the event and determine course of action. Escalation may be required.
Matrak will notify customers of delay in service and provide updates on Matrak’s status page.

Long (a week or more)

Experience a delay in service and processes in flight may need to be restarted.
Matrak will monitor the event and determine course of action. Escalation may be required.
Matrak will notify customers of delay in service and provide updates on Matrak’s status page.

Production Environments and Data Recovery

Production data is backed up to AWS S3 and AWS Glacier within the Sydney region for long term storage and recovery. In an event that requires data to be recovered, it will be retrieved from these backup systems.

Matrak assumes that in the worst-case scenario, if the production environment suffers a complete data loss, the account will be reconstructed from code, and the data restored from the backup systems.

Recovery of production Environments and data should follow the procedures listed above and in Data Management - Backup and Recovery