What your IT department will ask

1. What is in it

The people who sign in: name, email address, role. The department's own roster: who is on it, what they do, how they like to work. The schedule itself: who is working which day, on which call lane. Time-off and swap requests, each of which carries a note the person typed. An audit trail of who changed what.

No patient data. Nothing in the database names, identifies or describes a patient, and there is no route that would accept it.

No payment data. A quote can carry a link to a payment processor's own hosted page, and that is the whole of the card path: no card field, no key on the server, nothing stored. The link is restricted to that processor's domains, because a quote page is public to whoever holds its link and an arbitrary URL behind a "Pay by card" button would lend our domain to anywhere at all.

One thing worth saying out loud. Those request notes are typed by staff, and somebody asking for leave sometimes explains why. So a note can contain a member of staff's own health information. That is staff data rather than patient data, and it does not make this a patient records system — but it is real, and it belongs in a review rather than in a surprise.

2. Who can reach it

Every account belongs to one organisation, and every route that reads anything filters by the organisation of the account asking. An id from another customer's install comes back as "not found" rather than "forbidden", because a 403 confirms that the id exists somewhere.

Three roles: owner, scheduler, viewer. Pricing and accounts are the owner's; building and publishing schedules is the scheduler's; a viewer reads.

Some pages answer without a login on purpose, and they are a written list rather than a prefix rule: each person's own page and phone feed, a wall board, a quote, an invitation, and the published price. Each one is reached by a link containing a token nobody can guess, and the list is named explicitly in the code so that a new route cannot join it by accident.

Passwords are stored as scrypt hashes with a per-account salt, never in any readable form. Sessions are bearer tokens sent in a header, not cookies, so there is no cross-site request forgery surface to speak of.

3. In transit and at rest

In transit: HTTPS only. TLS certificates come from Let's Encrypt and renew themselves; plain HTTP redirects. HSTS, a content security policy, X-Content-Type-Options, X-Frame-Options and a referrer policy are set on every response, and no third-party script, font or analytics tag runs on any page.

At rest: not encrypted. The database is a file in a volume on the server, and we do not claim encryption at rest, because it is not there. It is in the last section with everything else that is not true yet.

4. Logs

The request log records method, path, status, duration and a request id. It does not record request bodies, form contents or headers, so passwords and session tokens never reach it. Paths that carry a secret — a reset link, a claim link, somebody's personal link — are redacted before the line is written, because a reset link sitting in a log file is a working reset link.

5. Backups, and proof they work

A snapshot is taken nightly and kept for thirty days. Every night a second job restores the newest snapshot into a scratch container using the real image, and fails loudly unless the restored copy answers its health check and holds real data. A third copy is pulled to a machine outside the server, which re-verifies that each file restores. Backups nobody has ever restored are a claim about files, not a recovery plan.

6. The server

One VPS in Virginia. SSH is key-only — no passwords, no keyboard-interactive — and repeat failures are banned on an escalating schedule. The only service listening is SSH; the web ports are the proxy. Releases are unattended, alert on failure, and every one records which commit is serving, readable over HTTP.

7. What one caller can spend

Request bodies are capped. Schedule builds run one at a time, with a ceiling on how much solver time any one request can buy, and a much lower ceiling in the public sandbox. Nothing an unauthenticated caller can do writes an unbounded number of rows.

8. Getting your data out, or deleted

The whole year comes out as a spreadsheet, and so does your own workbook with the year written into it. Every call list exports to CSV and to a calendar feed. That is the ordinary way to use Rota, not an exit procedure, which is the point: leaving is the same button as Tuesday.

Ask and we will send a copy of everything held for your organisation, or delete it. See the privacy policy for how that is handled and how long it takes.

9. What is not true yet

This section exists because a vendor review finds these anyway, and finding them on a list is a different conversation from finding them in an answer that was written to avoid them.

• No encryption at rest at the application level.
• No MFA, no SSO, no SAML. One password per account.
• One server, one region, no failover. Recovery from a lost host is restore-from-backup. The restore is drilled nightly; the rebuild of the host itself is manual.
• No formal data processing agreement, retention policy or deletion workflow. Data stays until somebody removes it.
• No third-party penetration test.
• No hosted uptime monitor. The check that runs from outside the server runs on a machine that sleeps.
• No BAA. If your own analysis concludes that those free-text request notes make this a HIPAA matter for you, that conversation has to happen before you sign rather than after.
• One person builds and runs it. Which is the real question behind most of the others, so: your data comes out as your own spreadsheet whenever you want it, without asking anybody, and that is the answer that does not depend on us being here.

10. Who to ask

CRBN MOTORSPORTS LLC, trading as SproulTech
10845 Derringer Drive, Orlando, Florida 32829, United States
nate@sproultech.com

A questionnaire is welcome. Anything not answered above gets a written answer, including "no".