Langford Calendar

Holding client data

Needs setup. Turn on sign-in rules and user roles before you store client records.

What “Tested” means

Started from the project's published images and signed in as a new admin; the page showed "Bookings". Testing shows the app starts and signs in. It is not a security audit.

I run a:

Rules this helps you meet: NY DFS Part 500 — The safeguards apply once we host it

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 Calendar · Standard.

What your examiner or auditor will ask

Is client NPI encrypted, both stored and in transit?

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.

BuiltEvidence: the checks below · our control listHelps you meet: NY DFS cybersecurity rule (23 NYCRR 500.15)

Can someone reach the client data from the internet without signing in?

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.

BuiltEvidence: the checks below · our control listHelps you meet: NY DFS cybersecurity rule (23 NYCRR 500.07)

Do you require multi-factor authentication (MFA) for producers and CSRs?

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.

Designed, not builtEvidence: the checks below · our control list

Do you keep audit trails of who accessed or changed records?

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.

BuiltEvidence: the checks below · our control listHelps you meet: NY DFS cybersecurity rule (23 NYCRR 500.06)

Is the data backed up, and can you restore it?

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.

BuiltDesigned, not builtEvidence: the checks below · our control list

What's still on you

Your written information security program and risk assessment. This page is evidence for it, not the program itself.
Deciding who gets access: add and remove producers and CSRs the day they join or leave, and give each one their own login.
MFA on everything else that touches NPI: email, agency management system, carrier portals.
Notifying the insurance commissioner (in New York, the DFS superintendent) within 72 hours of a cybersecurity event. That notice is the agency's job; we tell you what we see on our side.
Keeping this page and the check results in your vendor file for the examiner.

Rules this helps you meet: HIPAA Security Rule — The safeguards apply once we host it

We don't sign Business Associate Agreements (BAAs) yet. Don't store patient health information until we do.

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 Calendar · Standard, and the parts that stay with the practice.

What your examiner or auditor will ask

Access control: can only the right people and systems reach ePHI?

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.

BuiltEvidence: the checks below · our control listCovers on our side: HIPAA Security Rule (45 CFR 164.312(e)(1), 164.312(a)(1))

Audit controls: is access to ePHI recorded?

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.

BuiltDesigned, not builtEvidence: the checks below · our control listCovers on our side: HIPAA Security Rule (45 CFR 164.312(b))

Integrity: can records be changed or destroyed improperly without anyone knowing?

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.

Partly coveredEvidence: the checks below · our control list

Transmission security: is ePHI protected when it moves?

Yes. TLS 1.2 or later on every connection, no plain-HTTP listener, and the database refuses unencrypted connections.

BuiltEvidence: the checks below · our control listCovers on our side: HIPAA Security Rule (45 CFR 164.312(e)(1))

Is ePHI encrypted where it is stored?

Yes. Database and file storage encryption is always on.

BuiltEvidence: the checks below · our control listCovers on our side: HIPAA Security Rule (45 CFR 164.312(a)(2)(iv))

Unique user identification and automatic log-off?

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.

Designed, not builtEvidence: the checks below · our control list

What's still on you

“Minimum necessary”: set user roles so front desk, billing and clinicians each see only what their job needs.
Your risk analysis and written policies, and training your staff.
A Business Associate Agreement with us before any PHI goes in (see above).
Patient access requests and breach notification to patients. Those are the practice's duties.

Rules this helps you meet: GLBA Safeguards Rule — The safeguards apply once we host it

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 Calendar · Standard.

What your examiner or auditor will ask

Is customer information encrypted at rest and in transit?

Yes. Storage encryption is always on, and every connection uses TLS 1.2 or later.

BuiltEvidence: the checks below · our control listMaps to: FTC Safeguards Rule under GLBA (16 CFR 314.4(c)(3))

Is multi-factor authentication (MFA) required for anyone who accesses customer information?

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.

Designed, not builtEvidence: the checks below · our control list

Do you log and monitor user activity?

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.

BuiltDesigned, not builtEvidence: the checks below · our control listMaps to: FTC Safeguards Rule under GLBA (16 CFR 314.4(c)(8), 314.4(d)(2))

Is access limited to authorized users and systems?

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.

BuiltDesigned, not builtEvidence: the checks below · our control listMaps to: FTC Safeguards Rule under GLBA (16 CFR 314.4(c)(1))

How are changes to the system managed?

Every change is code, pinned to an exact image, and recorded with who made it.

BuiltEvidence: the checks below · our control listMaps to: FTC Safeguards Rule under GLBA (16 CFR 314.4(c)(7))

Can customer information be securely disposed of when you leave?

