Privacy Policy
Effective: August 25, 2026
This policy explains what RosterSafe collects, why, who we share it with, and how long we keep it. It describes the system as actually built. If you find something here that does not match what the product does, tell us at [email protected] and we will correct the policy or the product.
Two different kinds of people are described here
Customers are the firms and their staff who log in and use RosterSafe. Providers are the clinicians whose credentials a customer tracks. Providers do not have accounts and usually never interact with us. Almost everything sensitive in RosterSafe is provider data that a customer entered, and the customer decides what to put in.
For provider data, the customer is the controller and RosterSafe is the processor. We hold and process it on the customer's instructions. If you are a provider and want to know what a particular firm holds about you, ask that firm. We will help them answer, but we cannot answer for them, and we will not hand a firm's data to someone who is not that firm.
1. What we collect
Account data (about customers)
- Name and email address.
- A password hash, or a Google account identifier if you sign in with Google. We never store your password itself.
- Your role (owner, credentialer, or read-only client) and which firm you belong to.
- If you enable two-factor authentication, an encrypted 2FA secret.
Session data (about customers)
- A session record for each active login, including the IP address and browser user agent that created it, the time it was created, and whether it has been revoked.
- We store these so you can see and revoke your own active sessions, and so an unrecognized login is visible to you. They are deleted when the session is deleted.
Provider data (about clinicians, entered by customers)
This is the substance of the product. Depending on what a customer chooses to enter, a provider record can include:
- Name, credential suffix, NPI number, date of birth, email address, phone number, taxonomy and specialty.
- Social Security Number, if the customer enters one.
- DEA registration number, if the customer enters one.
- License, certification, malpractice and CAQH dates and identifiers.
- Payer enrollment records, application status, and effective dates.
- Documents the customer uploads, such as license copies and certificates.
- Exclusion screening results against public sanction lists.
SSNs, DEA numbers and 2FA secrets are encrypted at the application layer with AES-256-GCM before they reach the database. They are excluded from API responses, logs, and exports by default. A specific reveal action is the only way to read one, and every reveal writes an audit event recording who did it and when.
Billing data
Payments are processed by Paddle, which acts as Merchant of Record. Paddle collects and holds your card details. We never see or store a card number. We store your subscription status, plan, billed provider quantity, and Paddle's identifiers for your customer and subscription.
Usage and technical data
- Server logs, including request paths, timestamps, and error traces. Encrypted fields are excluded from logs.
- An activity trail of significant actions taken inside your firm, which is a product feature and is visible to you.
- On the public marketing site only, Microsoft Clarity records page views, clicks, scrolling and mouse movement, and replays them as session recordings and heatmaps. Form inputs are masked, so what you type is not captured. It is not loaded in the application, so no screen holding provider or credential data is ever recorded. The Cookie Policy names every cookie it sets.
2. Why we process it, and on what basis
| Purpose | Data | Lawful basis (UK/EU GDPR) |
|---|---|---|
| Providing the service | Account, provider, document data | Performance of a contract |
| Sending deadline alerts and digests | Account email, provider deadlines | Performance of a contract |
| Taking payment | Billing data | Performance of a contract |
| Keeping accounts secure | Session IP, user agent, audit events | Legitimate interests (security) |
| Exclusion screening | Provider name, NPI | Performance of a contract |
| Newsletter, if you subscribe | Email address | Consent, withdrawable at any time |
| Understanding how the marketing site is used | Public-site page views, clicks, and mouse movement | Legitimate interests (improving how the site explains the product) |
| Meeting legal obligations | Billing records | Legal obligation |
For provider data specifically, the lawful basis is the customer's to determine, not ours. We process it on their documented instructions.
3. Who we share it with
We do not sell personal data, and we do not share it for advertising. We block the request Microsoft Clarity would otherwise make to Microsoft's cross-site advertising identity graph, so nothing we measure is linked into it. We use the following processors, each doing one job:
| Provider | What they do | What they receive |
|---|---|---|
| Supabase (Postgres) | Primary database | All stored data, with encrypted fields still encrypted |
| Cloudflare R2 | Document vault and encrypted backups | Uploaded documents, encrypted database backups |
| Render | API hosting | Data in transit and in memory during processing |
| Cloudflare Pages | Website hosting | Request metadata for the public site |
| Paddle | Payments, as Merchant of Record | Billing contact and card details, which we never see |
| Resend | Transactional and alert email | Recipient email address and message content |
| Sign in with Google, if you use it | Authentication only | |
| Microsoft (Clarity) | Analytics and session replay, on the marketing site only | Public-site interactions, IP address, browser and device details. Nothing from the application. |
We use three public government sources to fill in and screen provider records. They do not work the same way, and the difference matters:
- NPPES NPI Registry. This is the only one we send anything to. When you look up a provider, we send that NPI number or name to the registry, which is public data published by CMS. The request comes from our servers, so the registry sees RosterSafe asking, not you, and we send it no account details.
- OIG List of Excluded Individuals and Entities and SAM.gov. We download the full published list on a schedule and keep our own copy. Screening then runs against that copy, inside RosterSafe. Nothing about your providers is sent to either source.
We may disclose data if required by law, and we would tell you unless legally prevented. If RosterSafe is ever sold or merged, data may transfer as part of that, and this policy travels with it.
4. Where data is held
RosterSafe is operated from the United Kingdom and its infrastructure is primarily in the United States. If you are in the UK or EEA, your data is transferred to the United States under the Standard Contractual Clauses incorporated into our processors' terms.
5. How long we keep it
- Account and firm data: for as long as the account is open. After you delete your firm, data is removed from live systems promptly.
- Backups: an encrypted backup is taken nightly. Every night's copy is kept for a week, and one copy a week is kept for a month, after which it is destroyed. Deleted data can persist in a backup until that backup ages out.
- Sessions: a revoked or expired session stops working straight away. The record itself is deleted 30 days later, so we can still answer "why was I signed out".
- Billing records: kept for as long as tax and accounting law requires, typically six years.
- Newsletter subscriptions: until you unsubscribe.
6. Your rights
Depending on where you live, you may have the right to access, correct, delete, restrict, object to, or port your personal data, and to complain to a regulator. In the UK that is the Information Commissioner's Office.
Exercise any of these by emailing [email protected]. We will respond within 30 days. If your request concerns provider data held by a customer firm, we will pass it to that firm, because they control it.
7. HIPAA, stated honestly
RosterSafe holds credentialing data about clinicians. That is provider information, not patient health information. Whether this makes RosterSafe a HIPAA business associate is not settled, and we are not going to claim a status we have not established. We do not currently sign Business Associate Agreements. If your compliance program requires one, talk to us before you sign up rather than after, and we will tell you plainly where we are.
Do not upload patient health information to RosterSafe. The product has no use for it and it does not belong here.
8. Children
RosterSafe is a business tool and is not directed at anyone under 18. We do not knowingly collect data from children.
9. Changes to this policy
If we make a material change we will update the effective date above and notify account owners by email before it takes effect. Changes to what we collect are made in the policy at the same time as they are made in the product, not afterwards.
10. Contact
Email [email protected] for any privacy question, including data requests. See also our security practices, the Cookie Policy, and the Terms of Service.