Security and privacy

For college IT and security reviewers · Last updated November 9, 2026

This page says what Precept actually does with your program's data, based on how it's built and set up today. It also says what Precept doesn't have yet, so you don't have to dig for it. If you need a questionnaire filled in or a data privacy agreement signed, email aaron@hedgeslabs.com.

Short version: Precept holds education records, not medical records. It runs on Supabase and Vercel in the United States, encrypts data in transit and at rest, walls each program off in the database, never sees card numbers, and lets the director export or delete everything at any time.

At a glance

Where it runs

Precept doesn't run its own servers. It's built on providers that publish their own security reports, which you can request from them:

These certifications belong to the providers, not to Precept. Precept itself has no SOC 2 or ISO certification.

Encryption

• In transit: every page and every database call uses HTTPS. The site sends Strict-Transport-Security for two years, including subdomains, so browsers refuse plain HTTP.
• At rest: Supabase encrypts the database and stored files with AES-256.
• Passwords: stored by Supabase Auth as one-way hashes (bcrypt). Precept never sees or stores a password in plain text.
• API keys: only a SHA-256 hash is stored. The key is shown once, when the director makes it.

Sign-in and who can see what

• Accounts: email and password (8 characters minimum), through Supabase Auth. Google or Microsoft sign-in can be turned on for a college that wants it.
• Joining a program: people join only with an invite from the program or a class code the director makes. The director approves join requests and can turn sign-ups off.
• Roles: director, faculty and staff see their own program. A student sees only their own shifts, progress, documents and bookings. A preceptor sees only shifts sent to them to sign.
• Enforced in the database: every one of Precept's tables has Postgres row level security turned on, so these rules hold even if someone calls the database directly. Tables with no access rules can't be read by users at all. Actions that need extra checks (joining, booking, signing, deleting) run as database functions that check the caller first.
• Documents: uploaded files (compliance documents, site agreements) go to a private storage bucket with one folder per program. PDF and image files only, 10 MB each. Files open through signed links that expire after 5 minutes.
• Sessions: short-lived sign-in tokens that renew while the person is using Precept. Signing out ends the session on that device.
• API access: optional. A director can make a key for the college's own systems. Keys are read-only unless the director chooses read-and-write, work for one program only, never see sign-ins, documents or billing, and can be turned off at any time.

How the website is protected

• A strict Content Security Policy limits which sites the pages can load code from or send data to (Supabase, Stripe checkout, FormSubmit, Google Fonts, and one QR code library from cdnjs). The Supabase library is served from Precept itself.
• Pages can't be framed by other sites (X-Frame-Options DENY), and the camera and microphone are turned off for the whole site.
• Signed-in pages are marked noindex, so search engines don't list them.
• No ad trackers, no third-party analytics, and no cookies from other companies. Visits to the home page, demo and sign-up page are counted with a random ID and no name, email or IP address.
• The open demo keeps everything in the visitor's own browser. Nothing typed in the demo is sent anywhere.

Patient information

Precept is for education records, not medical records, and isn't built to hold protected health information. The Terms forbid entering anything that identifies a patient.

• Patient contact reports use pick lists for age range, sex, setting, acuity, complaint and vitals. There are no fields for name, date of birth, address, phone, record number or call time.
• Free text is checked before it saves. The narrative, impression, medications and nature of illness are screened for dates of birth or full dates, names after titles, phone numbers, street addresses, record or Social Security numbers, emails and ages over 89. If any are found, the report won't save until they're removed.
• Exports show month and year only, never exact shift dates or signing dates.
• The student patient log never leaves the student's device. It's kept in the browser on the student's own phone or computer, is never sent to Precept or the program, asks for no identifiers, and stays until the student deletes it or clears the browser's site data. Only what a student later puts into a report and sends is saved, and that goes through the same checks.
• Clock-in location: if the student allows it, the phone works out how far it is from the clinical site. Only that distance is saved, not the phone's coordinates.

FERPA and student records

Student records belong to the program. Precept handles them as a school official under the program's direct control (34 CFR 99.31(a)(1)): only for the program's purposes, never sold, never used for ads, never used to train AI models, and never shared except with the providers above to run the service. Students who want to see or correct their records go through their program. I'll sign a college's data privacy agreement on request.

Keeping, exporting and deleting data

• Export: the director can download all of the program's data as a file from the Account page at any time. Reports also export to CSV, or print to PDF, inside the app.
• Delete: the director can delete the program from the Account page. That removes its records, roster, shifts, sign-offs, tests, invites, bookings, API keys and uploaded documents right away. It can't be undone.
• Sign-in accounts (a person's name and email) are separate from program records. Anyone can ask me to delete theirs.
• Retention: data is kept while the account is open. Billing records stay at Stripe as long as tax law requires.
• Backups: daily database backups, kept 7 days, are in place before any program's real students are entered.

If something goes wrong

• If I learn of a breach that affects your program's data, I'll tell the program director within 72 hours, with what happened and what was affected.
• Found a security problem? Email aaron@hedgeslabs.com. I'll answer within one business day and won't take action against good-faith reports.
• Only I have administrator access to the hosting, database and payment accounts.

More detail: Privacy Policy · Terms · Accessibility · API. To pass this along, download it as a PDF. Online at precept.squidskull.com/security.