Security and trust
Your register is somebody’s answer to a hard question.We treat it that way.
This page describes how BarrierLedger isolates, holds and returns client data. It states what is designed and what is contracted — and, at the bottom, what we do not claim.
Tenancy
Isolated by construction, not by convention.
The strongest promise about data is structural: there is no code path that returns one client’s register to another.
One tenant per client
Every client gets its own tenant with its own register, method profiles, users and history. Nothing is shared between operators, and no cross-tenant view exists.
Isolation enforced in the database
Tenant isolation is enforced with PostgreSQL row-level security, enabled and forced from the first migration rather than filtered in application code.
A standalone product
BarrierLedger has its own login, tenants, billing and runtime. It shares brand and patterns with FEEC’s other products, not a database or a tenant.
Consultancies, one tenant each
If you assess wells for several operators, each operator gets its own tenant so the register, profile, approvals and audit trail belong to them.
Where the data lives
A live register does not sit on the shared host.
The shared cloud runs the fictional demo tenant and permissioned fixtures. A customer’s register is held on dedicated hosting or inside the customer’s own infrastructure.
Shared cloud
A separate tenant on shared infrastructure, used for the demo tenant and for permissioned fixtures. It is where an evaluation runs, not where a live customer register is kept.
Dedicated hosting
Your own isolated server and database running the same software, managed by FEEC, with backup retention and recovery time set in the order form.
Self-hosted licence
The platform runs inside your own infrastructure, under your own change control, with your own database, backups and key management.
Availability targets, stated as targets
Access and approval
Who can change a status, and who cannot.
Integrity data is only trustworthy if the route to a change is controlled and visible.
- Sign-in requires a one-time code in addition to a password.
- Roles decide who may assess, who may review, who may approve and who may only read.
- Read-only, audit and external-verifier accounts are free and cannot change a status.
- An override takes a mandatory reason and a second approver, and is stored alongside the computed result rather than replacing it.
- Every assessment, approval and override is attributable and kept in the history.
Backups and recovery
Reporting a concern
Data handling
Written down, and available before you send anything.
The legal pack is published in full, so it can be read before a conversation rather than after a signature.
A DPA before any data moves
A data processing agreement is signed before anything is shared, and the sub-processors involved are published rather than described in general terms.
Your data stays yours
You keep ownership of your registers, schematics and well records. Derived fixtures use anonymised or fictional data with written permission, never a customer’s live data.
Export and deletion on request
Full export at any time, including the assessment history, and deletion on request at the end of an engagement.
Nothing leaves without a reason
Client data is not used to train anything, is not shared between tenants, and is not added to a mailing list.
The documents
What we do not claim
- We hold no information-security certification and no independent security attestation, and we claim none.
- No regulator approves, audits or endorses us.
- We publish no badge, trust seal or operator logo.
- We do not claim service levels beyond the targets written into the Service Level Agreement and the order form.
Ask us the awkward security question.
Bring your own checklist. We will answer against what is designed and contracted, and tell you plainly where a claim would be too strong.