Security & Trust

CampusResolve holds some of the most sensitive information a campus handles. Security is a foundational design goal, not an afterthought — the controls below are built into the product, layered so no single one is relied upon. The institution remains the records custodian; CampusResolve is the tool its staff use, hardened to protect that data.

Encryption

• In transit: all traffic is served over TLS, with HTTP Strict Transport Security enforced.
• At rest: sensitive fields are encrypted with AES-256-GCM. Each institution has its own data-encryption key, so tenants are cryptographically separated.
• Key management: the master key is held in a managed key-management service (KMS) and never sits in application configuration. Per-tenant keys enable crypto-shredding — a tenant’s data can be rendered permanently unrecoverable by destroying its key.

Access control & tenant isolation

• Deny-by-default authorization: a fine-grained access engine grants each action only when an explicit, current rule permits it.
• Database-level isolation: PostgreSQL row-level security independently enforces that one institution can never see another’s data — a second layer beneath the application checks.
• Least privilege: the application connects as a restricted database role; administrative access is limited and role-tiered.

Authentication

• Mandatory two-factor authentication (authenticator-based, RFC-6238 TOTP) for staff accounts.
• Institutional single sign-on via OIDC, so institutions can use their own identity provider.
• Session control: server-side sessions can be revoked immediately; refresh-token reuse is detected and terminates the session.
• Public endpoints are rate-limited to resist brute-force and abuse.

Auditability & integrity

Access to case data is recorded in a tamper-evident, hash-chained audit log, so the record of who accessed what cannot be silently altered. The platform can produce a complete, litigation-ready export of a matter with its audit trail intact.

Application hardening

• A strict Content-Security-Policy with per-request script nonces, plus a full set of security response headers.
• Input sanitization and content-integrity checks on user-supplied data.
• Change management through automated CI (type-checking, linting, tests, and a security scan on every change), with dependency and vulnerability scanning.

Availability & recovery

• Automated, encrypted database backups plus point-in-time recovery.
• Uptime monitoring and error tracking, with a documented incident-response and disaster-recovery process.

Governance & compliance

• A set of written security policies (information security, access control, change management, incident response, vendor management, business continuity, risk assessment, and key management).
• Data handling is designed to support institutions’ FERPA obligations; terms are set out in our Data Processing Addendum.
• We are actively pursuing SOC 2. It is in progress and not yet certified — we will update this page as milestones are reached.

Reporting a vulnerability

If you believe you have found a security issue, please email our security contact with the details. We take reports seriously and will respond promptly. Please do not publicly disclose an issue before we have had a chance to address it.

For related detail, see our Privacy Policy and Accessibility statement.