Business Continuity & Disaster Recovery Policy

The Business Continuity & Disaster Recovery Policy ("BCDR Policy") establishes a formal framework to ensure ZynReach's ability to achieve the following, as part of ZynReach's governance, security, and business continuity framework:

• Maintain critical services and operations.
• Minimize the impact of major outages and incidents.
• Respond to disasters and operational disruptions.
• Restore priority services and systems.
• Protect Customer Data.
• Minimize data loss.
• Support customers during outage events.
• Restore operations in an organized manner.
• Improve ZynReach's resilience against risk.

This Policy applies to the operations, systems, and services that fall within ZynReach's control and that are necessary for delivering the Services. This Policy does not automatically extend to Customer systems or infrastructure exclusively under the control of third parties. It may include:

• ZynReach Platform.
• Production Environment.
• Databases.
• Application Services.
• APIs.
• Authentication Services.
• Storage.
• Monitoring.
• Logging.
• Backup Systems.
• Supporting Infrastructure.
• Critical Internal Operations.
• Key Third-Party Dependencies.

ZynReach seeks to achieve the following objectives:

• Protect the integrity of data.
• Minimize service disruption periods.
• Identify priority systems.
• Ensure the existence of actionable recovery procedures.
• Maintain appropriate communication channels during crises.
• Test recovery plans periodically.
• Review plans after incidents and tests.
• Continuously improve operational resilience.

ZynReach's approach to continuity management is founded on the following principles:

• Resilience — designing operations and systems to reasonably withstand foreseeable disruptions.
• Recovery — maintaining organized mechanisms for restoring critical services.
• Redundancy — using redundancy and alternatives where technically and economically appropriate.
• Prioritization — giving priority to the most important services and systems.
• Continuous Improvement — improving continuity plans based on testing, incidents, and changes in risk.

For purposes of this Policy, a "Disaster" may include any event that causes a material disruption to critical systems or operations, including:

• Infrastructure failure.
• Cloud Service outage.
• Database failure.
• Data loss or corruption.
• Cyberattack.
• Ransomware.
• Security Incident.
• Natural Disaster.
• Fire.
• Power Failure.
• Network Failure.
• Major Software Failure.
• Human Error.
• Failure of a key vendor.
• Other events with a material impact.

Business Continuity means ZynReach's ability to maintain or restore essential functions and operations within an appropriate timeframe following a disruption.

Disaster Recovery means the set of technical and organizational procedures used to restore the following after the occurrence of a disaster or material failure:

• Systems.
• Applications.
• Databases.
• Data.
• Infrastructure.

In accordance with its risk management program, ZynReach assesses the impact of the loss or disruption of critical functions and systems. This assessment may include:

• Impact of the disruption.
• Importance of the service.
• Dependencies.
• Affected customers.
• Recovery requirements.
• Financial impact.
• Operational impact.
• Legal or regulatory impact.

Systems and services may be classified into priority tiers as follows:

• Critical — systems whose disruption causes a material impact on service delivery.
• High — systems of significant importance that must be restored within an appropriate timeframe.
• Medium — systems whose disruption can be tolerated for a limited period.
• Low — non-critical systems whose restoration may be deferred.

Recovery order is determined according to the following priority:

• Data safety and security.
• Critical services.
• Core customer-facing services.
• Supporting services.
• Non-critical systems.

RTO (Recovery Time Objective) is the planned target timeframe for restoring a function or service following a disruption.

RTO does not represent an absolute guarantee of recovery in every incident, unless expressly stated in an SLA or commercial agreement.

RTO is determined for each critical service based on risk assessment and infrastructure design.

RPO (Recovery Point Objective) is the maximum tolerable amount of data loss, measured in time, in a recovery scenario. RPO is determined based on the following, and no specified RPO constitutes a contractual commitment unless expressly agreed:

• Type of data.
• System.
• Backup technology.
• Service requirements.

ZynReach may maintain an internal matrix specifying RTO/RPO for each critical system, updated whenever material changes occur in:

• Architecture.
• Services.
• Customers.
• Risk.

ZynReach maintains appropriate continuity plans for critical operations and services. These plans may include:

• Emergency procedures.
• Responsibilities.
• Points of contact.
• Alternatives.
• Recovery priorities.
• Escalation mechanisms.

ZynReach maintains a Disaster Recovery Plan appropriate to the nature of its services. It may include:

