What this guide covers
- the difference between encryption at rest and decryption on read
- which student fields are encrypted in the database
- how the backend reads mixed encrypted and legacy rows safely
- what to check before exporting or reviewing sensitive records
Quick answer
Superadjust encrypts sensitive student fields using AES-256-GCM before writing them to the database. The data is only readable after the server validates access and decrypts the requested fields for that user session.
Step 1: Understand what the backend protects
Superadjust encrypts sensitive student fields before writing them to the database. The current backend model uses AES-256-GCM for encryption at rest, with a key derived from the STUDENT_DATA_ENCRYPTION_KEY environment variable. If that key is missing, the backend throws on startup rather than falling back to plain text.
This matters because the database is not meant to be the readable source. The encrypted row is the source of truth, and the API only returns readable values after the server decrypts them when needed.
| Aspect | Implementation | What This Means |
|---|---|---|
| At rest | AES-256-GCM | Industry-standard symmetric encryption for stored data |
| Key handling | Derived from STUDENT_DATA_ENCRYPTION_KEY | Server-side environment variable, never exposed to clients |
| Read path | Decrypted on demand by the server | Data is only readable after access validation |
Step 2: Know which student fields are encrypted
The backend encrypts the private student fields that could expose identity, support needs, or free-text notes if stored in plain text. These values are written encrypted first, then decrypted only when the server needs to return them to the product UI or an export flow.
| Encrypted Field | Why It Matters |
|---|---|
| first_name / last_name | Direct student identity fields. |
| dsm5_category | Diagnosis grouping or needs-profile context when used. |
| area_to_focus | Functional need or barrier statement used in the student profile. |
| adjustment_level | Stored privately even though it appears in controlled product views. |
| notes | Free-text teacher notes can contain sensitive detail. |
| tags | Stored privately because tags can still reveal support context. |
Field coverage: The encryption model covers identity fields, diagnosis context, support notes, and any free-text content that could reveal sensitive student information if the database were accessed directly.
Step 3: Understand how decryption works in practice
When Superadjust reads a student record, the server uses one of two helper paths. It uses decrypt(...) when the controller knows the value is encrypted, and safeDecrypt(...) when the database may still contain a mix of encrypted and legacy plain-text rows.
safeDecrypt(...) matters because it checks whether a value looks like a valid encrypted payload before trying to decrypt it. That lets the backend handle older mixed records without breaking the read path or exposing raw cipher text in normal product use.
Encryption Flow
Database Row
Encrypted at rest
Encrypted Fields
AES-256-GCM protected
Server Decrypts
On approved read
Product View
Or export output
Data is only readable after the server validates access and decrypts the requested fields
For day-to-day use, the practical takeaway is simple: the app shows readable values only after the server has validated access and decrypted the right fields for that request.
Why this matters
Encryption at rest protects the database copy of student information. It reduces the risk of sensitive names, notes, diagnosis context, and support details being readable in storage. The product only becomes readable after the backend confirms access and decrypts the requested fields for that user session.
- Identity fields like first_name and last_name are never stored in plain text.
- Diagnosis and support context (dsm5_category, area_to_focus) remain protected at rest.
- Free-text notes and tags are encrypted to prevent accidental exposure of sensitive detail.
- The server handles mixed encrypted and legacy rows gracefully using safeDecrypt.
Common mistake
Encryption does not mean unreadable everywhere: A common mistake is assuming encryption means the data is unreadable everywhere. It is unreadable at rest in the database, but the server still decrypts approved fields on read so teachers, coordinators, exports, and profile views can work normally.
What to do next
After reviewing encryption, the next useful guide is usually Who can see student records or Export history and re-downloads. Those guides explain who can access decrypted records and how generated files are stored and served later.
Next guide
Exporting your data →
Download your evidence records at any time.