DR Services Addendum

AEGISYS CLOUD SOLUTIONS

Disaster Recovery Services

Addendum to Master Agreement

AEG-DR-ADD-001   |   January 2025

Published at: aegisys.com/legal/dr-services-addendum

ACCEPTANCE BY CONDUCT By continuing to use Aegisys Disaster Recovery services after the effective date of this Addendum, Client acknowledges that it has read, understood, and agrees to be bound by the terms of this Addendum and the Aegisys Master Agreement. No separate signature is required.

1. Purpose and Incorporation

This Disaster Recovery Services Addendum (“DR Addendum” or “Addendum”) is issued by Aegisys Cloud Solutions (“Aegisys”) and governs the provision of Disaster Recovery (DR) hosting, replication, standby, and related services to clients of Aegisys. This Addendum is incorporated into and forms part of the Aegisys Master Agreement (AEG-MA# 7451), published at aegisys.com/legal/aegisys-master-agreement (“Master Agreement” or “MSA”).

In the event of any conflict between this Addendum and the Master Agreement, this Addendum governs with respect to DR services, except where the Master Agreement expressly provides otherwise. All defined terms in the Master Agreement apply herein unless separately defined.

Conduct-Based Acceptance. Client’s continued use of Aegisys DR services following publication or update of this Addendum constitutes Client’s acceptance of its terms. This acceptance mechanism is consistent with and reinforced by Section 8.1 and Section 19.24 of the Master Agreement. No signature, click-through, or separate written agreement is required.

Client-Specific Details Deferred to Schedule. This Addendum is generic and applies to all Aegisys DR clients. Client-specific environments, recovery targets, contacts, and baseline configurations are documented in a DR Services Schedule (“Schedule”) issued separately by Aegisys to each DR client. The Schedule is incorporated into this Addendum by reference.

2. Definitions

The following terms have the meanings set out below when used in this Addendum or in any DR Services Schedule:

Term	Definition
Canadian Data Residency	The requirement that all Client data processed, stored, or replicated under DR services remains on infrastructure physically located within Canada at all times.
Configuration Drift	The degradation of DR service functionality resulting from changes made to Client’s production environment that were not communicated to Aegisys, causing the DR environment to become misaligned with the production baseline documented in the Schedule.
Disaster Event	A declared failure, outage, or loss of access to Client’s primary production environment that requires activation of Aegisys-hosted DR services.
DR Environment	A hosted standby system, database replica, or recovery resource maintained by Aegisys for Client’s benefit and described in the DR Services Schedule.
DR Services Schedule	A client-specific document issued by Aegisys describing the covered DR environments, reference RPO/RTO targets, environment baseline configuration, and designated contacts. The Schedule is incorporated into this Addendum.
DR Test	A planned, coordinated exercise to validate the operability and currency of a DR Environment, including failover procedures and recovery validation.
Environment Change	Any modification to Client’s production infrastructure that may affect DR replication, VPN connectivity, or Aegisys-integrated services, as described in Section 5 of this Addendum.
Failover Activation	The manual process by which a DR Environment is brought online for Client use following a declared Disaster Event.
Recovery Point Objective (RPO)	The maximum acceptable amount of data loss, measured in time, in the event of a Disaster Event. RPO is a planning reference target and is not a guaranteed service level.
Recovery Time Objective (RTO)	The maximum acceptable duration of service unavailability following a Disaster Event. RTO is a planning reference target and is not a guaranteed service level.
Replication Lag	The elapsed time between a transaction occurring in Client’s production environment and that transaction becoming available in the DR Environment.
Schedule Baseline	The point-in-time snapshot of Client’s production environment recorded in the DR Services Schedule at the time of service commencement or last confirmed review, against which DR services are configured.

3. Scope of DR Services

3.1  Categories of DR Environments

Aegisys provides DR services across the following general categories. The specific environments applicable to each Client are identified in the DR Services Schedule:

• Physical Hosted DR — Aegisys hosts a physical server on behalf of Client within its private cloud infrastructure. Replication is managed at the database or application layer.
• Virtual Hosted DR — Aegisys hosts one or more virtual machines as warm standby targets within its private cloud environment. VMware site replication between Aegisys datacentres provides infrastructure-layer protection.
• Database Replication DR — DR replication is achieved through database-native mechanisms including MSSQL Log Shipping or MSSQL Replication, where no physical or virtual cluster exists at the Client’s production site.
• VPN-Dependent DR — Replication from Client’s on-premise production environment to Aegisys DR systems traverses a managed site-to-site IPSec VPN tunnel maintained between Client’s site and the Aegisys private cloud.
• Active Directory Replica — Aegisys hosts a replica domain controller that receives Active Directory site replication from Client’s primary domain controller over an IPSec VPN tunnel.
• Isolated Sandbox Hosting — Aegisys hosts a non-production, isolated environment (such as a test or sandbox server) that is not a DR replica. Sandbox environments are covered by nightly Barracuda Backup services and are not subject to replication SLAs.

3.2  What Is Always Included

• Hosting of DR environments within Aegisys private cloud infrastructure in Sudbury, Ontario, Canada
• Nightly Barracuda Backup with immutable local and offsite (Montreal, QC) copies for all hosted environments
• Automated backup restorability testing
• VMware site replication between Aegisys dual datacentre locations for virtual hosted workloads
• 24/7 dual SOC monitoring (RocketCyber MDR + Barracuda XDR) of all hosted environments
• Managed firewall and IPSec VPN infrastructure connecting Client to Aegisys
• Aegisys Help Desk access for DR activation requests and incident reporting

3.3  What Is Always Excluded

• Guaranteed RPO or RTO — reference targets in the Schedule are planning guidance only (see Section 4)
• Automated failover — all DR activations require manual coordination between Client IT and Aegisys
• Application-layer support for third-party applications running in DR environments
• DR services for environments not documented in the DR Services Schedule
• Monitoring of Client-side production infrastructure for changes or failures
• Remediation work arising from undisclosed Client environment changes (see Section 5)

4. RPO and RTO — Disclaimer and Reference Targets

No Guaranteed RPO or RTO. Aegisys does not guarantee any specific Recovery Point Objective or Recovery Time Objective for any DR environment. Reference RPO and RTO targets documented in the DR Services Schedule are planning guidance only. They reflect design intent under normal operating conditions and are not service level commitments.

Actual recovery outcomes at the time of a Disaster Event depend on factors including but not limited to:

• The state and currency of replication at the time of the Disaster Event
• Whether Client’s production environment matches the Schedule Baseline or has drifted due to undisclosed changes
• The availability and response time of Client IT personnel required for manual activation steps
• The nature, scope, and cause of the Disaster Event
• Network conditions affecting VPN-dependent replication paths at the time of activation
• Application compatibility between production and DR environment versions

ℹ  NOTE  Aegisys strongly recommends that NPEI and all DR clients formally define and document their RTO and RPO requirements and share them with Aegisys to confirm that current service configurations are capable of meeting those targets. Contact rbeyers@aegisys.com to schedule a DR review.

5. Client Environment Change Notification Obligation

Notification Requirement. Where Aegisys provides services that integrate with, replicate from, or depend upon Client-managed infrastructure, Client must notify Aegisys in writing within five (5) business days of any change to Client’s production environment that may affect such services. Notification must be sent to rbeyers@aegisys.com or submitted through the Aegisys Support Portal at aegisys.myportallogin.com.

5.1  What Constitutes a Notifiable Change

The following changes require notification. This list is illustrative and not exhaustive — when in doubt, Client should notify Aegisys:

• Changes to operating system versions, database engines, or database schemas on systems that are replication sources
• Changes to network infrastructure, including firewall rules, VPN endpoints, routing configurations, or IP addressing
• Changes to Active Directory structure, including domain changes, site topology modifications, or domain controller additions or removals
• Changes to authentication credentials or access permissions affecting Aegisys-connected systems
• Application version upgrades affecting replicated or integrated databases
• Hardware changes to systems that serve as replication or integration sources
• Third-party support or maintenance changes affecting replicated systems (e.g., change of hardware support vendor)

5.2  Consequences of Non-Notification

Aegisys has no independent visibility into Client-managed network or system changes. Where Client fails to provide timely notification as required under this Section:

• Aegisys bears no liability for replication failures or data gaps arising from undisclosed changes
• Aegisys bears no liability for extended RPO or RTO resulting from the discovery of Configuration Drift at the time of Disaster Event activation
• Remediation work required to restore DR service functionality following undisclosed changes is billable at Aegisys standard professional services rates
• Client bears all costs associated with data loss within the RPO gap created by Configuration Drift

5.3  Configuration Drift Acknowledgement

Client acknowledges that Aegisys DR services are configured against the Schedule Baseline documented in the DR Services Schedule. Changes to Client’s production environment without notification may silently degrade or disable DR replication. Aegisys is not responsible for monitoring Client-side infrastructure for changes. Configuration Drift discovered at the time of a Disaster Event may extend recovery time and increase data loss beyond reference targets.

5.4  Annual Environment Review

Aegisys will issue an annual Schedule Review Request to each DR client. Client must respond within thirty (30) days confirming either that the production environment is unchanged or providing details of any changes since the last confirmed review. Non-response within 30 days is documented by Aegisys, and Client bears the risk of Configuration Drift arising from any unconfirmed changes.

6. Technical Limitations

The following limitations apply generally to Aegisys DR services. Client-specific limitations are identified in the DR Services Schedule.

• Source-Site Cluster Dependency — Without a physical or virtual cluster at Client’s production site, DR replication is limited to database-native mechanisms such as MSSQL Log Shipping or database replication. This means failover is warm standby — not automatic or instantaneous.
• Database-Native Replication Constraints — MSSQL Log Shipping and database replication carry inherent RPO limitations tied to the log-ship or replication interval. Data written between the last successful replication event and a Disaster Event may not be present in the DR Environment at the time of activation.
• VPN-Dependent Path Risks — Where replication traverses a site-to-site IPSec VPN tunnel, replication continuity depends on VPN tunnel stability. VPN interruptions caused by Client-side network changes or hardware failures may cause replication gaps. Notification obligations under Section 5 apply.
• No Automated Failover — All DR activations require manual coordination between Client IT personnel and Aegisys. There is no automated failover mechanism. RTO includes the time required for Client IT to declare a Disaster Event and participate in activation procedures.
• Application Version Compatibility — The DR Environment must run application versions compatible with those in production. Upgrades at the production site that are not coordinated with Aegisys may render the DR Environment incompatible at the time of activation.
• Hardware Support Currency — For Client environments running on physical hardware hosted by Aegisys, lapsed hardware support contracts may extend recovery time in the event of hardware failure. Client is responsible for maintaining current hardware support on all Client-owned equipment.

✅  NOTE  Section 2.7 of the Aegisys Master Agreement explicitly carves out the use of a standby system during a documented business continuity event as a permitted use. DR standby environments hosted by Aegisys are authorized for Client’s use during a declared Disaster Event.

7. DR Testing

Annual Minimum. Aegisys recommends that each DR client conduct a minimum of one (1) DR test per calendar year for each covered DR environment. DR testing validates that replication is current, DR systems are functional, and Client IT personnel are familiar with activation procedures.

7.1  Scheduling

DR tests must be scheduled in advance with Aegisys. Client is responsible for initiating test scheduling by contacting Aegisys at least fourteen (14) business days prior to the desired test date. Aegisys will confirm availability and provide a test plan.

7.2  Responsibilities During Testing

• Aegisys — Provides technical support during the DR test, activates the DR environment per the test plan, and documents test results including any replication gaps or application issues identified.
• Client — Provides IT personnel to participate in the test, validates application functionality in the DR environment, and reviews and signs off on test results.

7.3  Remediation Following Testing

Where DR testing identifies replication gaps, application incompatibilities, or other issues arising from Client’s production environment, remediation work will be scoped and quoted by Aegisys. Remediation arising from undisclosed Client environment changes is billable per Section 5.2. Remediation arising from Aegisys infrastructure issues will be addressed by Aegisys at no charge.

8. Failover Activation Process

The following describes the general process for activating Aegisys-hosted DR environments during a declared Disaster Event. Client-specific contacts and environment-specific activation steps are documented in the DR Services Schedule.

8.1  Declaration

Client IT must formally declare a Disaster Event by contacting Aegisys via the primary escalation path identified in the DR Services Schedule. Aegisys Help Desk is available at 705-222-3652 or through aegisys.myportallogin.com. After-hours escalation is available at 1-866-961-1805, Option 9.

8.2  General Activation Steps

• Client IT declares Disaster Event and contacts Aegisys via the Schedule-defined escalation path
• Aegisys confirms receipt and initiates DR activation procedures for covered environments
• Aegisys validates replication currency and advises Client of any known data gap (RPO status)
• Aegisys brings DR environment online; Client IT validates application functionality
• Both parties confirm successful activation and document the event

8.3  Client Responsibilities During Activation

• Provide available IT personnel to participate in activation coordination
• Validate application-layer functionality in the DR environment following infrastructure activation by Aegisys
• Manage any DNS, routing, or application configuration changes required to redirect operations to the DR environment
• Notify Aegisys promptly when primary site recovery is complete and failback is required

ℹ  NOTE  Failback — returning operations from the Aegisys DR environment to Client’s primary site — requires separate coordination with Aegisys and should be planned in advance. Failback procedures are documented in the DR Services Schedule.

9. Canadian Data Residency

All Client data processed, stored, replicated, or backed up under Aegisys DR services is hosted exclusively on infrastructure physically located within Canada. This includes:

• Primary DR hosting: Aegisys private cloud — Sudbury, Ontario
• VMware site replication target: Aegisys alternate datacentre — Sudbury, Ontario
• Barracuda Backup offsite replication: Barracuda-managed datacentres — Montreal, Quebec

Override of MSA Section 2.1. This Section expressly overrides the “Canada and United States” hosting language in Section 2.1 of the Master Agreement with respect to DR services. No Client data subject to this Addendum is transferred to or stored in the United States or any jurisdiction outside Canada.

Canadian data residency under this Addendum satisfies applicable Canadian federal and provincial privacy legislation, including PIPEDA and applicable provincial equivalents, with respect to data hosting location.

10. Security and Confidentiality

SOC 2 Type II Certification. Aegisys holds an active SOC 2 Type II certification, independently audited against the AICPA Trust Services Criteria. SOC 2 Type II certification is the governing security control framework for all Aegisys DR services. Client and its auditors may review Aegisys trust documentation at trust.aegisys.com.

Dual SOC Monitoring. All Aegisys-hosted DR environments are covered by continuous 24/7 dual Security Operations Centre (SOC) monitoring via RocketCyber MDR and Barracuda XDR platforms. SOC coverage includes threat detection, alert triage, incident response, and the ability to isolate affected environments in the event of a security incident.

VLAN Segmentation. Client DR workloads are logically isolated from all other Aegisys client environments via dedicated VLAN segmentation within the Aegisys private cloud fabric.

Confidentiality. All Client data hosted within Aegisys DR environments is subject to the confidentiality obligations in Section 7 of the Master Agreement.

11. Limitation of Liability — DR Specific

General. The limitation of liability provisions in Section 17 of the Master Agreement apply to all DR services. Aegisys’s aggregate liability for any claim arising from DR services shall not exceed the fees paid for those services in the twelve (12) months preceding the claim.

No Liability for RPO Data Gap. Aegisys bears no liability for the loss of data that falls within the RPO gap — that is, data created or modified between the last successful replication event and the time of Disaster Event activation. Client acknowledges that replication-based DR services are inherently asynchronous and that some data loss is an expected characteristic of this architecture.

No Liability for Client-Caused Delays. Aegisys bears no liability for extended RTO resulting from delays caused by Client, including but not limited to: unavailability of Client IT personnel during activation, Client failure to validate application functionality, or Client-side DNS or routing changes required for failover.

No Liability for Undisclosed Environment Changes. Aegisys bears no liability — including no liability for data loss, extended recovery time, or remediation costs — for DR service failures arising from Client environment changes that were not disclosed to Aegisys as required under Section 5 of this Addendum. This limitation applies regardless of whether the change was intentional, inadvertent, or made by a third party on Client’s behalf.

⚠  NOTE  The liability limitations in this Section are a direct consequence of the architecture of replication-based DR services. Aegisys configures and maintains DR environments based on documented baselines. Client-side changes that are not communicated to Aegisys are outside Aegisys’s knowledge and control.

12. Fees and Payment

Recurring Fees. Monthly recurring fees for DR hosting, replication, backup, and monitoring services are as set out in the applicable Order or DR Services Schedule. Recurring fees cover the standard scope of services described in Section 3.2 of this Addendum.

Billable Remediation. Remediation work required as a result of Client’s failure to notify Aegisys of environment changes (Section 5), or arising from Configuration Drift discovered during DR testing or Disaster Event activation, is not covered by recurring fees and will be billed at Aegisys standard professional services rates. Aegisys will provide a scope and estimate prior to commencing billable remediation work.

Payment Terms. All payment obligations are governed by Section 6 of the Master Agreement.

13. Term and Termination

Term. This Addendum is effective from the date of publication and remains in effect for so long as Client uses Aegisys DR services, unless terminated in accordance with this Section or the Master Agreement.

Termination Notice. Either party may terminate DR services under this Addendum upon ninety (90) days written notice to the other party, subject to any Committed Service Term in effect under the Master Agreement.

Data Retention on Termination. Upon termination of DR services, Aegisys will retain Client data in DR environments for thirty (30) days following the effective termination date to allow Client to retrieve or transfer data. After thirty (30) days, Aegisys will permanently delete all Client DR data from Aegisys systems. Client is responsible for arranging data retrieval prior to deletion.

Effect of Termination. Termination of DR services does not terminate the Master Agreement. Sections of this Addendum that by their nature should survive termination — including limitation of liability, confidentiality, and payment obligations — will survive.

14. DR Services Schedule

What the Schedule Contains. For each DR client, Aegisys issues a DR Services Schedule identifying the specific covered DR environments, reference RPO/RTO targets, the Schedule Baseline configuration, designated contacts, and any client-specific deviations from standard Addendum terms.

Schedule Supersedes Addendum for Client-Specific Details. Where the Schedule specifies terms applicable to a particular Client environment, the Schedule governs over the general terms of this Addendum for that environment and that Client.

Acceptance of Schedule. Client acknowledges the DR Services Schedule by continued use of DR services following delivery of the Schedule. No separate signature is required.

Schedule Delivery. Aegisys delivers the DR Services Schedule to Client via the Aegisys Client Portal (aegisys.myportallogin.com) and by email to the designated Client IT contact identified in the Schedule. Client is responsible for maintaining current contact information in the Aegisys Portal per Section 3.3 of the Master Agreement.

Self-Service Access. The following resources are available to DR clients without requiring contact with Aegisys:

Resource	URL
Master Agreement	aegisys.com/legal/aegisys-master-agreement
DR Services Addendum	aegisys.com/legal/dr-services-addendum (this document)
Service Status	status.aegisys.com
Trust Centre (SOC 2 Type II)	trust.aegisys.com
Support Portal	aegisys.myportallogin.com

15. General Provisions

Governing Law. This Addendum is governed by the laws of the Province of Ontario and the federal laws of Canada applicable therein, consistent with Section 19.20 of the Master Agreement.

Amendments. Aegisys may update this Addendum at any time by posting the updated version at aegisys.com/legal/dr-services-addendum and providing thirty (30) days notice to DR clients per Section 19.24 of the Master Agreement. Continued use of DR services following the notice period constitutes acceptance of the updated terms.

Entire Agreement. Together with the Master Agreement and the applicable DR Services Schedule, this Addendum constitutes the entire agreement between Aegisys and Client with respect to DR services and supersedes all prior representations, discussions, and agreements relating to such services.

Severability. If any provision of this Addendum is found to be unenforceable, the remaining provisions continue in full force and effect.

Language. This Addendum has been drafted in the English language, which is the controlling version.

Aegisys Cloud Solutions

7-598 Falconbridge Road, Suite 7, Sudbury, Ontario, Canada P3A 5K6

705-222-3652   |   1-866-961-1805   |   aegisys.com   |   trust.aegisys.com

AEG-DR-ADD-001   |   Published June 2026   |   © 1999–2026 Aegisys Cloud Solutions (1468625 Ontario Limited). All rights reserved.