• Activation Criteria.
• Recovery Procedures.
• System Dependencies.
• Backup Recovery.
• Infrastructure Recovery.
• Database Recovery.
• Validation.
• Failback.

Depending on the technical design of the service, ZynReach uses appropriate measures to increase infrastructure resilience; the use of any specific technology does not mean that all components of the service are protected against all types of disasters. These measures may include:

• Redundancy.
• Replication.
• Automated Recovery.
• Failover.
• Backup Infrastructure.
• Geographic Redundancy.

Where ZynReach relies on Cloud Providers, the continuity of certain components depends on the availability and services of those providers.

ZynReach manages the risks that fall within its control.

To a reasonable extent, ZynReach identifies critical external dependencies that may affect service continuity. These may include:

• Cloud Providers.
• DNS Providers.
• Payment Providers.
• Email Providers.
• Authentication Providers.
• Monitoring Providers.
• Communication Providers.

ZynReach seeks to assess the risks of key vendors and take appropriate measures when necessary. These may include:

• Vendor alternatives.
• Redundancy.
• Contractual Protections.
• Business Continuity Assessment.

ZynReach uses appropriate backup mechanisms for data and systems that require them, in accordance with the technical design of the service. These may include:

• Automated Backups.
• Database Backups.
• Incremental Backups.
• Full Backups.
• Encrypted Backups.

ZynReach applies appropriate controls to protect backups from:

• Unauthorized access.
• Unauthorized modification.
• Unauthorized deletion.
• Corruption.

Backup retention periods are determined according to:

• The nature of the system.
• Operational requirements.
• Risk.
• Legal requirements.
• The Data Retention Policy.

ZynReach conducts appropriate tests to verify the restorability of backups.

The mere existence of backups does not, by itself, guarantee that every backup can be restored under all circumstances.

Recovery plans include appropriate procedures for restoring critical databases. These may include:

• Database Restore.
• Replication Recovery.
• Integrity Validation.
• Consistency Checks.

Following recovery, appropriate verification processes are carried out to confirm the integrity of data and systems before the service is fully restored, depending on the nature of the incident.

Where Failover mechanisms are available, they may be used to reduce the impact of component failures.

They may be triggered automatically or manually, depending on the design of the service.

Once the primary environment has stabilized, Failback procedures may be carried out to return operations to the primary environment.

This is done after verifying the integrity of systems and data.

In the event of a material incident, ZynReach may activate crisis management procedures. These may include:

• Forming an Incident Response Team.
• Designating an Incident Commander.
• Setting recovery priorities.
• Managing communications.
• Coordinating technical teams.
• Documenting decisions.

An Incident Commander may be appointed, whose responsibilities include:

• Coordinating the response.
• Setting priorities.
• Managing escalation.
• Coordinating teams.
• Overseeing recovery.
• Managing internal communications.

Whether an event warrants activation of the Disaster Recovery Plan is determined based on:

• The level of impact.
• The duration of the disruption.
• The scope of the problem.
• Whether recovery is possible through normal means.
• The risks associated with continuing as-is.

Incidents may be classified as follows:

• Severity 1 — Critical: material, widespread impact on a core service.
• Severity 2 — High: significant impact on an important function.
• Severity 3 — Medium: limited impact manageable through normal operations.
• Severity 4 — Low: minor impact.

Escalation is carried out according to the severity of the incident. It may include:

• Technical Escalation.
• Management Escalation.
• Security Escalation.
• Legal Escalation.
• Customer Communication.

ZynReach maintains appropriate channels for communication during major incidents. These may include:

• Email.
• Status Page.
• Support channels.
• Internal management channels.

When a material incident affects the services provided to a customer, ZynReach may provide appropriate updates in accordance with:

• The SLA.
• The Terms of Service.
• The DPA.
• The Incident Response Policy.

ZynReach may use a Status Page to inform customers of:

• Outages.
• Maintenance.
• Known issues.
• Recovery.

Appropriate, secure communication channels must be used when handling sensitive information related to incidents.

Disaster recovery plans include security scenarios, such as:

• Ransomware.
• Malware.
• Account Compromise.
• Data Corruption.
• Unauthorized Access.
• Infrastructure Attack.

In the event of suspected Ransomware, ZynReach may:

• Isolate affected systems.
• Prevent further spread.
• Protect backups.
• Investigate the scope of impact.
• Restore systems from trusted sources.
• Verify the integrity of the environment before resuming operations.

ZynReach seeks to use appropriate controls to reduce the likelihood that backups will be affected by large-scale security incidents.

