Business and Work Continuity Plan

This plan sets out how PRONETSYS S.A.S. (Pronetsys) prepares for, responds to and recovers from events that may disrupt the services it provides to its clients or its team's work. Its priorities are, in this order, to protect people, to preserve client information and to restore critical services within acceptable timeframes.

The plan is aligned with the principles of the ISO 22301:2019 standard (with its Amendment 1:2024) and with the ISO 22313:2020 guidance, without this implying certification. The recovery times indicated here are design objectives that the company validates through testing and adjusts according to the commitments of each contract.

1. Objectives

• Protect the life and physical integrity of employees, clients and visitors during any emergency.
• Maintain or restore critical services within the recovery time objectives (RTO) and with data loss no greater than the recovery point objectives (RPO) defined in the impact analysis.
• Protect the confidentiality, integrity and availability of client information, especially sensitive data, including during the contingency.
• Communicate in a timely, truthful and coordinated manner with clients, employees, suppliers and authorities.
• Ensure the continuity of the team's work, even in the event of power or connectivity failures at an employee's remote workplace or with key personnel absent.
• Learn from each incident, test or exercise to improve response capability.

2. Scope

The plan covers the technical support and service desk services, hosting and domains, hosted email, cloud backup (on the company's own infrastructure and managed on client platforms), virtual VoIP telephony, AI chatbots, digital signage, streaming, development and consulting projects, and the internal processes that support them. It includes the team's remote work (the company has no physical office and serves its clients through virtual channels), technical visits in the Aburrá Valley (Medellín metropolitan area) and the company's own infrastructure, hosted in data centers and with cloud providers, or contracted from cloud, data center, connectivity and telephone trunk providers.

3. Reference framework and definitions

The plan forms part of the risk and compliance management process described in the Process Map and is coordinated with the Information Security Policy and with the Occupational Health and Safety Policy, which governs emergency preparedness and response affecting people.

Business impact analysis (BIA)

Assessment of how the disruption of each service or process has an impact over time, in order to define priorities and recovery times.

RTO (recovery time objective)

Maximum desired time between the disruption of a service and its restoration to an acceptable level.

RPO (recovery point objective)

Maximum amount of data, expressed in time, that it is acceptable to lose; for example, an RPO of 24 hours means restoring, at most, from the previous day's backup.

Incident, contingency and crisis

Increasing levels of severity of an event, which determine who leads the response; their criteria are defined in section 8.

Alternate site or route

Infrastructure, provider, connection or workplace other than the usual one, prepared to take over operations.

4. Roles and responsibilities

Roles are assigned by name in an internal register, each with its respective alternate. In a small team, one person may hold more than one role, but the Continuity Committee must always have at least two people available with decision-making authority.

5. Business impact analysis (BIA)

The BIA is prepared and updated following these steps: identify the services and processes; estimate the impact of their disruption at 4, 8, 24 and 72 hours (operational, contractual, legal, reputational and financial impact, and impact on clients' operations, including patient care in the case of healthcare providers (IPS)); establish priorities, RTO and RPO; and identify dependencies on people, technology, information and suppliers. The result is validated by General Management.

Priority 1: critical, recovered first. Priority 2: high. Priority 3: medium, recovered once the higher-priority services have been stabilized.

6. Backup strategy: the 3-2-1 + 1 rule

Recovery capability depends on having backups that are intact, recent and beyond an attacker's reach. For this reason, the critical information of Pronetsys and of the services it provides to its clients is backed up under the 3-2-1 rule, reinforced with an immutable or offline copy:

• Backups are encrypted in transit and at rest, and the encryption keys are kept in the password manager with controlled emergency access.
• Backup systems use credentials separate from those of production, with multi-factor authentication, so that the compromise of a server does not allow its backups to be deleted.
• Daily execution, verification and periodic restoration tests follow the backup management procedure in the Process Map. A backup is considered valid only if it has been verified and its restoration has been tested.
• For backups managed on the client's platform, Pronetsys recommends applying this same rule. If the client decides not to do so, the decision and the associated risk are documented.

7. Risk scenarios and strategies

The following scenarios are the most relevant to operations. For each one, preparedness measures and a response strategy are defined; the strategy is executed using the procedures in section 8.

7.1 Power outage

Preparedness: an uninterruptible power supply (UPS) or backup battery for the work equipment and router of the person on shift, with enough runtime to close or hand over the cases in progress; client services hosted in data centers or clouds with their own backup power (a supplier selection criterion); laptops with batteries in good condition, charged at the end of the workday.

Response: verify that the services hosted in data centers and clouds are still operating; if the outage at an employee's workplace is prolonged, reassign their cases to another employee who has power or continue from another location with power; check the equipment once power is restored.

7.2 Internet outage

Preparedness: backup connectivity for each employee (mobile data plan or a second home internet provider); a mobile data plan for technicians; client services hosted in data centers and clouds, so that a connectivity failure at an employee's workplace does not affect them.

Response: switch to the alternate connection; if this is not sufficient, reassign the cases to another employee who has connectivity or continue from another location with a secure connection; keep receiving cases through the available channels; report the failure to the provider and record the times.

7.3 Ransomware attack

Preparedness: multi-factor authentication, patching within the deadlines set in the Information Security Policy, endpoint protection with malicious behavior detection, least privilege, network segmentation, email filtering, team awareness and immutable or offline backups.

Response: immediately isolate the affected devices and servers from the network; revoke sessions and change potentially compromised credentials; preserve evidence; determine the scope and whether personal data is involved; restore from verified clean backups, predating the compromise, onto rebuilt and updated systems. The recovery strategy is based on backups and not on paying ransoms; any exceptional decision rests with General Management, with legal advice. The notifications to clients and authorities provided for in the Information Security Policy are made.

7.4 Server or cloud provider failure

Preparedness: availability monitoring; disk redundancy and snapshots; backups replicated with another provider or in another region; documentation and scripts to rebuild servers (hosting control panels, PHP, databases, email) on alternate infrastructure; DNS records with time-to-live (TTL) values that allow quick changes; contracts with providers that define their availability and support.

Response: confirm the failure with the provider and estimate its duration; if the RTO is expected to be exceeded, restore the services on the alternate infrastructure in the BIA priority order, update the DNS records and validate with clients; return to the primary infrastructure in a planned manner once it has been restored.

7.5 Unavailability of key personnel

Preparedness: a matrix of alternates by role (section 9.5), cross-training, up-to-date technical documentation by client and service, and emergency access to critical credentials, so that no single person is the only one who knows an access or a procedure.

Response: activate the alternate; redistribute tickets, prioritizing P1 and P2 cases; inform clients of possible adjustments to non-critical times; if the absence is prolonged, reinforce the team with external staff or partners under confidentiality agreements.

7.6 Loss or theft of equipment

Preparedness: full-disk encryption, automatic screen lock, multi-factor authentication, remote lock and wipe capability, work information synchronized to corporate repositories (not only stored on the device) and an up-to-date inventory.

Response: the employee reports the loss to the Information Security Lead immediately, on the same day; the device is locked or wiped remotely, sessions are closed and the credentials stored on or used with it are rotated; an assessment is made of whether personal data was exposed in order to decide on notifications; a backup device is provided and, in case of theft, a police report is filed.

7.7 Earthquake or other natural disaster in Medellín

The Aburrá Valley is exposed to earthquakes and, during rainy seasons, to floods and landslides that may affect employees' homes and workplaces, mobility and clients' infrastructure.

Preparedness: an emergency plan and brigade under the Occupational Health and Safety Policy, with guidance for each employee on the hazards at their remote workplace; a recommendation to secure racks and equipment in the managed client infrastructure; backups and alternate services in geographic locations outside the Aburrá Valley; a contact list accessible offline.

Response: first, the safety of people: evacuation, verification of each employee's status and support for those who need it (emergency line 123). Then, damage assessment, redistribution of work among the unaffected employees and recovery of services from the alternate infrastructure. Damaged facilities are not entered until they have been inspected by competent personnel.

7.8 Pandemic or mobility restrictions

Preparedness: the entire team works remotely with corporate equipment, VPN access with multi-factor authentication and remote support tools; processes are operated without physical presence, except for technical visits.

Response: maintain remote work under the arrangement agreed with each employee in accordance with current labor legislation (remote work, telework or work from home); prioritize remote support; limit on-site visits to cases that cannot be resolved remotely, following the biosafety protocols established by the authorities; monitor the team's workload and health.

7.9 VoIP trunk provider failure

Preparedness: backup of the virtual PBX configuration (trunks, extensions, menus, recordings); overflow routing or a secondary trunk with another provider when the client contracts it; a documented procedure for forwarding calls to mobile numbers; the provider's escalation contacts.

Response: confirm the failure and open a case with the provider; activate the secondary trunk or the call forwarding agreed with each client; inform the affected clients and follow up with them; restore the normal configuration and verify incoming and outgoing calls once the failure has been resolved.

8. Response procedures

The response is escalated according to the severity of the event:

8.1 Detection and activation

1. Detection. The event may be detected through monitoring or through a report from a client, an employee or a supplier.
2. Immediate reporting. Whoever detects the event informs the Technical Lead or the Service Desk Coordinator without delay, through the primary channel or, if it is not working, through the alternate channel.
3. Logging. A ticket and a log are opened, recording the time of detection, the symptoms and the initial actions. The log is maintained throughout the event.
4. Initial classification. The level (incident, contingency or crisis) is assigned according to the table above. When in doubt, the event is classified at the higher level.
5. Activation. The Continuity Lead activates the plan at level 2; General Management does so at level 3. The activation is communicated to the team through the communication tree.
6. Convening the response team. The team meets in the predefined virtual room (or by conference call bridge if there is no internet), and the roles are confirmed: leadership, technical recovery, communications, security and logging.

8.2 Assessment

1. Safety of people. It is confirmed that no one is at risk; if anyone is, the emergency plan prevails.
2. Scope. The affected services, clients, systems and information are determined, based on the BIA and the service inventory.
3. Nature of the event. The Information Security Lead determines whether it is a security incident; if so, evidence is preserved before making changes that could destroy it.
4. Estimate. The restoration time via the normal route is estimated and compared with the target RTO.
5. Strategy decision. A decision is made on whether to recover on the usual or the alternate infrastructure, and in what order, according to the BIA priorities. The decision and its rationale are recorded in the log.

8.3 Communication with clients

1. Identification of affected parties. Using the service inventory, a list of the affected clients and their authorized contacts is prepared, starting with priority 1 services.
2. First notice. An initial notice is sent as soon as possible, with the goal of doing so within the first hour after activation at level 2 or 3. It states what is happening, which services are affected, what the client can do in the meantime and when they will receive the next update.
3. Periodic updates. Progress is reported at the announced intervals, even if there is no news, to avoid uncertainty. Messages are truthful, without speculation about unconfirmed causes, and are approved by the Continuity Lead or General Management.
4. Alternate channels. If email or the support portal are affected, the alternate channels in section 10 are used (phone, messaging, notice on the website).
5. Personal data. If the event compromises personal data, the notification rules of the Information Security Policy apply: notice to the client acting as data controller and a report to the Superintendence of Industry and Commerce within the required terms.
6. Restoration notice. Each client is notified that the service has been restored and is asked to confirm that their operations are back to normal.
7. Post-incident report. For level 2 or 3 events, the affected clients receive a report with the timeline, the cause, the impact and the measures to prevent recurrence.

8.4 Recovery

1. Containment. If there is a security incident, it is contained before restoring, so as not to reinfect the recovered systems.
2. Strategy execution. The Technical Recovery Lead executes the service's documented procedures (runbooks): failover to alternate routes, server rebuilding or restoration from backups.
3. Backup verification. Before restoring, it is confirmed that the chosen backup is intact and predates any compromise.
4. Restoration by priority. Services are recovered in the BIA order; each relevant configuration change is recorded in the log.
5. Validation. Critical functions are tested and clients are asked to confirm that everything is working.
6. Enhanced monitoring. Recovered services are monitored more frequently during the following hours or days.
7. Time recording. The actual recovery time and the actual data loss are recorded, in order to compare them with the target RTO and RPO.

8.5 Return to normal operations

1. Closure criteria. The Committee confirms that services are stable, that there are no active threats and that clients have validated their operations.
2. Planned return. The return from the alternate infrastructure or site to normal operations is carried out as a planned change, with a prior backup and data synchronization.
3. Removal of temporary solutions. Redirections, temporary access and provisional configurations are removed, and the credentials used during the emergency are rotated.
4. Plan deactivation. The Continuity Lead (or General Management at level 3) declares the end of the contingency and communicates it to everyone involved.
5. Documentation closure. The log is completed and the lessons learned session is scheduled (section 13).

9. Work continuity

Business continuity depends on the team being able to keep working safely and healthily even if power or connectivity fails at an employee's workplace, a key person is absent or a device fails.

9.1 Remote work

• All roles work remotely with corporate equipment; only on-site technical visits require physical presence.
• Remote work requires a secure connection, a VPN or equivalent access with multi-factor authentication for administrative systems, and avoiding unprotected public networks.
• Conversations with clients and the handling of confidential information take place in spaces that preserve privacy.
• Ergonomic conditions, working hours and disconnection from work are governed by the Wellbeing and Workload Policy and the OHS Policy, in harmony with Law 2191 of 2022 on disconnection from work.

9.2 Backup equipment

• At least one preconfigured, encrypted and updated backup laptop is kept, ready to be delivered the same day in the event of damage, loss or theft.
• Each employee has an alternate means of connectivity (mobile data plan or a second home internet provider); the person on shift has a UPS or backup battery for their work equipment; and technicians have portable diagnostic tools.
• When a contract so provides, critical spare parts or loaner equipment are kept for the client's infrastructure.

9.3 VPN access and administration routes

• Access to networks and administration consoles is through a VPN or equivalent mechanisms with multi-factor authentication and named accounts.
• VPN capacity is sized so that the entire team can work remotely at the same time.
• There is a documented, restricted alternate access route to the critical servers for cases in which the primary VPN fails.
• Access is revoked immediately upon an employee's departure, according to the access provisioning and deprovisioning procedure in the Process Map.

9.4 Documentation and shared knowledge

• Each service and each managed client has up-to-date technical documentation: diagrams, inventory, configurations, supplier contacts and recovery procedures (runbooks).
• Documentation is stored in corporate repositories that are accessible remotely and backed up according to the 3-2-1 + 1 rule, never only on one person's device.
• Incident solutions are recorded in the service desk knowledge base.
• A copy of this plan and of the emergency contact list is kept available offline, in protected form, by the members of the Committee.

9.5 Alternates by role

9.6 Password manager and credential segregation

• All corporate and client credentials are kept in a corporate password manager, organized into separate vaults by client and by criticality level.
• Each person accesses only the vaults that their role requires; access to the critical vaults (domain registrars, cloud, hosting control panels, backup systems, PBX) is limited to technical roles and their alternates.
• No critical credential depends on a single person. There is an emergency access mechanism under dual control, the use of which generates an alert and requires the affected credentials to be rotated at the end of the contingency.
• The multi-factor authentication recovery codes for critical accounts and the recovery mechanism of the password manager itself are kept securely, separate from everyday devices.

9.7 Caring for the team during the contingency

Prolonged contingencies are managed in shifts, with explicit breaks and handovers, to avoid sustained workdays that affect health and the quality of decisions. The Human Resources and OHS Lead monitors the workload during and after the event.

10. Communication tree

The communication flow during a contingency is as follows. The contact list with names, phone numbers and alternates is kept in an internal register and verified quarterly.

• Whoever detects the event (employee, client, monitoring or supplier) informs:
  • Service Desk Coordinator or Technical Lead (first response), who informs:
    • Continuity Lead (evaluates and activates the plan), who informs General Management and convenes the Continuity Committee. From there:
      • Technical Recovery Lead: technical team and suppliers (cloud, data centers, connectivity, trunks, manufacturers).
      • Communications Lead: affected clients (by service priority), employees and other suppliers.
      • Information Security Lead: clients that are data controllers of the affected personal data, the Superintendence of Industry and Commerce and judicial authorities, when appropriate.
      • Human Resources and OHS Lead: verification of people's status and emergency services (line 123).

Pre-approved templates are kept for the initial notice, the updates, the restoration notice and the post-incident report, so that messages can be sent quickly and with consistent information.

11. Testing and exercises

A plan that is not tested is not reliable. The following schedule is a minimum proposal that the Continuity Committee validates at the beginning of each year, according to available resources and contractual commitments.

Each test leaves a record of its scope, participants, results, measured times and improvement opportunities. Tests that may affect client services are coordinated with the clients and carried out as planned changes.

12. Plan maintenance

• The Continuity Lead is responsible for keeping the plan up to date and for its version control.
• The plan is reviewed at least once a year and, in addition, after each actual activation, after tests with unsatisfactory results, after changes in services, critical suppliers or key personnel, and after relevant legal or contractual changes.
• Updates are approved by the Continuity Committee and communicated to the team; new employees become familiar with the plan during their onboarding.
• The current version is published on this site, and a copy accessible offline is kept for the members of the Committee.

13. Lessons learned

Each activation of the plan and each exercise is an opportunity for improvement. The review is carried out with a blameless approach, focused on facts and causes.

1. Review session. The team that participated meets with the Continuity Lead, with the goal of doing so within five business days after closure, while the facts are fresh.
2. Timeline. The sequence of events is reconstructed based on the log, the tickets and the technical records.
3. Analysis. The team identifies what worked, what did not and why, and what the root causes were; actual times are compared with the target RTO and RPO.
4. Actions. Specific actions are defined, each with an owner and a date, and are managed in the continuous improvement process of the Process Map.
5. Update. This plan, the recovery procedures, the knowledge base and, if necessary, the BIA are updated.
6. Dissemination. Lessons are shared with the team and, when appropriate, with the affected clients through the post-incident report.