The Invisible Technologies Disaster Recovery Plan establishes procedures to recover Invisible Technologies operations following a disruption resulting from a disaster. The types of disasters contemplated by this plan include natural disasters, political disturbances, man made disasters, external human threats, and internal malicious activities. This Disaster Recovery Plan is maintained by the Security team. Disaster Recovery Policies • Invisible Technologies performs testing of the Disaster Recovery Plan annually. The Security team is responsible for coordinating and conducting rehearsals of this Disaster Recovery Plan annually. • Whenever the DRP is used, it must be followed by a retrospective and tabletop reenactment in order to identify lessons learned and playbooks needing creation. • This policy and plan must be updated at least annually with additional playbooks taking into account new risks of disasters learned through testing and reenactment of past disaster incidents. Scope of Disaster Recovery Plan This policy includes all resources and processes necessary for service and data recovery, and covers all information security aspects of business continuity management. The following conditions must be met for this plan to be viable:

1. All equipment, software and data (or their backups/failovers) are available in some manner.
2. If an incident takes place at the organization’s physical location, all resources involved in recovery efforts are able to be transferred to an alternate work site (such as their home office) to complete their duties. This plan does not cover the following types of incidents:
3. Incidents that affect customers or partners but have no effect on Invisible Technologies’ systems. In this case, the customer must employ their own continuity processes to make sure that they can continue to interact with Invisible Technologies’ systems.
4. Incidents that affect cloud infrastructure suppliers at the core infrastructure level, including but not limited to Google, Slack, and Amazon Web Services. The organization depends on such suppliers to employ their own continuity processes. Notification List In the event of a disaster, notify these people in order: • Scott Downes Disaster Recovery Objectives The objectives of this plan are the following: • Identify the activities, resources, and procedures needed to carry out Invisible Technologies’ processing requirements during prolonged interruptions to normal operations.

• Identify and define the impact of interruptions to Invisible Technologies’ systems. • Assign responsibilities to designated personnel and provide guidance for recovering Invisible Technologies operations during prolonged periods of interruption to normal operations. • Ensure coordination with other Invisible Technologies 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. Please see Invisible Technologies’ critical contacts on Invisible Technologies’ Business Continuity Plan. Defining Critical Systems and Services From a disaster recovery perspective, Invisible Technologies defines two categories of systems: Non-Critical Systems. These are all systems not considered critical by the definition below. 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. Non-Critical Systems are restored at a lower priority than Critical Systems. Examples of Non-Critical Systems include analytics servers. Critical Systems. These systems host application servers and database servers or are required for the functioning of systems that host application servers and database servers. 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. The following services and technologies are considered to be critical for Invisible Technologies business operations, and must immediately be restored (in priority order):

1. Production infrastructure
2. Transit infrastructure
3. Build and deployment infrastructure General Disaster Recovery Plan While specific playbooks are available for specific scenarios, there are overall rules of engagement whenever a disaster incident needs to be opened. Notification Phase This phase addresses the initial actions taken to detect and assess damage inflicted by a disruption to Invisible Technologies. The notification sequence is listed below:
4. The first person to report the disaster should notify Scott Downes.
5. Scott Downes is to notify team members referenced above in the Notification List section.
6. Based on the damage assessment, if Invisible Technologies will be unavailable to customers for more than 24 hours Scott Downes will declare that a disaster has occurred and that the Disaster Recovery Procedure has been activated. Scott Downes also has the discretion to activate the Disaster Recovery Procedure based on other criteria.
7. In the event customer data has been compromised, customers must be notified no later than 72 hours

after the incident is reported. 5. Once the Disaster Recovery Procedure has been activated, Scott Downes should notify relevant personnel and executive leadership on the general status of the incident. Notification can be conducted over chat, email or phone. Scott Downes may also notify the Invisible Technologies operations team if the disaster involves the Invisible Technologies premises or is related to Invisible Technologies employees. 6. If the Disaster Recovery Procedure has not been activated, the Recovery and Reconstitution phases will not be performed. Instead, Scott Downes and necessary team members will perform all appropriate tasks under Invisible Technologies’ Incident Response Plan. 7. Either Scott Downes or someone they select will document who was contacted and when, and will summarize each call. Recovery Phase This phase covers the recovery of the application at an alternate site. If the disaster involves both Critical Systems and Non-Critical Systems, the Invisible Technologies Security team may prioritize the recovery of Critical Systems and proceed to the Reconstitution Phase for the Critical Systems before Non-Critical Systems have completed the Recovery Phase. This phase consists of the following tasks, some of which can be run in parallel:

1. Assess damage to affected environments, prioritizing critical systems first. Document observations.
2. If possible, back up the affected environments in a forensically sound manner. Do not alter affected systems and applications in any manner.
3. Verify that previous backups of critical databases and systems recovery points are available before moving on to the Reconstitution Phase. Reconstitution Phase This phase consists of activities necessary for restoring Invisible Technologies operations to the original operating state (or permanently move operations to the new site or state, if necessary). If the disaster involves both Critical Systems and Non-Critical Systems, the Invisible Technologies Security team may prioritize reconstituting the Critical Systems before beginning reconstitution of the Non-Critical Systems. This phase consists of the following tasks, some of which can be run in parallel:
4. Begin replication of the new environment using previously confirmed backups using automated and previously tested scripts.
5. Invisible Technologies utilizes multiple availability zones; however, if the primary region is unavailable replicated backups should be used to create a production environment in the failover region.
6. Test the new environment using pre-written tests.