What we store, and who can see it
The strongest security decision in this product is a scope decision: there is nowhere in it to type anything about the people your agency supports. Everything below follows from that.
We hold nothing about the people in your care.
No residents. No patients. No diagnoses, support plans, care plans, service notes, behavior data, medication records, incident reports or ISPs. Not "encrypted", not "access-controlled" — absent. There is no field for it, no import that accepts it and no setting that turns it on.
This is the single most useful thing we can tell you about the risk of using it. The moment a scheduling tool stores information about the people you support, it becomes a healthcare records system, with every obligation that carries — and the breach that matters stops being "somebody learned who works Tuesdays" and becomes something you have to notify people about.
Keeping it to workforce data makes it simple to approve, simple to audit, and genuinely less interesting to anybody who breaks in. A stolen copy of this database tells somebody who works where. That is not nothing, and we protect it — but it is a different category of harm, and you should choose your vendors knowing which category each of them is in.
We also don't track licenses or certifications. You mark somebody as a med aide, a CNA or an LPN; whether their credential is current is yours to know. All the product does is make sure a slot you marked as needing an LPN is filled by somebody you marked as one.
Everything that is in the database.
Not a summary — this is the list. If something is not here, the product does not hold it.
| What | Why it is there |
|---|---|
| Staff | Name, work contact details, the positions they hold, the locations they work, the hours they prefer and the days they are available. This is what makes a schedule possible at all. |
| Locations and positions | Your homes, day programs and offices, and the roles you staff them with. Named by you, in your own words. |
| Shifts and assignments | Who is scheduled where and when, including the recurring patterns those weeks are generated from, and whether a week is a draft or published. |
| Attendance | Call-offs, late arrivals and no-shows, each with the date it happened, who recorded it, and any note they wrote. |
| Time off | Dates somebody is unavailable, so the product refuses to schedule over them. |
| Logins | Email address, a bcrypt hash of the password, the role you gave them, and their current sessions. Never the password itself. |
| Billing state | Your billing email, your invoice history and a Stripe customer reference. Never a card number — those are entered on Stripe's own pages and never reach us. |
The authoritative version of this, with retention periods and every third party involved, is the privacy policy. This page is the plain-English one.
Who can see what, and why the staff boundary holds.
Four roles. Administrators see everything for your agency, schedulers build and change schedules, staff see their own shifts, and the platform owner — us — manages accounts and billing without a route into your schedules or your staff names.
- An unpublished schedule. Drafts are a scheduler's working copy.
- Any colleague's name on a shift — they see a count of who is on with them
- Anyone else's hours, availability or time off
- Attendance records, other than the facts behind their own score
- A supervisor's written note about an incident, or who wrote it
- Any other agency's anything
The staff-facing part of the product is a separate set of endpoints, not a permission check inside the scheduler's ones. Every one of them answers questions about a single person and selects only rows assigned to them.
The distinction matters because of how each shape fails. A role check inside a shared endpoint leaks an entire agency's unpublished week the first time somebody forgets to write it — and a missing check looks like nothing at all in a code review. An endpoint that can only ever select your own rows cannot leak by omission. There is no line to forget.
Agencies are separated the same way: every query is filtered by organization, and the only role permitted to cross that line is the platform owner, whose screens deliberately show no schedules and no staff names.
Passwords, sessions and the office timeout.
- Passwords are stored as bcrypt hashes and never in a readable form. We cannot tell you your password because we do not have it.
- Invitation and reset links are single-use and expire — invitations after seven days, password resets after an hour — and are stored hashed rather than in the clear, so a copy of the database does not hand somebody a set of working links.
- Changing a password ends every existing session for that account. If somebody suspects their login has been used, changing it is the whole remedy.
- Session cookies are HTTP-only and same-site, and marked secure in production, so they are not readable by page scripts and are not sent from another site.
- Office logins time out after 60 minutes of inactivity, with a warning shortly before, and the session is ended on the server rather than just hidden on screen.
The timeout applies to schedulers, administrators and owners — not to staff. That is deliberate. An office computer at a nurses' station is a shared machine showing an entire agency's roster, and 60 minutes is the right answer there. A staff member's phone shows one person's own shifts, and logging them out every hour would mean the person checking whether they work tomorrow at 11pm has to find their password instead. The timeout follows the exposure, not the org chart.
Everything is encrypted in transit over HTTPS. No system is perfectly secure and we will not claim otherwise — if we ever discover a breach affecting your information we will tell you without delay, including what we do not yet know.
Three layers, and a restore we have actually run.
A backup nobody has restored from is a belief, not a backup. All three of these exist today, and the third one has been rehearsed end to end.
- Point-in-time recovery on the database itself, with a seven-day window. This covers the ordinary disaster: a bad deployment, a mistake at our end.
- A nightly export, one file per agency, held on separate infrastructure and kept for up to 90 days. One file per agency rather than one file for everything, so restoring your deleted week does not roll back another agency's legitimate work from the same days — and so a copy of your data can be handed to you without exposing anybody else's.
- A restore procedure that has been run against a real export. The rehearsal found a genuine ordering bug that would have made a restore fail partway through. That is what a drill is for, and it is the reason we describe this as working rather than as configured.
One more thing worth knowing, because it is the failure this kind of system usually has: an automated check compares the backup's table list against the actual database schema, and fails if a table has been added without saying how it belongs to an agency. A new feature therefore cannot quietly leave a table out of your backup — the build stops until somebody decides. A completeness check that only passes because somebody remembered to extend it guards nothing.
If you close your account, ask and we will send you an export first. Deletion reaches the backups as those copies age out.
Everyone else who touches it.
Four, and the privacy policy lists exactly what each one gets. We do not sell your information and we do not share it for advertising.
| Who | What they get |
|---|---|
| Cloudflare | Hosting and delivery of the application and the nightly exports. |
| Neon | The managed Postgres database the product runs on. |
| Stripe | A billing name and email, and payment details entered on Stripe's own pages. Card numbers never reach us. |
| Anthropic | Only when a scheduler types a plain-English request: that sentence, plus the staff names, locations and positions needed to interpret it. Nothing is sent unless somebody types something. |
The last one is the one to think about, so here it is plainly: the model only ever proposes a change. Every change is applied by our own code afterwards, through the same checks as a change made by hand. And there is no per-agency switch to turn it off today — it is on for every account or none. If a hard guarantee rather than a practice is what you need, tell us before you sign up and we will say plainly whether we can offer it yet.
HIPAA, and what we do and don't offer.
We do not currently offer a business associate agreement, and we would rather explain why than let you find out at the end of a procurement.
A BAA covers a vendor that handles protected health information on your behalf. This product is built so that there is none to handle: the inventory above is the whole database, and none of it is about the people you support. Staffing rosters and attendance records are employment information about your workforce.
We are not going to turn that into a compliance claim on your behalf. Whether a workforce-only scheduling system needs a BAA under your policies, your state's rules and your funders' requirements is a question for your own compliance officer, and they should look at the inventory above rather than at a badge on a marketing page. If they need something from us in writing to make that determination, ask — sales@delegynshift.com — and you will get a straight answer, including "not yet" if that is the answer.
What we will not do is add resident data later and quietly become a different kind of vendor. The scope on this page is the product's design, not its current stage.
What we don't claim.
This is a small, new product. Being straight about what that means is worth more than a page of assurances:
- No SOC 2 report. There isn't one.
- No penetration test by a third party yet
- No single sign-on, SAML or SCIM
- No two-factor authentication yet — a real gap, and the honest word for it
- No BAA, for the reasons above
- No 24/7 support line, and no uptime guarantee in the terms
If any of those is a requirement rather than a preference, this is not the right product for your agency yet, and knowing that now is worth more to you than a trial is to us.
What you get instead is a system that holds less, a scope that is a design decision rather than a stage, and answers like this one when you ask.
Try it on next week.
Fourteen days, your real schedule, no card. The worst case is you print one clean schedule and walk away.
Start a free trialQuestions first? sales@delegynshift.com