PII & encryption at rest

Wisteria stores some personally identifiable information by necessity (you can’t issue a personalised certificate without a name on file). This page lists what PII is held, how it’s protected, and what’s not stored.

What PII Wisteria stores

For every user:

Email — the sign-in identifier
Full name — appears on certificates, in the UI, in emails sent to and about them
Role — super_admin, content_manager, trainer, auditor, learner
Department — for routing courses and content
Password hash — bcrypt; the plaintext password is never stored
Sign-in metadata — last sign-in time, recent IP (kept by Supabase Auth, not directly visible in Wisteria’s UI)
Quiz attempts and scores — learning record per course

For some workflows:

Audio recordings of oral quiz answers — kept for 30 days for dispute resolution, then deleted
Audit log entries — actor identification (name, email snapshot) at the time of any action

What PII Wisteria does NOT store

Phone numbers — not requested, not stored
Home addresses — not requested, not stored
Birth dates — not requested
Government IDs — never
Health information — none, regardless of customer industry
Financial information — none
Anything not necessary for L&D operations

If you have a workflow that requires storing additional PII (e.g. employee ID for HRIS integration), talk to us. We’d treat it as a custom field with explicit consent and encryption.

Encryption in transit

All Wisteria traffic uses HTTPS / TLS 1.2+. This applies to:

Browser → Wisteria
Wisteria → Supabase
Wisteria → Anthropic / OpenAI / Resend
Wisteria → integrated providers (Microsoft Graph, Google API, Lark API)

TLS termination happens at Vercel’s edge, with end-to-end re-encryption to backend services.

Encryption at rest

Wisteria’s primary database is Supabase Postgres, encrypted at rest using AES-256 by Supabase’s infrastructure. This applies to:

Database tables
Database backups
File storage (Supabase Storage)

The encryption keys are managed by Supabase (which uses AWS KMS under the hood). Wisteria doesn’t hold the raw keys.

Application-level encryption for sensitive data

Some data is encrypted a second time at the application level — meaning even if the database were exposed, the data would be unreadable without Wisteria’s runtime decryption key.

Data	Encryption	Why
Integration access tokens (Microsoft, Google, Lark)	AES-256-GCM	High-value credentials; defense-in-depth
AI provider API keys (when BYOK ships)	AES-256-GCM	Same
Webhook signing secrets	AES-256-GCM	Prevents tampering even on accidental log dumps

The application-level encryption key lives in Vercel’s environment variables, never in source control, never in logs. Key rotation is supported (encrypted columns include a key_version field).

Password handling

Storage — bcrypt hash via Supabase Auth (cost factor 10). Plaintext never touches Wisteria’s database.
Reset — Supabase Auth’s standard reset-link flow; links valid for one hour, one-use only.
First sign-in — temporary password is bcrypt-hashed before storage and force-changed on first use.
Migration — when you change your password, the old hash is overwritten; old passwords are not retained.

Audit logging of PII access

Wisteria’s audit log captures who changed PII (e.g. user.role_change, user.delete). It does NOT capture who read PII (no user.read event).

For customers under regulations that require access logging (HIPAA, certain GDPR contexts), this is a gap. We’re considering an opt-in PII-access log for high-sensitivity customers; tell us if it’s blocking.

A few key positions:

Right to know — your users can request a copy of all their data. Email privacy@getwisteria.com to initiate.
Right to delete — supported via the Users page (super_admin only). Permanent deletion cascades quiz history, certificates, assignments. Audit log entries the user authored are preserved with name set to “Unknown.”
Right to portability — quiz history and certificate downloads are available to learners directly. Bulk export of all personal data on request.
Data Processing Agreement — available on request.

Encryption in motion to AI providers

When Wisteria sends data to Anthropic Claude or OpenAI Whisper:

The data is transmitted over HTTPS.
The provider’s stated policy is that API data is not used for training.
The provider may retain the data temporarily for abuse detection (typically 30 days).
The data is decrypted at the provider’s end to be processed.

This is a recognised privacy consideration for any AI-using system. Customers with strict requirements may choose to not use Wisteria’s AI features (manual authoring still works) — but the AI features are the differentiator.

If you have strict no-data-leaves-our-region requirements, talk to us. The current US AI provider story doesn’t fit; we’re tracking regional options as providers expose them.

What “PII minimum” looks like in practice

For a learner-only user, Wisteria’s database stores:

Email
Name
Department
Password hash
Their quiz attempts and scores
Their certificates

That’s it. No phone, no address, no birthdate, no ID. The footprint is small by design.

For a super_admin, the data is the same plus elevated permissions in the database.

Reporting a leak

If you suspect any kind of data exposure or unauthorised access: email security@getwisteria.com. We treat reports as high-priority and respond within one business day.