1. Introduction and scope
This Backup and Data Retention Policy explains how Tadeed backs up and retains data processed through Tadeed eInvoicing. It applies to the Service in every environment where the same application build is operated, including local, development, staging, and production.
This Policy is published from one central record. It is not copied into each tenant database. Every tenant sees the same published version.
This Policy describes the backup and retention behaviour that the application implements. It is not a service-level agreement, and it does not promise a recovery time, a recovery point, or a backup frequency beyond the schedule that is actually installed for that environment.
2. Data covered by backups
Operational backup tooling can include:
- the master database, which holds tenant registration, subscription, and this legal-policy record;
- each tenant database, which holds that tenant's accounting, invoicing, and related business records;
- uploaded files stored on the application server, when a file backup runs;
- a recovery point that ties a completed tenant database dump to its file archive.
When file storage uses object storage, the tenant recovery point downloads that tenant's objects under the tenants/<company> prefix and stores them in the recovery-point file archive. Restore writes those objects back to the same prefix. Redis, where used, mainly holds cache, rate-limit, queue, and session state and is not treated as the system of record for invoices or accounting entries.
A backup copy is a disaster-recovery artefact. It is separate from the live record the tenant uses in the Service.
3. Backup frequency and retention
Recovery points are created by the daily backup job. That job runs inside one API instance when BACKUP_SCHEDULE_ENABLED is true, or from the server schedule installed by npm run backup:cron:install. Use only one of those on an environment. The job is off until one of them is turned on, so this Policy does not claim that a schedule is already active.
Tenant recovery points are kept according to the active retention settings. Super Admin can change those settings, and environment variables can set them, only inside the limits built into the application:
- daily recovery points: 1 to 30 days (30 when BACKUP_RETENTION_DAILY_DAYS is unset; the environment template sets 7);
- weekly recovery points: 0 to 12 weeks (12 when BACKUP_RETENTION_WEEKLY_WEEKS is unset; the environment template sets 4);
- manual recovery points: up to 20 per tenant (template and code fallback 7);
- pre-restore safety copies: 1 to 30 days (14 when unset; the environment template sets 7);
- a maximum number of recovery points per tenant, capped at 40 (40 when unset; the environment template sets 14).
An environment may be configured below these defaults. Cleanup removes older recovery points that fall outside the active policy. Master database dump files follow a shorter cleanup cycle implemented in the backup cleanup job: one dump per day for 7 days, and up to four dumps within 28 days.
4. Accounting and ZATCA record retention
Invoices, credit notes, debit notes, accounting entries, and ZATCA submission records remain in the tenant's live database while the subscription is active. Backup retention in section 3 does not replace that live record and is not the customer's statutory archive.
After account closure, the application retains the closed tenant's records for a closure retention period. The application default, and the minimum used by the closure process, is 2,190 days (six years), unless the tenant's plan sets a longer archive retention. Operators may set the closure retention with environment configuration, but not below that minimum.
Customers remain responsible for keeping the accounting and tax records required by ZATCA and other applicable law, including their own exports.
5. Data security
Backup files are written under the configured backup directory with restricted file permissions. Database dumps are compressed. Encryption of backup files is applied when backup encryption is configured. When backup storage is set to object storage, uploads use server-side encryption configured for that bucket.
Backup status and recovery-point details exposed to a tenant are limited to that tenant. Super Admin backup operations require master-admin authentication and backup permissions. This Policy does not claim a named certification such as ISO or SOC.
6. Restoration procedures
Restoration is an operations action. Super Admin can run a restore or a restore rehearsal through the backup tools. A tenant can view the tenant's own backup status and recovery-point metadata. Tenants cannot restore another tenant's database or files.
A restore uses a completed recovery point that belongs to the selected tenant database. It is not immediate, and it can succeed only when that recovery point and its files are still within the retention in section 3. Local files are restored to that tenant's upload folder. Object-storage files are restored to that tenant's object prefix. The application can take a pre-restore safety copy before a restore.
7. Tenant responsibilities
- Keep user access limited to people who are authorised to view or change the tenant's data.
- Export and store statutory invoices, accounting records, and ZATCA evidence independently of Tadeed's backup copies.
- Review backup status available in the tenant application and contact Tadeed if a recovery point is required.
- Do not treat a backup copy as the official book of record.
8. Subscription termination
Ending a subscription does not by itself delete the tenant database. Closed accounts follow the closure retention period in section 4. During that period the records are retained and are not available as an active subscription.
The customer should export required records before or during closure. Termination does not remove the customer's own legal duty to retain tax and accounting records.
9. Data deletion
After the closure retention period, the application can purge the closed tenant's retained data. Dropping the tenant database during purge happens only when that operation is explicitly enabled for the environment. Backup copies that are still inside the active backup retention remain until the cleanup job removes them. Deletion from the live database therefore does not instantly erase every backup copy.
This Policy does not authorise deletion of another tenant's invoices, accounting entries, or uploaded files.
10. Policy updates
Tadeed publishes changes by creating a new version of this Policy in the central legal-policy record. Only a published version is shown on the website, on the registration page, and in the tenant application. Draft edits stay unpublished.
The version and effective date on this page are the published values. Existing acceptance records are kept. A later version is recorded as a new acceptance only through the existing legal-acceptance process, and login is not blocked unless that published version requires re-acceptance.
11. Contact information
Questions about this Policy or a request to restore a recovery point:
Tadeed Strategic Services Company
Commercial Registration No.: 7051732423
VAT Registration No.: 314244812800003
7447 9th Street, Al Amamrah District
Dammam 32415, Eastern Province
Kingdom of Saudi Arabia
Email: info@tadeed.com