Security and trust
Integrity data, held to an engineering standard.
A barrier register answers hard questions about live wells. BarrierLedger isolates every operator in the database, keeps production apart from demo, controls who can change a status, and records the basis of every assessment.
Tenancy
Isolated by construction.
The strongest promise about data is structural: there is no code path that returns one operator’s register to another.
One tenant per operator
Every operator gets its own tenant with its own register, method profiles, users and history. There is no cross-tenant view, and consultancies run one tenant per operator they support.
Isolation enforced in the database
PostgreSQL row-level security is enabled and forced on every tenant table from the first migration, and a tenant-boundary test suite runs on every change.
A standalone product
BarrierLedger has its own sign-in, tenants, billing and runtime. It shares engineering standards with FEEC’s other products, never a database or a tenant.
Macros never run
Imported workbooks are parsed as data and validated row by row. Nothing in an uploaded file is executed.
Where the data lives
Hosted your way.
Every option runs the same software. Customer data is held in production only; the demo and staging environments carry fictional data.
Shared cloud
The standard multi-tenant production platform, included in every plan, with a separate tenant per operator and encrypted nightly backups.
Dedicated hosting
Your own isolated server and database running the same software, managed by FEEC, with backup retention and recovery time agreed in the order form.
Self-hosted licence (on request)
Planned and quoted on request, in place of the Enterprise subscription: the platform runs inside your own infrastructure, under your own change control, with your own database, backups and key management.
Monthly availability targets are published on the pricing page and set out in the Service Level Agreement; any service credits are set in your order form.
Access and approval
Who can change a status, and how.
Integrity data is only trustworthy if every route to a change is controlled and visible.
- Sign-in supports a one-time code in addition to a password, and your organisation can require it for every user.
- Roles decide who may enter data, who may assess, who may review, who may approve and who may only read.
- Any member other than an administrator can be limited to the assets they work on; the database applies that limit to everything they read and write.
- Status overrides need a written reason and a second person’s approval before they take effect.
- A locked review period cannot be edited; a change after locking is a restatement with its own approval and history.
- Tenant policy changes are requested by an integrity engineer and approved or rejected by a client administrator.
- Every assessment stores its input hashes, method-profile and settings versions, and the engine build.
- The API’s OpenAPI description is published on purpose: knowing the routes grants nothing, because every call needs a signed-in user or an API key and is held to that tenant’s roles and isolation.
Backups and recovery
Free read-only access
Operations
Measured, and said plainly.
What the platform measures, what alerts the operator, and who answers.
The platform measures the response time and the error responses of every API route, the depth of each background job queue, and how long ago each scheduled job last succeeded, including the scan that raises alarms, without identifying any tenant, user or well. Uptime checks run every minute against the production service and alert the operator, and a second set of checks runs from outside the hosting environment. BarrierLedger is operated by a single engineer: outside the support hours in your order form, support is best effort, as the Service Level Agreement states. The operations trust pack sets out each control area, what shows it working and what is not yet in place.
Data handling
Written down 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 by name.
Your data stays yours
You own your registers, schematics and well records. Demo and staging environments carry fictional data only; customer data is held in production and nowhere else.
Export whenever you want
A full data export is available from the application on every plan, alongside Excel exports and report packs. Deletion at the end of a contract follows the DPA.
No secondary use
Customer data is not used to train anything, is not shared between tenants and is not added to a mailing list. The website runs no trackers and no third-party scripts.
The documents
Reporting a vulnerability
Good-faith reports are welcome and are not treated as a breach of the Acceptable Use Policy. Send the details through the enquiry form or the FEEC contact page; they reach the engineering team directly. Please do not access other customers’ data or disclose an issue publicly before we have had a reasonable time to fix it. Our security.txt carries the same route.
What we do not claim
Let's talk
Bring your security questionnaire.
We will walk through tenancy, hosting, access control and data handling against your own checklist, and put the answers in writing.