Disaster Recovery Plan
EventLinx has a recovery plan to restore systems when something breaks, such as server failures, outages, cyber incidents, or major service disruptions. The main goal is simple: bring back the core ticketing system first, then restore everything else afterward.
The documentation site and other non-critical services are lower priority and are only restored once the main platform is stable again.
What this plan covers
This plan applies when systems stop working due to infrastructure problems, software failures, security incidents, or external outages like power or network loss.
To handle this, EventLinx relies on backups and redundant systems so recovery does not depend on manual fixes made under pressure during an incident.
Recovery targets
EventLinx uses internal targets to guide how quickly systems should come back online. Critical systems like ticketing and APIs are prioritized and are generally restored within a few hours. Less important systems may take longer, sometimes up to a full day.
Data loss is kept minimal through regular backups. Critical systems are designed to lose as little recent data as possible, usually around an hour, while less important systems may tolerate longer recovery windows.
How recovery is handled
Recovery starts by stabilizing affected systems so the problem does not get worse. After that, core infrastructure like servers, networking, and services are restored.
Once systems are back, data is recovered from backups if needed. Everything is then checked to make sure it is working correctly and has not been corrupted or compromised. Only after this validation step are services brought back online for users.
Who is involved
Recovery is mainly handled by technical staff who focus on bringing systems and data back online. Management is involved when decisions need approval, especially if the outage is serious or unclear.
Communication is kept separate from technical work so that updates stay consistent and do not interfere with recovery actions. In most cases, a small coordination group keeps everyone aligned so tasks do not overlap or conflict.
What we assume during recovery
This plan assumes that backups exist and are usable when needed. It also assumes that key systems and staff are available during the incident, and that external providers such as hosting or network services can support recovery if required.
If any of these assumptions are not true during an incident, recovery may take longer. In that case, priorities are adjusted so the most important systems are restored first.
Testing and upkeep
Recovery procedures are not only used during emergencies. They are tested from time to time to confirm that backups work and systems can actually be restored when needed.
These tests also help confirm that roles and responsibilities still make sense and that recovery steps match the current system setup. When infrastructure changes, the recovery plan is updated to stay accurate.
Security and privacy during recovery
Even during recovery situations, EventLinx continues to follow normal security and privacy rules. Access to systems remains controlled, and personal information is still protected under PIPEDA requirements.
Recovery work does not remove or bypass security controls. Instead, it operates within them to restore services safely and correctly.