Is customer information encrypted at rest and in transit?
Yes. Storage encryption is always on, and every connection uses TLS 1.2 or later.
Complete edition · Send invoices and keep the books
Langford · built on open-source software


Full business accounting: invoices, payments, purchasing and reports, plus much more if you want it.
Tested by Langford on Oct 21, 2026: Started from the project's published images and signed in as a new admin; the page showed "Framework". Read the test report
Built on ERPNext, open-source software (GPL-3.0). Source available.
Needs setup. Turn on sign-in rules and user roles before you store client records.
Started from the project's published images and signed in as a new admin; the page showed "Framework". Testing shows the app starts and signs in. It is not a security audit.
You hold customer information, so you need a written information security program (WISP), and every vendor that touches the data belongs in it. This hosting covers on our side several elements of the Safeguards Rule under the Gramm-Leach-Bliley Act (GLBA): encryption, logging and monitoring, access limits and change control. For advisers and broker-dealers it helps you meet the safeguarding parts of SEC Regulation S-P. Below are vendor due-diligence questions answered for Langford Ledger · Complete.
Yes. Storage encryption is always on, and every connection uses TLS 1.2 or later.
Not by default. Turn on this app's own two-step sign-in if it has one. Our platform-wide sign-in with authenticator codes is designed but not built yet.
Our hosting logs every database and storage access to a separate archive kept 6 years. A per-user activity screen inside the app depends on the app; our built-in one is designed, not built. Each customer's setup is also assessed continuously against the hosting rules.
Our side: the app's identity can reach only its own database and storage, and nothing is reachable from the internet except the app. Inside the app, row-level limits are designed, not built; use the app's roles.
Every change is code, pinned to an exact image, and recorded with who made it.
The whole setup can be destroyed on request. Export and delete of single records inside the app is designed, not built.
Not yet. Our audit archive is write-once (WORM), but its lock is not engaged yet, so it does not yet meet broker-dealer record-keeping rules. It also holds audit logs, not your business records.
These run on your setup when we launch it.
Tested is not an audit. We check our hosting and test that the app starts and signs in; meeting these rules is still your program's job.
Started from the project's published images and signed in as a new admin; the page showed "Framework".
The result file is under Technical details.
Customer reviews appear here once offices are using it.
From our last MySQL hosting check run: runs/mysql-test-2026-10-21/verify.txt. 12 of 12 passed. Control ids are defined in docs/CONTROLS.md.
| Result | Check | What was checked |
|---|---|---|
| Pass | NET-PRIVATE | mysql public network: Disabled |
| Pass | NET-PRIVATE | storage public network: Disabled |
| Pass | IAM-WORKLOAD | storage shared key: false |
| Pass | ENC-TRANSIT | mysql require_secure_transport: ON |
| Pass | ENC-TRANSIT | container app allowInsecure: false |
| Pass | AUDIT-LOG | mysql audit_log_enabled: ON |
| Pass | BACKUP | mysql PITR days: 35 |
| Pass | GUARDRAILS | deny assignments on rg: 8 |
| Pass | POSTURE | audit initiatives on rg: 2 |
| Pass | ENC-TRANSIT | GET <your app address> 200 |
| Pass | AUTH-UNIQUE | /books without a session: 302 |
| Pass | NET-PRIVATE | anonymous blob read from the internet: 403 |