Backup and disaster recovery policy

1. Introduction

This Backup and Recovery Policy establishes corporate guidelines for the protection, availability, integrity and confidentiality of information in the scope of the SaaS service of the Quiker Innovation Management Platform. Its objective is to minimize risks of data loss, reduce operational impacts resulting from failures, security incidents or disasters, and ensure the continuity of services provided to customers.

The policy is independent of specific vendors, technologies or platforms, and must be applied to all components that support the Quiker Platform SaaS service, including cloud, on-premises or hybrid environments, when applicable.

2. Objectives

The objectives of this policy are:

Establish standardized and regular backup processes for databases, applications and storage.
Define the RTO (Recovery Time Objective) and RPO (Recovery Point Objective) parameters for the different types of information assets.
Ensure the existence of Disaster Recovery (DR) mechanisms that ensure the continuity of operations in severe failure or disaster scenarios.
Define guidelines for data and service recovery, including automatic and manual restoration.
Ensure compliance with good information security practices, governance and applicable regulatory requirements.

3. Scope

This policy applies exclusively to the Quiker Innovation Management Platform SaaS service and all information assets necessary for its operation, including, but not limited to:

Databases used by the platform;
Applications, services, APIs and microservices that make up the SaaS solution;
Service support infrastructure, including production and contingency environments;
Storages, data volumes, objects and files associated with the platform’s operation;
Production environments and, when applicable, approval environments that support the service.

Assets that are not part of the scope of the Quiker Platform SaaS service are not covered by this policy.

4. Classification of Assets

For backup and recovery purposes, assets are classified into:

Databases: systems responsible for the structured storage of critical business data.
Applications and Services: systems that support the company’s operational and strategic processes.
Storages and Files: repositories of files, objects, media and unstructured data.

Backup and recovery parameters must be defined according to the criticality of each asset.

5. Backup Frequency

5.1 Databases

Complete backups must be performed at least daily.
Incremental or differential backups can be used depending on the criticality and volume of data.
For critical databases, continuous backup or point-in-time recovery mechanisms must be adopted, when supported.

5.2 Applications and Services

Backups of configurations, artifacts, images, codes and dependencies must be performed at least daily.
Whenever possible, versioning and infrastructure as code should be adopted as additional layers of recovery.

5.3 Storages and Files

Backups must be carried out according to the criticality of the data, respecting at least a daily periodicity.
Critical or regulatory data may require increased frequency and extended retention.

6. RTO and RPO

Recovery objectives must be defined according to the criticality of the asset, as follows:

6.1 Databases

RTO: up to 4 hours for highly critical databases.
RPO: up to 24 hours, which can be reduced according to business needs.
Minimum backup retention: 7 days, which can be extended according to legal or contractual requirements.

6.2 Applications and Services

RTO: up to 4 hours for critical applications.
RPO: up to 24 hours.
Minimum retention: according to criticality and operational dependence.

6.3 Storages and Files

RTO: up to 8 hours, except for exceptions defined by the business.
RPO: up to 24 hours.
Minimum retention: defined according to the type of data, which can vary from days to months.

7. Backup Retention

Backups must be stored securely and segregated from the production environment.
Retention policies must consider legal, regulatory, contractual and operational requirements.
Long-term backups must be protected against accidental deletion, corruption and unauthorized access.

8. Disaster Recovery

The Disaster Recovery (DR) strategy must include:

Replication of data and services to a secondary environment or region, preferably asynchronously or synchronously depending on criticality.
Clear definition of contingency environment activation procedures.
Updated documentation of DR plans.
Periodic tests to validate recovery times and data integrity.
The maximum acceptable replication delay must be aligned with the RPOs defined for each asset.

9. Data Recovery and Services

In the event of an incident, failure or loss of data, the following methods must be used, as applicable:

Restoration from full, incremental or differential backups;
point‑in‑time recovery, when available;
Activation of secondary environments or replicas;
Restoration of configurations and applications from versioned repositories.
Recovery can be automatic or manual, depending on the type of incident and the architecture adopted.

10. Backup and Recovery Testing

Restoration tests must be carried out periodically, at least once a semester.
Tests must validate data integrity, recovery time and adherence to defined RTOs and RPOs.
Test results must be documented and any errors corrected.

11. Backup Security

All backups must be protected by appropriate access controls.
Whenever possible, data should be encrypted at rest and in transit.
Access to backups must be restricted to authorized people and systems.

12. Responsibilities

12.1 Information Technology Team

Implement and maintain backup and recovery processes;
Monitor the execution of backups and resolve failures;
Ensure the security, integrity and availability of backups;
Carry out periodic restoration and DR tests;
Carry out recovery procedures in the event of an incident.

12.2 Users and Business Areas

Use systems in accordance with corporate policies;
Promptly communicate any incident, failure or unavailability to the IT team;
Participate in the definition of criticality, RTO and RPO when requested.

13. Policy Review

This policy must be reviewed periodically, at least once a year, or whenever significant changes occur in infrastructure, business processes or legal and regulatory requirements.