Disaster Recovery Plan (DRP)

Version: 3.2
Date: December 2025

Table of Contents

1. Introduction
2. Purpose
3. Scope
4. Assumptions
5. Recovery Teams
6. Team Member Responsibilities
7. Disaster Declaration
8. Invoking the Plan
9. Recovery Time Objective (RTO)
10. Recovery Point Objective (RPO)
11. External Communications
12. Vendor Communication Protocol
13. Crucial Vendor Contact Information
14. Data Management and Backups
15. Data Retention and Disposal
16. Security Assessment for Disasters
17. Privacy Incident and Data Breach Management
18. Plan Review and Maintenance
19. Status Reporting to Event Manager
20. Determining the Course of Action
21. Infrastructure Resilience and High Availability
22. Incident Detection and Monitoring
23. Recovery Procedures
24. Backup and Data Recovery Strategy
25. Security Incident Handling During Disasters
26. Customer Notification Procedures
27. Third-Party Vendor Dependencies
28. Documentation and Evidence Retention
29. Continuous Improvement
30. Security Incident Management
31. Alignment with Business Continuity Plan (BCP)
    Appendix A – Emergency Contacts

‍

1. Introduction

This Disaster Recovery Plan outlines the procedures and actions Monada.ai must follow to recover from disasters, minimizing disruptions and restoring core operations effectively.

2. Purpose

The purpose of this Disaster Recovery Plan (DRP) is to define the processes and responsibilities required to restore Monada.ai’s critical systems and services following a disaster or major operational disruption.

This plan establishes the framework for detecting incidents, coordinating response efforts, recovering affected systems, and restoring normal service operations within the defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The DRP aims to:

• Ensure the rapid recovery of critical systems and infrastructure
• Minimize disruption to customer services and business operations
• Protect the confidentiality, integrity, and availability of customer data
• Provide clear roles, responsibilities, and procedures for incident response and recovery
• Support effective communication with internal teams, customers, and vendors during disaster events
• Enable continuous improvement through testing, review, and post-incident analysis

‍3. Scope

This Disaster Recovery Plan applies to Monada.ai’s production systems, cloud infrastructure, and operational processes that support the delivery of the Monada platform and associated services.

The plan covers technical incidents and disasters that may affect the availability, integrity, or security of production systems and customer data, including infrastructure failures, service outages, security incidents, and other operational disruptions requiring coordinated recovery actions.

This DRP focuses specifically on technical system recovery and platform availability.

Business continuity aspects related to workforce availability, organizational operations, and broader operational continuity are addressed separately within Monada’s Business Continuity Plan (BCP).

The DRP applies to Monada personnel responsible for operating, maintaining, and recovering the platform infrastructure and services.

4. Assumptions

• Key personnel or their alternates will be available during a disaster.
• This document will remain accessible in a secure, redundant environment.
• A single, unified recovery procedure will be in place for critical resources.

5. Recovery Teams

• Event Manager: Oversees the overall disaster recovery process. Shahar Weinberg, CEO
• Disaster Recovery Team (DRT): Executes recovery operations.: Adi Ben Mayor, CPO

6. Team Member Responsibilities

• Designate an alternate for each team member.
• Maintain and regularly update contact lists.
• Ensure all team members are familiar with this DRP.

7. Disaster Declaration

A disaster is declared when any of the following occurs:

• Service disruption for at least 10% of customers.
• Failure of a core system component.
• Disruption of critical workflows.

8. Invoking the Plan

Upon declaring a disaster, the DRP is activated, and problem management protocols are followed until normal operations resume.

9. Recovery Time Objective (RTO)

• RTO: 24 hours

10. Recovery Point Objective (RPO)

• RPO: 12 hours

11. External Communications

• Public Relations (PR): Manages external communication with customers and media.
• Legal Team: Handles interactions with legal authorities.

12. Vendor Communication Protocol

The DRT will immediately notify relevant vendors upon disaster declaration.

13. Crucial Vendor Contact Information

