This is the question professional teams ask before handing a file system their work. We answer it plainly: how Orbifs is built, where data lives, how access is controlled, and how files recover. Every control below is something we actually run today. Where something is a backstop, a target, or still being finalised, we mark it — and don’t claim it as done.
Controls marked live are implemented and running in production. Items marked being finalised are genuinely not yet locked, and we will not present them as complete until they are. No certification is claimed. This whitepaper is versioned and dated; each update is published. For a structured, control-by-control self-attestation, see our CSA STAR Level 1 self-assessment (CAIQ-lite).
Metadata and file content (object bytes) are stored in the Paris, France region; backups are kept off-region, also in Paris. All on infrastructure operated by a European cloud provider.
| Property | Detail |
|---|---|
| Metadata region | Paris, France (EU) |
| Object storage region | Paris, France (EU) — file content / bytes |
| Backups | Off-region, Paris (EU) — separated from primary metadata for resilience |
| Provider | OVHcloud (European cloud provider) — named in our sub-processor list |
| Recovery | Content-addressed, immutable, tamper-resistant version history |
| Data transfer | No data-transfer fees for customers |
Full residency, jurisdiction and sub-processor detail is in the Data Residency & Sovereignty Statement.
Files are split into chunks and stored by the cryptographic hash of their contents. This is the foundation for de-duplication, integrity verification and tamper-resistant version history.
Every chunk is identified by its SHA‑256 hash. Content that hashes the same is the same content — which lets us verify integrity on read and detect any corruption or tampering.
Files are divided using content-defined chunking, so a small edit only changes the chunks it touches. Uploads and version history stay efficient even on large CAD, BIM and point-cloud files.
Each saved version is an immutable composition of content-addressed chunks. Earlier versions are never mutated in place — they remain recoverable through your plan’s retention window.
| Layer | Current position |
|---|---|
| In transit | live All client–service connections use TLS, terminated at our edge (Caddy) with modern, automatically-renewed certificates. |
| At rest | live Object storage uses server-side encryption (SSE, AES‑256) on the bucket holding your file content. |
| Key management | being finalised At-rest keys are currently managed by the storage provider. Our custody model and any customer-managed-key (BYOK) option are being finalised before we make a firm claim. |
| Zero-knowledge | Not offered today; tracked as a possible future capability, not a current claim. |
We will not assert end-to-end or zero-knowledge encryption unless the design genuinely provides it. Today, encryption in transit (TLS) and at rest (SSE‑AES256) are both live; the key-management custody model is what remains to be finalised, and is described above honestly.
Isolation between customer organisations is enforced primarily in the application layer: every request carries an authenticated tenant context, and every query is scoped to that tenant. No request can address data outside its own tenant.
As defence-in-depth, the metadata database also carries Postgres row-level security (RLS) policies. We describe these honestly as a backstop — application-layer query scoping is the active, primary mechanism, not RLS alone.
Access to projects runs through user accounts, roles and per-project permissions in the admin console. Users and administrators get the access their role needs — no more.
Recovery is not one feature but several layers: immutable versions, write-once object storage, conflict-copy safety, and off-region continuous backups with point-in-time recovery.
| Layer | What it does |
|---|---|
| Immutable versions live | Prior versions and deleted files are restorable through your plan’s retention window — the basis for recovering from mistakes and ransomware. |
| WORM object storage live | The production object bucket uses S3 versioning plus Object Lock (write-once-read-many), so stored bytes cannot be overwritten or deleted before their lock expires. |
| Conflict-copy safety live | When two people edit the same file concurrently, neither edit is silently overwritten; a conflict copy is preserved so no work is lost. |
| Off-region backups (PITR) live | Metadata is continuously backed up (pgBackRest, WAL/point-in-time recovery) to a separate off-region bucket in Paris, encrypted at rest, and restore-drilled. |
| Backup-failure alerting live | A dead-man’s-switch monitor alerts us if a backup is missed, so a silent backup failure can’t go unnoticed. |
| Published RPO/RTO & restore SLA being finalised | We restore-test in every pilot today; the formally published recovery-point/recovery-time targets and SLA are being finalised. |
Immutable versions plus WORM object storage mean an attacker who reaches the live system still cannot rewrite or erase your version history within the lock window — but we describe this as strong recoverability, not an absolute guarantee.
Archi Systems AS is established in Norway, within the EEA, and applies the GDPR. Hosting customer data in the EU (Paris) involves no transfer of personal data outside the EEA.
A Data Processing Agreement is available for customers, alongside our privacy policy and technical & organisational measures (TOMs).
Kept short and EU-based, and shared in full in our sub-processor list. We run our own mail server in the EEA, so no third party handles your support correspondence.
Built with EU security frameworks in mind, including raised expectations on backup, recovery and access control.
For the full picture of where data lives and who can touch it, read the Data Residency & Sovereignty Statement →
A non-negotiable principle: do not claim a certification before it exists. Here is what we’re pursuing, and in roughly what order — plus the one assurance artefact we can publish today.
| Target | What it signals | Status |
|---|---|---|
| CSA STAR Level 1 (CAIQ self-assessment) | A public, structured self-attestation against the Cloud Security Alliance’s questionnaire — the one assurance artefact a vendor can publish without a third-party audit. | published |
| ISO/IEC 27001 | Mature information-security management system — our intended anchor. | pursuing |
| SOC 2 (Type I → II) | Audited security controls over time; valued by larger and international customers. | pursuing |
| Cyber Essentials | Baseline cyber hygiene — a lighter, quicker early signal. | candidate |
| ENS / SecNumCloud-adjacent | Public-sector and French sovereign-cloud expectations, per target market. | candidate |
We publish a CAIQ-lite self-assessment that maps the controls on this page to the standard security domains, with honest yes / partial / planned answers. Read the CSA STAR Level 1 self-assessment →
No third-party certifications are claimed yet. The CSA STAR Level 1 entry above is a self-assessment, not an audit. A short, EU-based sub-processor list keeps our scope simple, and the policy set behind this page — incident response, backup/restore, data residency, GDPR — is in place or under legal review. We’ll publish each certification only once formally achieved.
Need our DPA, sub-processor list, CAIQ self-assessment or a completed security questionnaire? We keep an answer bank ready. Request security documents →
Every pilot includes a restore test: we restore a prior version and a deleted file so you see recovery work on your own data before you commit.