Compliance

Compliance control mapping

This page maps Restorable's evidence output to the specific control language auditors assess. For each framework: the control reference, what it requires, and what Restorable produces as evidence toward it.

If your auditor asks for something not listed here, email support@restorable.app. We will tell you honestly whether we cover it or not.

NIS2 Directive (EU 2022/2555)

Article 21(2)(c): backup management and disaster recovery

Requirement: Essential and important entities shall implement appropriate and proportionate measures including "business continuity, such as backup management and disaster recovery, and crisis management."

What Restorable produces:

Automated, scheduled database backups (daily or hourly depending on plan) encrypted with customer-held keys before upload.
Ciphertext stored in EU-sovereign object storage (Scaleway FR), outside the primary provider's blast radius.
Documented retention policy (30, 90, or custom days by tier).

Article 21(2)(f): assessing the effectiveness of measures

Requirement: "Policies and procedures to assess the effectiveness of cybersecurity risk-management measures." This applies to all measures under Article 21, not only backup. Restorable provides the effectiveness evidence for backup measures specifically. Other risk-management measures (access controls, patching, incident response, training) require their own assessment processes.

What Restorable produces:

Scheduled restore tests (weekly on Starter, weekly + on-demand on Pro/Team) that run a full pg_restore or mongorestore into an isolated container.
Application-level checks (row counts, index presence, NULL assertions, custom SQL/aggregation) that verify the restored database matches your schema expectations.
A DSSE Ed25519-signed receipt (in-toto Statement v1) for each restore test, recording the engine version, backup size, restore duration, check results, and verdict.
Per-org append-only transparency log with inclusion and consistency proofs.

Article 21(2)(h): cryptography and encryption policies

Requirement: "Policies and procedures regarding the use of cryptography and, where appropriate, encryption."

What Restorable produces:

Backup encryption with customer-held age (X25519) keys. The agent encrypts before upload; Restorable's servers store only ciphertext. No managed-keys tier exists.
Receipt signing with customer-held Ed25519 keys. The signing key never leaves the customer's infrastructure.
Key management is documented in the agent configuration and the auth key setup guide.

Article 20: management accountability

Requirement: Management bodies must approve and oversee cybersecurity risk-management measures. Article 20 includes personal liability for management who fail to approve, oversee, or ensure implementation of measures.

What Restorable produces: Weekly evidence email summarizing restore test outcomes, and signed receipts accessible via dashboard and API. These are inputs into management oversight, not a substitute for it. Article 20 compliance also requires documented governance arrangements, board-level approval of cybersecurity policies, and management training records. Those are outside Restorable's scope.

Article 21(2)(d): supply chain security

Requirement: "Supply-chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers."

When your organisation uses Restorable, you insert us into your backup supply chain. Article 21(2)(d) requires you to assess the security of that relationship. This section documents what Restorable provides for that assessment.

What Restorable provides for your supply chain assessment:

Open-source agent. The agent, verifier, core library, and wire-protocol specification are Apache-2.0. Your security team audits every line of trust-path code before deploying it.
Public infrastructure inventory. The infrastructure page lists every component, provider, and location in the stack. Your procurement team cross-checks each vendor against your own requirements.
EU-sovereign stack. No US vendors in the data path. Hetzner, Scaleway, OVH, Mollie, Brevo, Bunny. Reduces CLOUD Act and Schrems II exposure in your supply chain assessment.
Data Processing Agreement. Covers metadata-only scope (Restorable processes only ciphertext and receipt metadata; we cannot access your plaintext data). Includes sub-processor list and 48-hour breach notification commitment. Available at /dpa.
Terms of Service. Receipt-as-observation liability framing: receipts attest to what the agent observed, not to what your production database looks like. Available at /terms.
Reproducible builds. Customers verify the released binary matches the published source. The trust page documents the rebuild recipe and signing keys.
No vendor access to customer data. The architecture makes this structurally impossible, not policy-gated. Customer-held age encryption keys, no managed-keys tier, no exceptions.

What is not yet available (planned):

Pen test report cadence and disclosure to customers under NDA.
Published vulnerability management process documentation.
Dependency scanning results (SBOM/VEX) for the agent and verifier.

These are in progress. If your supply chain assessment requires any of them before you can proceed, email support@restorable.app and we will give you a timeline.

ISO 27001:2022

Annex A, control A.8.13: information backup

Requirement: "Backup copies of information, software and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup."

What Restorable produces:

