This is the summary of how BarrierLedger is operated, area by area, as it stands on 8 October 2026. It is written for an operator’s IT or security team before they send a questionnaire. Each area says plainly whether the control is shown working by a test or a recorded check, partly in place, written down as a procedure only, or not in place yet.
BarrierLedger holds no information-security certification or independent attestation, and this summary is not one. It is our own reading of our own evidence. The detailed control table, with the test, workflow or runbook section behind every row, and a pre-filled short-form cloud security questionnaire answered from it, are available on request through the enquiry form.
How the service is operated
BarrierLedger is operated by a single engineer. Support is given during the support hours stated in your order form; outside them, support is best effort, with no response-time commitment, as the Service Level Agreement says. The monthly availability target and how service credits work are set out there and in your order form.
What is measured, and what alerts
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. No tenant, user or well is identified in any of these measurements. Uptime checks run every minute against the production service and alert the operator; a second set of checks runs from outside the hosting environment every few hours and also verifies certificates and security headers. Unexpected application errors can be reported to an error tracker that receives no request content, no credentials and no database values.
Not yet in place: an uptime checker and status page hosted away from the production host, central retention of logs away from that host, and a dashboard with alert rules over the measurements above.
Where each area stands
Statuses: evidence means a test or a recorded check shows the control working; partial means part of the area is shown working and part is not yet in place; prose only means the procedure is written but not yet exercised; not applicable says why.
| Ref | Area | Status | In short |
|---|---|---|---|
| TC-01 | Logical access and tenant isolation | evidence | Row-level security is forced on every tenant table and tested against a real database on every change; roles and asset limits are enforced in the database; customer sign-in can require a one-time code. |
| TC-02 | Change management | partial | Every change runs the full test suites; production promotion needs the owner’s explicit confirmation and a green test run. Mandatory review by a second person is not yet enforced. |
| TC-03 | Vulnerability management | partial | Dependencies are scanned on every change and container base images weekly. An independent penetration test is scoped but not yet performed. |
| TC-04 | Secrets and key management | partial | Stored integration secrets are encrypted per record and the encryption key rotates without loss. No key-management service; a second key custodian is decided but not yet in place. |
| TC-05 | Backup and recovery | partial | Nightly encrypted backups to EU off-site storage and a local copy; a restore from the off-site copy was checked on 1 October 2026. Point-in-time recovery and a scheduled drill are not yet in place. |
| TC-06 | Logging, monitoring and error tracking | partial | See above. |
| TC-07 | Incident response | prose only | Severities, paging, customer notification and a post-mortem template are written; the plan has not yet been exercised. |
| TC-08 | Business continuity | prose only | The dedicated-hosting design and the rollback procedure are written; there is no standby host yet. |
| TC-09 | Asset and configuration management | partial | Host configuration is version-controlled and checked for drift. No hardened-host benchmark evidence yet. |
| TC-10 | Vendor management | partial | Sub-processors are published, including off-site backup storage and its region. No per-vendor review record yet. |
| TC-11 | Human resources and security awareness | not applicable | One engineer operates the service; there is no staff programme. |
| TC-12 | Platform-operator access | partial | Operator calls require a second factor and every one is recorded in an append-only log. Host-level operator actions are not yet in that log. |
| TC-13 | Encryption in transit | evidence | TLS on every public hostname, with certificates and security headers checked from outside. |
| TC-14 | Encryption at rest | partial | Backups and stored integration secrets are encrypted. Encryption of the database volume on the host is not yet evidenced. |
| TC-15 | Data lifecycle | partial | Export within 30 days of a request, deletion from live systems within 60 days, backup copies expire within 12 months, as the Data Processing Agreement states. No erasure has yet been performed and recorded. |
| TC-16 | Network and container hardening | partial | Administration paths are not public, and the application containers run read-only with every capability dropped. Restricting the origin to the CDN at the provider’s firewall is not yet in place. |
More on tenancy, access control and data handling is on the security page.