Skip to content
EN
Contact us
♻️ Business continuity & disaster recovery

Business continuity and disaster recovery plan.

TranscribIA processes recordings that may affect public service continuity: council minutes, public sessions and working groups. This page describes, without overstating claims, the verifiable technical measures that safeguard platform availability and recovery of your data after an incident. It is intended for IT directors, security officers and leadership teams who need to include their transcription tool in a formal business continuity plan.

Version v1.0 — Last updated: . Publisher: AMBASSADIA SARL.

Quantified targets

Measurable continuity targets

Two indicators frame our continuity commitment. They are derived from the backup system's actual configuration and times observed during restoration exercises, rather than theoretical estimates.

RPO — Recovery Point Objective

24 h

Maximum acceptable data loss

  • Calculation: determined by the daily backup frequency. In the worst case, data created in the 24 hours before the incident may need to be resubmitted.
  • Aligned with the full backup cycle (PostgreSQL database + audio objects + configuration).

RTO — Recovery Time Objective

4 h

Target maximum downtime

  • Calculation: the sum of times observed during exercises: decryption, transfer from off-site storage, schema restoration and integrity verification.
  • Reduced by granular per-organisation restoration (a single tenant, without restoring the entire database).

Backup strategy

Daily, encrypted, off-site backups

Every night, a full encrypted platform backup is pushed to object storage independent of the primary infrastructure. Encryption takes place on the publisher's side before any transfer, using keys the storage provider never holds.

🔑

End-to-end encryption

  • Application-level encryption with age (X25519 + ChaCha20-Poly1305)
  • Keys held by the publisher — the storage provider cannot read the data
  • Transfer through rclone over an encrypted channel (TLS)
  • Compatible with security teams' cryptographic requirements
🇪🇺

Location & frequency

  • Frequency: automated daily full backup
  • EU object storage (Backblaze B2 or Scaleway), European jurisdiction
  • No backup data transferred outside the EU
  • Geographical and logical independence from the primary site

Retention policy

90 days

Retention of full platform backups. Allows recovery to a point within three calendar months.

30 days

Retention of per organisation, independently restorable.

Restoration

Granular, secure and tested bit for bit

Restoration is designed to avoid putting other organisations at risk and to be reproducible. Every mechanism described here is exercised regularly, rather than merely planned on paper.

🎯

Granular by organisation

The PostgreSQL schema-per-org architecture (one isolated schema per organisation) allows a single tenant to be restored without affecting the others. An incident affecting one organisation does not bring the entire platform to a halt.

🛡️

Overwrite-protection snapshot

Before any restoration, an automatic snapshot of the current state is taken. This safety net prevents a restore from accidentally overwriting valid data — the operation remains reversible.

✅

Bit-for-bit validated DR drill

Procedures are implemented in two version-controlled scripts — backup-offsite.sh and restore-from-offsite.sh — and execution is verified by bit-for-bit comparison between source and target during exercises.

Incident management

Detect, contain, communicate

Continuity extends beyond major disasters. The platform includes continuous monitoring and automatic recovery mechanisms for common incidents, together with a communication policy for confirmed incidents.

Detection & automatic recovery

  • 24/7 monitoring. Queues, disk space, certificates, dependencies and worker health are continuously monitored.
  • 5-minute watchdog. Automatic recovery of stuck transcription jobs: no manual intervention for common incidents.
  • Alerts. Immediate Slack/email notifications and a daily digest for the operations team.

Degraded mode & communication

  • Degraded mode. If a transcription engine becomes unavailable, switching to a fallback engine preserves service.
  • Incident communication. Documented three-stage process: early warning, detailed notification, final report with causes and corrective measures.
  • Transparency. Customer organisations are informed of the actual impact and affected scope, in line with their notification obligations.

Major disaster

Disaster recovery: steps and target times

If the primary site is lost, the recovery procedure follows an ordered sequence, each step covered by a version-controlled script and target time, to meet the 4-hour RTO target.

  1. Detection & assessment

    T+15 min

    Confirmation of unavailability and its extent through 24/7 monitoring; recovery procedure initiated.

  2. Switch to off-site storage

    T+30 min

    Retrieval of encrypted backups from Backblaze B2 / Scaleway (EU) through restore-from-offsite.sh.

  3. Decryption & integrity check

    T+60 min

    Decryption using the publisher's keys (age / X25519) and verification of archive integrity.

  4. Granular restoration

    T+2 h

    Restoration of PostgreSQL schemas by organisation, following an overwrite-protection safety snapshot.

  5. Service restoration & verification

    T+4 h (target RTO)

    Service restart, bit-for-bit verification, controlled reopening to users and end-of-incident communication.

Target times are derived from disaster recovery exercises (DR drills). They are reassessed after each test and take account of the actual volume of restored data.

Two deployment modes

Allocation of responsibilities

The scope of this plan varies by deployment mode. In sovereign SaaS, the publisher operates and documents all controls. On-premise, operational responsibility shifts to your organisation — the product and backup scripts remain identical.

☁️

Sovereign SaaS (France)

The publisher is responsible for the entire continuity chain.

  • Backups, encryption, off-site storage and retention operated by AMBASSADIA SARL
  • 24/7 monitoring, watchdog and restoration handled by the publisher
  • DR drills executed and recorded by the publisher; results available for audit
  • Incident communication managed by the publisher
🏢

On-premise (your infrastructure)

The customer organisation handles operations; scripts are supplied.

  • backup-offsite.sh / restore-from-offsite.sh scripts supplied with the product
  • Off-site storage target, frequency and retention defined by your security officer
  • Monitoring, watchdog and recovery exercises handled by your team
  • The publisher supports implementation and provides associated documentation

Tests & exercises

A plan put into practice

A continuity plan that is never tested is an assumption. TranscribIA's backup and restoration procedures are executed and verified regularly, rather than merely documented.

Each DR drill (recovery exercise) restores a backup to an isolated environment and compares the result bit for bit with the source, using the version-controlled scripts backup-offsite.sh and restore-from-offsite.sh. This verification ensures that the archives are usable and the procedure is reproducible.

Daily

Automated backups and continuous monitoring

Periodic

Restoration exercises with integrity checks

After each test

Target times and documentation updated

These exercises support continuous review of actual RTO and RPO and improvements to procedures. Exercise reports can be shared with your teams during audits, as part of the cybersecurity component and the sovereignty approach.

Documentation & contact

For your leadership, IT and security teams

The full compliance pack — security measures, backup and retention policy, architecture diagrams, subprocessors — is publicly accessible without an account. Our team helps align this plan with your own business continuity approach.

Contact our compliance team View the compliance pack

Publisher: AMBASSADIA SARL (Monaco). Compliance contact: contact@transcribia.eu.