"Maintained": automated, encrypted backups on the schedule defined in your plan (daily or hourly). Retention policy documented and enforced. Each backup is retention-locked via S3 Object Lock (Compliance/WORM mode); deletion before the retention period expires is structurally impossible.
"Regularly tested": scheduled restore tests with signed receipts. Each receipt is a dated artifact proving the test occurred, what was tested, and the outcome.
"In accordance with the agreed policy": the agent configuration (config.yaml) is the machine- readable backup policy. Frequency, retention, checks, and encryption are all declared and auditable.

The signed receipt is independently verifiable using the open-source restorable-verify CLI. The auditor does not need access to Restorable's infrastructure or the customer's infrastructure to validate it.

SOC 2 (Trust Services Criteria)

A1.2: recovery infrastructure

Requirement: "The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives."

What Restorable produces:

Documented backup process: agent configuration declares sources, frequency, encryption, and retention.
Encrypted offsite copy in EU-sovereign storage, independent of the primary database provider.
Dashboard showing backup status, storage usage, and restore test history per source.

A1.3: recovery testing

Requirement: "The entity tests recovery plan procedures supporting system recovery to meet its objectives," including testing backup integrity and completeness using "realistic scenarios."

What Restorable produces:

Automated restore into an isolated container (a realistic scenario: cold restore from ciphertext, not a warm replica).
Application-level checks that go beyond "did pg_restore exit 0" to verify schema integrity, row counts, and custom invariants.
Signed receipt with full test metadata: engine version, backup size, restore duration, individual check results, and pass/fail verdict.
Historical restore test log in the dashboard and transparency log, showing test frequency and pass rate over time.

DORA (Digital Operational Resilience Act)

DORA applies to EU financial entities (banks, insurers, investment firms, payment institutions, and their critical ICT third-party providers). If your organisation is not in scope of DORA, the NIS2 and ISO 27001 mappings above are the relevant controls.

In application since January 2025.

Article 11: ICT business continuity policy

Requirement: Testing of ICT business continuity plans "at least yearly and after substantive changes to ICT systems," including cyber-attack scenarios and switchover to backup capacity.

What Restorable produces: Restore tests that run weekly (or more) exceed the annual minimum. Each test is a documented exercise that can be referenced in your ICT business continuity plan. The signed receipt chain provides evidence of testing cadence over time.

Article 12(2): backup scope and frequency

Requirement: Backup policies that specify "the scope of the data that is subject to the backup" and "the minimum frequency of the backup, based on the criticality of information or the criticality of the business functions."

What Restorable produces:

Agent configuration declares each source (database, connection, engine) and the backup schedule as a cron expression. This is the machine-readable backup scope and frequency declaration.
Restore tests verify the full scope of each declared source, not a sample.

Article 12(3)-(5): segregated recovery and integrity

Requirement: Recovery into systems "physically and logically segregated from the source ICT system." Post-recovery integrity checks.

What Restorable produces:

"Segregated from the source": the restore runs in a fresh, isolated container. No connection to the production database or network.
"Post-recovery integrity checks": application-level checks (row counts, schema assertions, custom SQL/aggregation) run after the restore completes. Each check is an independent assertion recorded individually in the receipt.

Article 12(7): post-incident reconciliations

Article 12(7) requires "multiple checks and reconciliations" after restoring from a real ICT-related incident, to ensure the highest level of data integrity. This is about post-incident recovery, not routine backup testing: it typically involves reconciliation between systems and with external counterparties.

Restorable's application-level checks support post-incident integrity verification (you can run an on-demand restore test after an incident and review the check results). But Article 12(7) compliance also requires inter-system reconciliation processes that are outside Restorable's scope.

Commission Delegated Regulation (EU) 2024/1774 (RTS), Articles 24-26

The DORA Level 1 text (Articles 11, 12) sets the framework. The Regulatory Technical Standards in Commission Delegated Regulation (EU) 2024/1774 specify the detail that supervisors and auditors assess against. Banks and insurers reading DORA should cross-reference these RTS articles alongside the Level 1.

Article 24: ICT business continuity policy components

Requirement: Financial entities shall include in their ICT business continuity policy "documented backup policies specifying the scope of data subject to backup and the minimum frequency of backup," along with "recovery time and recovery point objectives for each function," and "communication plans for internal staff, external stakeholders, and the media."

What Restorable produces:

The agent's config.yaml is the machine-readable backup policy: it declares every source, backup schedule (cron expression), retention period, and encryption configuration. This maps directly to the "scope of data" and "minimum frequency" requirements.
Signed receipts record the actual restore duration per source, giving your team empirical data for setting recovery time objectives (RTOs). A receipt that says "restore took 6m52s" is stronger evidence for an RTO than an untested estimate.
Recovery point objectives (RPOs) are visible from the backup schedule declared in config and the timestamps in sequential receipts.

Article 25: testing of business continuity plans

Requirement: Financial entities shall "test the ICT business continuity plans and the ICT response and recovery plans at least on a yearly basis and after substantive changes to the ICT systems." Testing must cover "scenarios of severe business disruptions" and include backup and restore procedures.

What Restorable produces:

Weekly restore tests exceed the annual minimum by at least 50x. Each test is a documented exercise with a signed receipt recording the outcome, engine version, restore duration, and check results.
On-demand restore tests (Pro/Team) let you run a test after any substantive change to your ICT systems: a Postgres major version upgrade, a schema migration, or a provider change.
The receipt chain provides a time-series record of testing cadence. An auditor can verify not only that tests occurred, but how frequently, and whether any gaps exist.

Article 26: recovery procedures and methods

Requirement: Financial entities shall implement "ICT response and recovery plans" including "prioritised recovery actions," "documented recovery procedures," and processes to "verify the integrity of the restored data."

What Restorable produces:

Each restore test is a documented recovery procedure executed end-to-end: decrypt the ciphertext, spin up a fresh database container, run pg_restore or mongorestore, execute application-level checks.
Post-restore integrity verification is built in. Application checks (row counts, schema assertions, NULL checks, custom SQL/aggregation) run after every restore and are individually recorded in the signed receipt.
The transparency log provides an append-only, tamper-evident record of all recovery test events, supporting the "documented recovery procedures" requirement.

BSI C5 (Cloud Computing Compliance Criteria Catalogue)

OPS-04 and related controls

Requirement: Documented and regularly tested backup and restore procedures. Relevant for selling into German public sector and regulated markets.

What Restorable produces:

Agent configuration as documented procedure.
Signed receipts as evidence of regular testing.
Transparency log as tamper-evident audit trail.
EU-sovereign data residency (Scaleway FR) satisfying C5 data location requirements.

What Restorable does not cover

Restorable verifies database backup restores. It does not cover all backup obligations under NIS2 or the frameworks above. Areas outside our scope:

Non-database systems: file systems, VM images, identity systems (Entra ID / Active Directory), SaaS application data, IaC state, secrets and key material.
Air-gap controls (offline copies, network isolation for ransomware resilience). Note: Restorable does provide backup immutability via S3 Object Lock in Compliance mode (WORM). Every backup is retention-locked for the tier period (30/90/365 days). Deletion before expiry is structurally impossible, not policy-gated. See the trust page for details.
Full business continuity plan testing beyond database restore (failover, communication plans, crisis management).

If your audit scope includes these areas, you need additional controls alongside Restorable.

Audit narrative template

Use this as a starting point when writing up your backup verification controls for an audit or security questionnaire. Replace the bracketed values with your specifics.

[Company] backup verification statement

[Company] uses Restorable to perform automated restore verification of its [Postgres / MongoDB] databases. The agent runs on [Company]'s infrastructure and is configured to:

Back up [N] database(s) [daily / hourly], encrypted with customer-held age (X25519) keys before upload to EU-sovereign object storage (Scaleway, Paris, FR). Restorable's servers store only ciphertext. No managed-keys tier is offered.

Run a full restore test [weekly / weekly + on-demand] into an isolated container environment with no network access to production.

Execute [N] application-level checks per restore, verifying schema integrity, row counts, and application invariants.

Produce a DSSE Ed25519-signed receipt (in-toto Statement v1) for each restore test. The signing key is held on [Company]'s infrastructure; it never leaves the agent process.

Append each receipt to a per-org transparency log. The log is append-only and provides cryptographic inclusion and consistency proofs, preventing silent modification or removal of historical entries.

Each receipt is independently verifiable using the open-source restorable-verify CLI against [Company]'s Ed25519 public key. No access to Restorable's infrastructure or [Company]'s infrastructure is required for verification.

This process addresses the restore testing and evidence expectations of [NIS2 Article 21(2)(f) / ISO 27001 A.8.13 / SOC2 A1.3 / DORA Article 12] by providing recurring, automated, documented, and independently verifiable evidence that backup recovery procedures are effective.

Evidence artifacts: weekly evidence email, signed receipts (available via dashboard and API), transparency log with inclusion and consistency proofs.