Critical vendor contact details are available in Monada.ai's secure repository.

14. Data Management and Backups

• Daily backups are maintained for critical databases and application file systems.
• Backup data is retained for 25 days in a geographically remote location.
• Access to backups is restricted to authorized personnel.

‍

15. Data Retention and Disposal

Monada maintains data retention and disposal practices to ensure that personal data and customer information are retained only for the period necessary to provide the contracted services and in accordance with applicable contractual and legal requirements.

Customer Data Retention

Customer data stored within the Monada platform remains under the control of the customer and is retained for the duration of the active service relationship unless the customer requests earlier deletion or different retention arrangements are contractually defined.

Authorized customer administrators may export their data at any time using platform functionality or by requesting assistance from Monada support.

Backup Retention

Production databases are automatically backed up using AWS managed backup services. Backup data is retained for up to 25 days, after which it is automatically overwritten according to the defined backup lifecycle policy.

Data Deletion

Upon termination of the service or upon customer request:

• Customer data can be exported.
• Data is removed from active production systems.
• Remaining copies contained within backup systems expire automatically through the backup retention cycle.

Infrastructure and Media Disposal

Monada operates on AWS cloud infrastructure. Physical storage media lifecycle management and destruction are handled by AWS according to its data center security controls. Storage devices that may contain customer data are sanitized or destroyed following industry standards such as NIST SP 800-88 before disposal.

Customer-Specific Requirements

Where required, Monada can review and align data retention schedules with customer-specific contractual, regulatory, or operational requirements.

16. Security Assessment for Disasters

In the event of a security breach, the CISO conducts a thorough assessment to identify affected systems.

17. Privacy Incident and Data Breach Management

Monada maintains procedures for identifying, managing, and resolving privacy or security incidents that may affect customer data.

Detection
Security or privacy incidents may be detected through monitoring systems, automated alerts, internal reviews, or reports from users or customers.

Assessment
The engineering team evaluates the incident to determine its scope, affected systems, and potential impact on customer or personal data.

Containment
Immediate measures are taken to isolate affected systems and prevent further exposure.

Investigation
System logs and infrastructure monitoring tools are reviewed to identify the root cause and extent of the incident.

Notification
If an incident may impact customer data, affected customers will be notified in accordance with contractual obligations and applicable regulatory requirements.

Remediation
Corrective actions and security improvements are implemented to prevent recurrence.

Documentation
All incidents are documented and reviewed internally to strengthen security practices and response procedures.

18. Plan Review and Maintenance

• Annual review and biannual testing (mock disasters, walkthroughs, or component testing).
• Regular updates to personnel and contact information.

19. Status Reporting to Event Manager

The DRT provides updates to the Event Manager, including:

• Disaster type and damage summary.
• Ongoing recovery efforts and required resources.

20. Determining the Course of Action

The Event Manager decides on the next steps based on DRT input:

• No Disaster Declared: Address the issue without activating the DRP.
• Disaster Declared: Implement recovery procedures immediately.

For further details on team roles, contact lists, or process flows, refer to the appendices.

21. Infrastructure Resilience and High Availability

Monada.ai operates on cloud infrastructure designed to provide resilience and service continuity.

Key architectural controls include:

• Deployment on AWS cloud infrastructure with built-in redundancy.
• Use of multiple availability zones where applicable to reduce single-point failures.
• Infrastructure components designed to support horizontal scaling and service continuity.
• Automated monitoring and alerting to detect service degradation or outages.

These architectural practices reduce the likelihood of full system outages and support faster recovery during incidents.

22. Incident Detection and Monitoring

Monada.ai maintains monitoring mechanisms to detect operational issues and potential disasters.

Monitoring includes:

• Infrastructure monitoring (availability, latency, system health).
• Application-level monitoring.
• Log aggregation and alerting for abnormal system behavior.
• Automated alerts to the engineering team when predefined thresholds are exceeded.

These monitoring capabilities allow the Disaster Recovery Team to rapidly detect incidents and begin remediation procedures.

