Classic edition · Manage staff and hiring
Langford · built on open-source software
Employee records, time off and hiring, for a growing office.
Tested by Langford on Oct 21, 2026: Started from the project's published images and signed in as a new admin; the page showed "Dashboard". Read the test report
Built on OrangeHRM, 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 "Dashboard". Testing shows the app starts and signs in. It is not a security audit.
You hold policyholder and client nonpublic personal information (NPI), so your information security program has to cover where it lives. This hosting helps you meet parts of your state's insurance data security law (based on the NAIC model law) and, in New York, the DFS cybersecurity rule (23 NYCRR 500). Below are the questions you get from a market conduct examiner, a carrier or your E&O questionnaire, answered for Langford People · Classic.
Yes. The database and file storage are encrypted at rest, and every connection uses TLS 1.2 or later. A setting that would weaken this is refused.
No. The database and file storage have no public address; only this app, inside a private network, can reach them. Producers and CSRs get in only through the app's sign-in.
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.
Backed up: yes, point-in-time restore for 35 days. Restore drills: designed, not run yet, so we cannot show you a restore receipt today.
If your practice keeps patient health information (PHI, or ePHI once it is electronic), these are the HIPAA Security Rule technical safeguards this hosting covers on our side for Langford People · Classic, and the parts that stay with the practice.
On our side, yes: the database has no public address, the app holds no cloud keys, and its passwords live in a vault. Who sees which patient inside the app is set by the practice through user roles.
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.
Partly covered. Changes are logged, the audit archive is write-once, and backups let us roll back 35 days. We have not mapped a control to this safeguard yet, so treat it as open.
Yes. TLS 1.2 or later on every connection, no plain-HTTP listener, and the database refuses unencrypted connections.
Yes. Database and file storage encryption is always on.
Depends on this app's settings: give each person their own login and set an idle time-out. Our platform-wide versions are designed, not built.
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 People · Classic.
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 "Dashboard".
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 |