Defense in depth across encryption, access control, AI boundaries, and audit. Provided for school & district IT and data-privacy reviewers.
Sensitive fields on every record are encrypted at the application layer using AES-256-GCM via OpenSSL — per-field, each with its own initialization vector and authentication tag, implemented in our encryption class and applied through an encryptable trait. Even if the entire database file were exfiltrated, an attacker would obtain ciphertext for every PII field with no realistic path to decryption without the application key. Fields encrypted include student names, email addresses, state/SIS identifiers, phone numbers and addresses, counselor session notes, parent/guardian contact info, sensitive demographic flags (IEP, 504, English-learner, meal program), and private messages. Keys are stored outside the database in environment configuration; database backups, logs, and exports do not contain the key. Key rotation runs as a batched re-encryption job without taking the application offline.
Identifiers are tokenized where the identifier itself could leak (logs, telemetry, support tickets) — internal numeric IDs are logged, never SIS identifiers or names. A single audit-trail funnel records every sensitive operation: actor, target object, action, structured detail, IP, user agent, and timestamp. Audit entries are append-only at the application layer — no edit or delete affordance, and the model layer implements no update/delete for them. Audited events include all authentication events, every counselor-note read, every change to support entries or behavior incidents, every permission change, every export, every AI API call (metadata only, never the prompt body), and every SIS sync. Default retention is seven years, aligning with FERPA record-retention guidance.
Passkey (WebAuthn) authentication is a first-class option — inherently multi-factor and phishing-resistant, with no password to give away. Sessions are JWT-based with a 24-hour expiration ceiling, stored in HttpOnly cookies, invalidated on password change or passkey re-enrollment, with an idle lock screen. Every data access passes through a single permission function that is the source of truth for organizational scope — a counselor at one school cannot reach another school's students even by manipulating URLs or API paths, because the check is at the model layer, not just the route. Role hierarchy (super-admin > admin > counselor > teacher > student/parent) is strictly enforced, and role elevation is itself audit-logged.
AI features maintain a hard separation between identifying student data and the AI service. Where content does not need to be read, it is referenced by an opaque internal identifier so the AI works on routing and structure without ever seeing names or note bodies. Where body content genuinely must flow to the AI for assistance, the user sees an explicit acknowledgment gate first. Every prompt that does flow out passes through a scrubber that replaces names, emails, phone numbers, addresses, and SIS identifiers with placeholder tokens before transmission, re-substituted locally on receipt — so the AI provider's logs do not contain readable student or parent identities. A compliance dashboard surfaces every AI exchange (model, timestamp, token counts, content category, originating user) without prompt bodies, and an organization can wipe its AI metadata at any time.
The login endpoint applies rate limiting with progressive backoff and account lockout on sustained failures, with admin notification; passkey-bound accounts are immune to credential stuffing. Against a stolen database file, the attacker holds AES-256-GCM ciphertext — infeasible to brute-force on any projected hardware roadmap, including state-level quantum investments per current NIST analysis. Encryption keys live in environment configuration, never in the database, version control, or backups; host access requires SSH key authentication with password SSH disabled. Per-session IP capture means a stolen session is detectable on first reuse from a different network.
CateLMS is designed around the FERPA record-keeping model: records scoped to the student's enrolled organization, access restricted to staff with a documented educational interest, every access logged, seven-year default retention. For users under 13 in K-8 deployments, CateLMS collects no data beyond what the district provides through its OneRoster connection; parental consent is the school's responsibility through its data-privacy agreements. We do not advertise to students, do not sell student data, and do not retain student data after a student leaves the organization beyond what FERPA permits.
Containment tools include per-organization session suspension, per-user revocation and lockout, key rotation without downtime, and AI-metadata wipe. In a confirmed incident affecting a customer's data, we commit to direct disclosure within the timeframes required by applicable state law (in Utah, within thirty days of discovery), with a full post-incident report naming root cause, data scope, contained-by time, and remediation. We will not minimize or obfuscate.