Trust Center

Upmark is a single Next.js application backed by managed PostgreSQL. District accounts authenticate by SSO through the district identity provider — no passwords are stored. A passcode-gated shared demo sandbox exists for evaluation, isolated from district data. Access is authorized at the row level on every request: a student can reach only their own attempt, a teacher only their own classes. That boundary is exhaustively fuzz-tested — every principal / action / resource decision enumerated (27,040 in total), with a pinned allow-count canary — rather than asserted.

• Encryption in transit (HTTPS) and at rest (managed database provider).
• Sessions are encrypted JWTs with a 24-hour lifetime — short by design, because classroom Chromebooks are shared hardware and SSO re-auth is cheap. Cookies are httpOnly, same-site, and secure with the __Secure- prefix in production.
• Role-based access: every server action derives a role-checked principal before doing any work; the AI grading worker is a system-only path reachable solely after an authorized submit.
• Abuse resistance: join codes are drawn from an ~887-million-value space, and a session accepts a join only while it is open. There are two ways to join. Rostered students sign in through the district IdP and their guessing is rate-limited per account (15 attempts / 5 minutes). A code can also be used to join as an ephemeral participant — a display name, no account — whose only credential is a signed, HttpOnly, session-scoped cookie; that anonymous path is rate-limited per source (same 15 / 5 minutes, best-effort by client IP). Neither a valid code nor a held cookie is itself access: every request is still authorized at the row level against the specific session and attempt it names, and a participant is bound to one session by a database foreign key.
• Input handling: answer payloads are shape-allowlisted and length-capped; all student text renders through framework escaping (no raw HTML injection surface); the exam timer is server-authoritative.
• Dependencies are audited at each bump; at the last review the only open advisories were transitive and confined to dev/build tooling, not runtime application code.

Upmark does not itself hold a SOC 2 attestation. We do not claim one. Our infrastructure runs on SOC 2 Type II–compliant providers, listed under Subprocessors below with each provider’s own attestations.

We collect the minimum necessary to run a classroom assessment, and no more.

• Per student we store an email, a first name, and a last name (first + last resolves duplicates), plus the SSO provider and subject id used to sign in. No photos, no demographics, no birthdate.
• Accommodations are not stored as a standing profile. A teacher applies a support (e.g. extended time) to specific students per assessment, captured as an assessment setting rather than a persisted record of why — because accommodation data can imply IEP/504 status and is treated as a sensitive class.
• Operational logs carry no names or emails. The ops log has no user foreign-key columns; a few audit breadcrumbs (for example a large teacher read, or a district export) record an opaque internal user id plus counts, which cannot be resolved to a person without database access. An integration test plants sentinel name and email values through a real grade-and-log path and asserts they never reach the ops log.

These are the third parties that process data on Upmark’s behalf. The compliance posture in each row is that provider’s own attestation, not Upmark’s. We recommend districts confirm current status at each provider’s trust page during review.

Optional and off by default: error monitoring (Sentry) activates only when a district-configured DSN is set; it strips user, cookie, header, and body data, and session replay is never enabled because it would record live exam content.

Upmark operates under FERPA’s “school official” exception: the vendor performs a service the school would otherwise perform, under the direct control of the school as to the use and maintenance of education records, and uses the data only for the contracted purpose with no re-disclosure or repurposing.

“Direct control” is implemented contractually through a Data Processing Agreement per district: the district dictates permitted use, training and monetization on student data are prohibited, and data is returned or destroyed at contract end. The no-training / no-retention-beyond-need stance below is what makes this posture real rather than merely stated.

FERPA has no certification program. We do not claim to be “FERPA certified.” What we offer is the school-official posture above, made contractually binding through a district DPA.

Upmark is built for classroom use directed by a school, and student accounts are provisioned through the district’s identity provider — the mechanism through which a school can provide consent on a parent’s behalf for an educational service.

Where any student is under 13, COPPA applicability is a district-specific question we handle in the DPA rather than assume. Data minimization (no birthdate, no demographics, the smallest workable identity set) keeps the footprint low regardless of a student’s age. [TO CONFIRM: exact COPPA scope is flagged for counsel per district — see the open-items note below.]

Upmark uses AI (the Anthropic Claude API) to grade against a teacher’s rubric and to help generate questions. The handling rules are enforced in code, not just documented:

• No model training on student data. Student PII and responses are never used to train models.
• Pseudonymized requests. Grading inputs carry only attempt-scoped ids — never names, emails, or user ids. This is enforced by construction (the grader’s input types have no user fields) and by an integration test that plants sentinel name, email, and user-id values and asserts they never reach the grader, and that no name or email reaches the ops log.
• Documented retention. Data is retained only as long as needed to deliver the functionality, then handled per the retention schedule below.
• Teacher-in-the-loop by default. The teacher reviews every AI grade before it reaches a student; the AI proposes, the teacher decides.

Integrity signals (for example tab-blur, paste, or fullscreen-exit events during a monitored session) are shown to the teacher as observations, never accusations, and are never an input to grading. On any proctoring surface, the product keeps the same caveat verbatim: “The teacher in the room is still the real control.”

Academic records (grades, attempts, content) are never auto-purged — statutory retention windows are being set with counsel, and records leave the system only through an explicit district deletion request. Operational exhaust is swept by a scheduled daily job, and misconfigured windows fail closed (data is kept):

Export and deletion are operator-run, token-guarded admin operations — there is no self-serve deletion button by design, because removing education records is a district decision. Export returns the complete teacher-owned data tree as JSON. Deletion is a hard delete in foreign-key order inside a single transaction and requires a confirmation email that must match the target user, so a wrong id fails safe instead of destroying the wrong records. Both paths are covered end-to-end by the privacy integration test.

To request a Data Processing Agreement (including national templates such as the NDPA / SDPC exhibit), a completed security questionnaire, or to report a vulnerability, contact the colleague organizing your pilot. They can route the request to the application operator.

Pilot guide & getting help

Open items we resolve per district with counsel: statutory retention windows by state, COPPA scope where students are under 13, the specific DPA template (many districts mandate their own), and any data-residency commitment required of the database host.