Before a service is considered restored, appropriate verification tests are conducted depending on the nature of the incident. These may include:

• Application Health Checks.
• Database Integrity Checks.
• Authentication Tests.
• API Tests.
• Security Checks.

Following recovery, the level of monitoring may be increased for an appropriate period to confirm the stability of the service.

If a primary communication channel fails, alternative channels identified within internal emergency procedures may be used.

Where appropriate, ZynReach maintains operational capability allowing certain functions to continue from alternative locations or environments.

ZynReach identifies the functions and roles considered essential during emergencies. These may include:

• Engineering.
• Infrastructure.
• Security.
• Operations.
• Customer Support.
• Management.
• Legal.

ZynReach seeks to reduce reliance on any single individual in critical roles through:

• Documenting procedures.
• Sharing knowledge.
• Identifying alternates.
• Cross-Training.

Appropriate information is maintained regarding the systems and assets considered necessary for recovery.

Critical recovery procedures must be documented in a manner that enables authorized personnel to carry them out.

Recovery procedures are subject to appropriate access controls.

High-risk procedures may only be carried out by authorized personnel.

Emergency procedures may be applied to expedite changes during critical incidents.

Nonetheless, such changes must be documented and reviewed once the crisis has ended.

Emergency Changes may be implemented when necessary:

• To stop the spread of an incident.
• To restore service.
• To protect data.
• To prevent further harm.

Material decisions made during incidents must be documented, where possible, including:

• The decision.
• The time.
• The responsible person.
• The rationale for the decision.
• The outcome.

ZynReach conducts appropriate testing of the BCDR plan. This may include:

• Tabletop Exercises.
• Backup Restore Tests.
• Failover Tests.
• Recovery Simulations.
• Communication Tests.

Hypothetical scenarios may be conducted to review teams' response capability without affecting the Production Environment.

The restoration of systems and data may be tested periodically based on risk and priority.

The results of significant tests are documented, including:

• The scenario.
• The date.
• The systems involved.
• The outcome.
• Issues identified.
• Corrective actions.

Following significant tests or incidents, lessons learned and appropriate corrective actions are identified.

A corrective action plan may be established that includes:

• The action.
• The responsible person.
• The priority.
• The target date.
• The status.

Continuity and recovery plans are reviewed:

• Periodically.
• After major incidents.
• After significant tests.
• When the technical architecture changes.
• When services change.
• When new risks emerge.

The impact of material changes must be considered with respect to:

• RTO.
• RPO.
• Dependencies.
• Backup.
• Recovery.
• Availability.

When a key vendor experiences a failure, ZynReach assesses its impact and activates alternative measures where available.

ZynReach does not guarantee the continuity of all external services, and the full recovery of certain functions may therefore depend on the restoration of vendor services.

Appropriate security controls must be maintained during recovery operations.

Emergencies must not result in the unjustified removal of security controls.

Temporary access privileges may be granted during recovery when necessary. In such cases:

• Access must be restricted.
• Use must be logged.
• Access must be revoked once no longer needed.

The following must be protected during recovery operations:

• Credentials.
• API Keys.
• Encryption Keys.
• Secrets.

Recovery procedures do not automatically alter the Data Retention Policy.

Deletion is handled in accordance with applicable policies, contracts, and laws, even during recovery operations, to the extent practicable.

Sufficient documentation must be maintained to support execution of the recovery plan. This may include:

• Architecture Diagrams.
• Recovery Runbooks.
• Contact Lists.
• System Dependencies.
• Backup Procedures.
• Escalation Procedures.

Dedicated Runbooks may be created for critical systems, containing recovery and verification steps.

Access to sensitive Runbooks is restricted in accordance with the principle of Least Privilege.

Management may establish a Business Continuity Committee or team responsible for:

• Reviewing risks.
• Reviewing plans.
• Overseeing testing.
• Overseeing corrective actions.

Management is responsible for providing:

• Appropriate resources.
• Authority.
• Priorities.
• The support necessary for the BCDR program.

The Security Team's responsibilities may include:

• Supporting incident response.
• Assessing security risks.
• Protecting data.
• Investigating incidents.
• Supporting secure recovery.

The responsibilities of the Engineering / Infrastructure team include:

• Restoring systems.
• Infrastructure.
• Databases.
• Backups.
• Failover.
• Validation.

The responsibilities of the Customer Support team include:

• Receiving customer reports.
• Relaying appropriate information.
• Updating customers in accordance with instructions.
• Escalating critical issues.