The whole setup can be destroyed on request. Export and delete of single records inside the app is designed, not built.

Designed, not builtEvidence: the checks below · our control list

Do your records meet broker-dealer write-once record-keeping?

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.

Not yetEvidence: the checks below · our control list

What's still on you

Your written information security program (WISP), the person in charge of it, and your risk assessment. Our answers go in it; they are not it.
MFA on the rest of your systems: email, custodian and CRM logins.
Privacy notices and incident response for your customers.
Vendor oversight: keep this page and the check results on file, and re-check them each year.

The 12 checks we run

These run on your setup when we launch it.

Policyholder records sit on a private database no one on the internet can reach runs when we set it up
Client documents and policy files are kept in private storage with no internet address runs when we set it up
No shared password opens the file storage; only this app's own identity can get in runs when we set it up
The database refuses any connection that is not encrypted runs when we set it up
The app only answers over encrypted (https) connections runs when we set it up
Every change to policyholder records is written to an audit log runs when we set it up
Policyholder records can be restored to any point in the last 35 days runs when we set it up
Settings that would weaken any of this are blocked automatically runs when we set it up
Your setup is reviewed continuously against the security rules for your kind of data runs when we set it up
The app is up at its own secure address runs when we set it up
Producers and CSRs must sign in before anything opens runs when we set it up
A stranger who guesses a file's address gets “access denied” runs when we set it up

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.

Langford test reportOct 21, 2026

Started from the project's published images and signed in as a new admin; the page showed "Bookings".

The result file is under Technical details.

Customer reviews appear here once offices are using it.

Built on: Cal.com (community edition) (open source)
Licence: AGPL-3.0 core + commercial licence for packages/features/ee and apps/api/v2/src/ee, at the pinned release v6.2.0 (LICENSE at tag v6.2.0, runs/fixretest-2026-10-22/calcom-licence/LICENSE-v6.2.0). The repo became MIT on main in ab21c7f805 (2026-04-15, Cal.diy); no release or image has been published since, so MIT does not cover any image we can pin
Database: PostgreSQL [compose]
Docker: yes (Dockerfile + docker-compose.yml in repo) [compose]
Peak memory in our test: 1470.5 MB
Images: calcom/cal.com:latest, postgres:16
Source: https://github.com/calcom/cal.diy
Website: https://cal.com
Tested on: Oct 21, 2026
Test result file: runs/catalog-boot-2026-10-20/calcom/result.json

Hosting checks (for your IT person)

From our last PostgreSQL hosting check run: runs/crm-test-2026-10-20/verify.txt. 12 of 12 passed. Control ids are defined in docs/CONTROLS.md.

Result	Check	What was checked
Pass	NET-PRIVATE	postgres public network: Disabled
Pass	NET-PRIVATE	storage public network: Disabled
Pass	IAM-WORKLOAD	storage shared key: false
Pass	ENC-TRANSIT	postgres require_secure_transport: on
Pass	ENC-TRANSIT	container app allowInsecure: false
Pass	AUDIT-LOG	pgaudit loaded: pg_stat_statements,pgaudit
Pass	BACKUP	postgres PITR days: 35
Pass	GUARDRAILS	deny assignments on rg: 7
Pass	POSTURE	audit initiatives on rg: 2
Pass	ENC-TRANSIT	GET <your app address> 200
Pass	AUTH-UNIQUE	document download without a session: 401
Pass	NET-PRIVATE	anonymous blob read from the internet: 403

Screenshots

About this app

What it replaces

Information

Other editions of Langford Calendar

Holding client data

What “Tested” means

What your examiner or auditor will ask

Is client NPI encrypted, both stored and in transit?

Can someone reach the client data from the internet without signing in?

Do you require multi-factor authentication (MFA) for producers and CSRs?

Do you keep audit trails of who accessed or changed records?

Is the data backed up, and can you restore it?

What's still on you

What your examiner or auditor will ask

Access control: can only the right people and systems reach ePHI?

Audit controls: is access to ePHI recorded?

Integrity: can records be changed or destroyed improperly without anyone knowing?

Transmission security: is ePHI protected when it moves?

Is ePHI encrypted where it is stored?

Unique user identification and automatic log-off?

What's still on you

What your examiner or auditor will ask

Is customer information encrypted at rest and in transit?

Is multi-factor authentication (MFA) required for anyone who accesses customer information?

Do you log and monitor user activity?

Is access limited to authorized users and systems?

How are changes to the system managed?

Can customer information be securely disposed of when you leave?

Do your records meet broker-dealer write-once record-keeping?

What's still on you

The 12 checks we run

Hosting checks (for your IT person)