23. Recovery Procedures

In the event of a declared disaster, the Disaster Recovery Team will follow these recovery phases:

Phase 1: Incident Identification

• Confirm service degradation or outage.
• Assess affected systems and potential root cause.
• Notify Event Manager.

Phase 2:  Containment

• Isolate affected systems where applicable.
• Prevent further service degradation or data integrity risks.

Phase 3: Recovery

• Restore services from backup or redeploy infrastructure components.
• Validate system integrity and data consistency.

Phase 4: Service Restoration

• Gradually restore customer access.
• Monitor system stability.

Phase 5: Post-Incident Review

• Conduct internal review.
• Document lessons learned.
• Update DRP procedures if necessary.

24. Backup and Data Recovery Strategy

Monada.ai maintains backup procedures designed to ensure recovery of critical data in case of system failure.

Backup practices include:

• Automated daily backups of production databases.
• Backup retention for 25 days.
• Storage in secure cloud storage within the infrastructure provider environment.
• Restricted access to backup systems through role-based permissions.

Backups are periodically tested to ensure recoverability.

25. Security Incident Handling During Disasters

If the disaster is related to a security incident or potential data breach, additional procedures are followed:

• Immediate investigation by the engineering team.
• Isolation of affected systems if required.
• Preservation of logs and forensic information.
• Coordination with customers if their data may be impacted.
• Notification procedures aligned with contractual obligations.

26. Customer Notification Procedures

If a disaster materially impacts customer services:

• Designated customer contacts will be notified.
• Status updates may be communicated through official communication channels.
• Updates will include:
  • Incident summary
  • Current mitigation actions
  • Estimated recovery timeline (if available)

Communication will be coordinated by the Event Manager.

27. Third-Party Vendor Dependencies

Monada.ai relies on certain third-party service providers to operate its platform.

Critical infrastructure vendors include:

• Amazon Web Services (AWS) – cloud infrastructure hosting
• Microsoft Azure OpenAI Service – AI processing
• Google Cloud Vertex AI – AI processing

Vendor outages are monitored and managed as part of the disaster recovery process.

28. Documentation and Evidence Retention

During a disaster event, the Disaster Recovery Team will document:

• Timeline of events
• Systems affected
• Recovery actions taken
• Root cause analysis

This documentation supports internal review and continuous improvement of the DRP.

29. Continuous Improvement

After each disaster event or DRP test:

• A post-incident review is conducted.
• Identified gaps are documented.
• Improvements are incorporated into future DRP revisions.

30. Security Incident Management

Monada maintains procedures for identifying, responding to, and resolving information security incidents that may affect platform operations or customer data.

Security incidents are handled by the engineering and management team responsible for platform operations and security oversight, which functions as the internal incident response team.

Incident Detection

Security incidents may be detected through:

• infrastructure monitoring and alerts
• application monitoring
• system log analysis
• internal reporting by employees
• reports from customers or partners

Incident Response

Once detected, incidents are evaluated to determine their scope and severity. The response process includes:

1. Incident identification
2. Containment and mitigation
3. Investigation and root cause analysis
4. Remediation and system recovery
5. Documentation and internal review

Incident Prioritization

Incidents are prioritized based on severity and potential impact on:

• system availability
• data confidentiality
• data integrity
• customer operations

Higher severity incidents receive immediate attention from the engineering team.

Customer Notification

If an incident may impact customer data or service availability, affected customers will be notified in accordance with contractual obligations and applicable regulatory requirements.

31. Alignment with Business Continuity Plan (BCP)

This DRP focuses on technical service restoration.

The broader Business Continuity Plan (BCP) addresses:

• Workforce availability
• Operational continuity
• Communication procedures
• Business operations during extended disruptions

Both plans operate together to ensure full organizational resilience.

Appendix A: Emergency Contacts

Event Manager
Shahar Weinberg - CEO

Disaster Recovery Lead
Adi Ben Mayor - CPO

Engineering On-Call
Available via internal incident response channels.

‍

‍