The Legal / Compliance team may participate in:

• Legal notifications.
• Regulatory requirements.
• Assessing contractual obligations.
• Managing legal communications.

The Customer remains responsible for:

• Its own internal continuity plans.
• Its systems.
• Its devices.
• Its local data.
• Integrations it manages.
• User accounts.

Service continuity relies on a shared responsibility model.

ZynReach is responsible for systems within its control, while the Customer is responsible for systems and operations within its own control.

Enterprise Customers must assess their reliance on ZynReach and prepare appropriate alternative plans for their business where necessary.

ZynReach may provide data export mechanisms in accordance with the plan, contract, and available functionality.

Enterprise Customers may request appropriate information about the BCDR program, subject to:

• Confidentiality.
• Security.
• The rights of other customers.
• Trade secrets.

Appropriate summaries or evidence of continuity testing may be provided to Enterprise Customers where the nature of the agreement permits.

ZynReach is not obligated to disclose details of its Recovery Architecture or Security Architecture where disclosure could increase security risk.

Where a separate SLA exists, any specific contractual commitments regarding the following are governed by the terms of the SLA:

• Availability.
• RTO.
• RPO.
• Service Credits.

This Policy operates in conjunction with the Incident Response & Security Breach Notification Policy.

The Incident Response Policy sets out the procedures for handling security incidents, while this Policy sets out the framework for business continuity and recovery.

This Policy operates in conjunction with the Security & Trust Policy and sets out the resilience and recovery procedures in detail.

Data is handled during and after recovery in accordance with the Data Retention & Deletion Policy and the DPA.

Where an Enterprise Security Addendum exists, this Policy is to be read together with it.

Where a Customer's contract contains a specific BCDR commitment, the commercial agreement governs to the extent of any conflict.

No internal recovery objectives constitute a contractual guarantee unless expressly incorporated into an SLA or commercial agreement.

ZynReach works to achieve appropriate levels of resilience and availability; however, it cannot guarantee that no outage, failure, or disaster will occur.

ZynReach takes appropriate measures to reduce the risk of data loss; however, backups and recovery procedures do not constitute an absolute guarantee against data loss under all circumstances.

This Policy does not affect the Force Majeure provisions set out in the Terms of Service or the commercial agreement.

Where an event involves a Security Incident, the relevant Incident Response procedures apply in addition to BCDR procedures.

ZynReach complies with the legal and regulatory requirements applicable to it concerning business continuity and data protection.

Records relating to BCDR testing, incidents, and corrective actions are retained in accordance with internal retention policies.

Sensitive BCDR information, including Recovery Architecture, Runbooks, and security details, is considered confidential and is not disclosed publicly except to the extent appropriate.

Any material exception to this Policy must be:

• Documented.
• Justified.
• Approved by the competent authority.
• Time-limited, where possible.

Violation of this Policy's requirements may result in:

• Corrective action.
• Management review.
• Changes to access privileges.
• Disciplinary action in accordance with internal policies.

ZynReach is committed to continuously reviewing and improving the BCDR program based on:

• Incidents.
• Testing.
• Technical changes.
• New risks.
• Customer requirements.
• Legal requirements.

This Policy must be reviewed periodically, at a minimum in accordance with ZynReach's approved internal review cycle, or upon the occurrence of a material change requiring review.

The following table sets out the record details for this document:

• Document Name — Business Continuity & Disaster Recovery Policy.
• Abbreviation — BCDR Policy.
• Company — Zyntra Digital.
• Platform — ZynReach.
• Website — zynreach.com.
• Version — 1.0.
• Effective Date — August 31, 2026.
• Classification — Internal / Enterprise / Security.
• Owner — Security / Operations / Management.
• Review — Periodic, or upon a material change.
• Related Documents — Security & Trust Policy / Incident Response Policy / Enterprise Security Addendum / DPA / SLA / Data Retention & Deletion Policy.

Zyntra Digital / ZynReach approves this document in accordance with the following details:

• Authorized Signatory Name: __________
• Job Title: __________
• Signature: __________
• Date: __________

This document represents a general framework for ZynReach's business continuity and disaster recovery program.

Unless expressly incorporated into a commercial agreement, this document does not constitute a contractual guarantee of any specific level of availability, RTO, RPO, or protection against data loss.

The obligations owed to each Enterprise Customer are governed by the applicable agreements, contracts, SLAs, and DPA.

© 2026 Zyntra Digital. All Rights Reserved.