Information security policy

Effective 18 October 2026 · Version 1.0

1. Purpose and scope

This policy sets out how The Switchboard Inbox protects the information handled by Switchboard, the messaging and scheduling service available at app.theswitchboardinbox.com, and the systems it runs on. It covers the application, its database, the servers and accounts used to run it, and everyone who has access to any of them. It is read together with the access control policy, the incident response plan, the data retention and deletion policy and the privacy policy.

2. Who is responsible

Dante Nwokeocha, who operates The Switchboard Inbox, is the Security Officer. He approves this policy, decides who gets access, handles incidents, and answers security questions from customers and platforms. Anyone else given access in future is bound by it before they receive access.

3. What we protect

Restricted	Passwords, session and encryption keys, access tokens for Meta, TikTok, Acuity, email and AI services, authenticator secrets, clinical notes. Never written in plain text to the database, to logs, or to chat or email.
Confidential	Client names, phone numbers, email addresses, social handles, message text and attachments, appointment details, the activity record. Visible only to signed-in staff of the practice, according to their role.
Public	The pages of theswitchboardinbox.com.

Switchboard does not collect payment card numbers or government identification numbers.

4. Encryption

• In transit. All traffic between a browser, a messaging platform and the server uses TLS 1.2 or later, with certificates issued and renewed automatically. Browsers are instructed to use HTTPS only (HTTP Strict Transport Security). Older protocol versions are not offered.
• At rest, storage. The database is stored on an encrypted DigitalOcean Volume. DigitalOcean encrypts Volumes at rest using LUKS and does not encrypt the local disks of its Droplets, so we keep client data off the Droplet's own disk.
• At rest, application layer. Clinical notes and the credentials stored for connected services are encrypted by Switchboard with AES-256-GCM before they reach the database, using a key that is not stored in the database. Authenticator secrets are protected the same way. Recovery codes are stored only as SHA-256 hashes, and passwords only as bcrypt hashes.
• Backups. Database backups are encrypted with AES-256 using a passphrase that is not kept on the server alone.
• Keys. Keys and secrets are kept in a permissions-restricted file on the server and never in the source code. They are replaced immediately if exposure is suspected.

5. Servers and network

• A host firewall permits only SSH, HTTP and HTTPS. The database and the application are on a private network inside the server and are not reachable from the internet.
• Administrators sign in to the server with SSH keys only. Password logins are switched off. Repeated failed logins are blocked automatically.
• Operating-system security updates are applied automatically, and the server is restarted promptly when an update requires it.
• The web server adds protective headers to every page: a content security policy, clickjacking protection, a restrictive permissions policy and no-sniff and referrer controls.
• Incoming webhooks from Meta and Acuity are accepted only when their signature verifies.
• Multi-factor authentication is on for the hosting (DigitalOcean) and domain and DNS (Cloudflare) accounts used to manage the service, and is being switched on for the source code, Meta developer and TikTok developer accounts; none of these accounts is shared.

6. Finding and fixing weaknesses

• The software's dependencies are scanned for known vulnerabilities, and the container images are scanned, at least monthly and before each release. The dated results are kept for at least three years.
• The server's configuration (firewall, SSH, updates, encryption, headers, certificates, exposed ports) is checked with a documented routine at least monthly, and after any change to the server. The dated report is kept.
• Findings are fixed on these timelines, counted from when we learn of them: critical within 7 days, high within 30 days, medium within 90 days. If a fix is not possible in time, the Security Officer records the reason and the interim measure.
• We have not yet commissioned an independent penetration test. One will be commissioned before the service is offered to more than a few practices, and then at least yearly.
• Security reports from outside are welcome; see how to report one.

7. Logging and monitoring

The application writes an activity record of sign-ins, failed sign-ins, second-step failures, password and two-step changes, role and account changes, the reading of clinical notes, and every export or erasure of a person's data, with the time, the account and the IP address. Records contain identifiers and counts, not message content. They are kept for as long as the installation exists and can be read by owners and administrators. The web server keeps access logs on a short rotation. The Security Officer reviews failed-login activity and the activity record at least monthly.

8. Changing the software

• Changes are tested with an automated test suite before release.
• Each release is applied by a script that first confirms the server is running exactly the code the release was built on, takes a database backup, builds the new version, loads it in a throwaway container, switches over only if that passes, checks that the application answers, and puts the previous version back automatically if it does not.
• Dependencies are pinned to exact versions in a lock file. New dependencies are added only when needed.

9. Backups and recovery

The database is backed up every night, the backup is encrypted, and 14 days of backups are kept. The restore procedure is written down and is tested at least once a year by restoring a backup into a separate database and checking it. If the server is lost, the service is rebuilt from the stored configuration and the most recent backup. Backups made before a deletion request age out after 14 days.

10. Suppliers

Suppliers that can touch client information are listed on the security page. Before using a new one we check what it will receive, how it protects it and whether it will use it for its own purposes. The list is reviewed at least once a year.

11. People

Anyone with access agrees to keep client information confidential, uses only their own account, uses multi-factor authentication where offered, reports anything suspicious at once, and loses access the same day they stop needing it. Anyone given access to the server or to client information is shown this policy and the incident response plan first.

12. Review and exceptions

The Security Officer reviews this policy at least once a year and after any serious incident, and changes the version and date above when it changes. An exception to any rule needs the Security Officer's written approval, a stated reason and an end date.