الأمان

Encryption

• In transit: every connection uses TLS 1.2 or newer with HSTS. There is no unencrypted access.
• At rest: the database, file storage and backups are encrypted by the hosting provider (AES-256).
• The most sensitive health and custody fields (medical conditions, immunization exemptions, court-order notes) are additionally encrypted inside the application, with a key kept apart from the database (the database and its backups hold only the encrypted text). The key is also held by HubiCare's own server functions that need it, such as the accounting sync a program turns on; no person at the hosting provider reads these fields, and no person at HubiCare reads them in the normal course of work. They stay encrypted in backups.
• Card and bank details never reach HubiCare; they go straight to Stripe.

Isolation between programs

Every table in the database enforces row-level security, so a query from a user at one program can only ever return that program's rows. There are no "allow all" rules for any person's access, and this is tested automatically for every role against its own organization and a different one on every change. Only HubiCare's own automatic server jobs (sending notices, preparing exports, billing and integration syncs) work outside these rules, each limited to its task and logged.

Sign-in and access

• Each person has their own login. Owners, site administrators and billing users must use two-step verification (authenticator app), and the system refuses their administrative actions without it.
• Sessions time out after inactivity. A password change signs out other sessions.
• Roles limit what each person sees: front desk staff do not see medical notes meant for the director; families see only their own children.
• The door tablet has no staff login. It is paired to a site with a device cookie and uses short family codes, with a lockout after repeated wrong codes.
• HubiCare's support team can look at a program's records in the app only when the program's owner allows it in Support (HubiCare can ask, with a reason, but cannot let itself in), for at most 4 hours at a time; the owner can end it at any time, and every request, permission and session is logged. Even then, support never sees the protected health and custody details (it can see children's and families' main details, including the yes/no allergy and custody flags, contacts, check-in photos, absences and their notes, consents, enrollment, staff and attendance), and the only changes it can make are importing a roster or past attendance for the program; every change is logged. A small number of named HubiCare engineers can reach the hosting systems to run the service (updates, backups, fixing outages); they do not open program records except to investigate a security incident (limited to what the investigation needs, logged, and the program told promptly) or to answer a legal demand (the program is told first unless the law forbids it). Systems process records automatically to send notices, prepare exports and run AI features the program turned on; no person views them. HubiCare's team reviews crash reports, which are cleaned of contact details. HubiCare's console shows each program's account details and service-health counts (for example how many open alerts), never records. Whatever someone at the program or a family writes in a support ticket is seen by HubiCare support.

Audit log

Every change to records is written to an append-only audit log (past attendance imported from before HubiCare is logged as one entry per file, not per row) with who, when, and the before and after values, chained so that tampering can be detected. Health and incident text is kept out of the log itself. The log is kept for 7 years. Programs see a change history of their own records (who added, changed, removed, viewed or downloaded what, and when; field names, not contents); the full technical log is kept by HubiCare and provided to the program on request, for example for a licensing investigation. Downloads of the change history are themselves logged. A full export of a program's data can be requested only by an owner signed in with two-step verification who has just typed a fresh code; it is stored in a private bucket readable only by that program's owners, for 7 days, then deleted, and every request and download is logged.

Application security

• A strict Content Security Policy with a per-request nonce, frame denial, and the other standard security headers on every response.
• All input is validated on the server. Server actions run as the signed-in user so database rules apply to every write.
• Dependencies are updated regularly and checked for known vulnerabilities in CI.
• Independent review: no outside penetration test has been done yet. One is planned, then yearly; findings will be tracked to closure.

Backups and recovery

The production database is backed up daily with 7 days of history, encrypted, in the same region. We test restoring a backup at least every three months and record the result. Door tablets keep working during an outage and sync when the connection returns.

Breach notification

HubiCare keeps a written Breach Response Plan. If we confirm that personal information was, or is reasonably believed to have been, acquired by an unauthorized person, we tell the affected program immediately on discovery (a first notice within 24 hours) and give a full notice within 72 hours of confirmation, with what the program needs to meet its own duties (for Minnesota public schools, Minn. Stat. 13.055; for businesses, Minn. Stat. 325E.61). Where HubiCare is itself the owner of the data, it notifies affected people in the most expedient time possible and without unreasonable delay, and the nationwide consumer reporting agencies within 48 hours if more than 500 people are affected, as Minn. Stat. 325E.61 requires. Report a security concern to security@hubicare.app.

Reporting a vulnerability

If you find a security problem, email security@hubicare.app. Give us a reasonable time to fix it before telling others, do not access data that is not yours, and we will not take legal action against good-faith research that follows these rules.