Security

Last updated: August 23, 2026

Our security practices

Encryption

• In transit: TLS on every connection, between you and us and between our own services.
• At rest: the database and file storage holding student work are encrypted at rest by our infrastructure provider.
• On our devices: full-disk encryption is mandatory on every machine used for company work, and removable media is prohibited for company and student data.

Where your data lives

Student coursework, names, and grades are stored in the United States (AWS us-east-1, via our database provider). Our application backend and transactional email also run in the US.

One exception worth naming: one of our AI transcription providers currently serves from a global endpoint rather than a US-pinned region. We are tracking that and will pin the region as soon as the provider offers it. Every processor, what it receives, and where it operates is listed in our Privacy Policy.

Access control

• Named individual accounts only: no shared logins on any system.
• Multi-factor authentication is required on our administrative consoles. Within the application, administrative endpoints require a second factor from any administrator who has enrolled one, and deny access if enrollment cannot be verified. Enrollment is not yet mandatory for every administrator, so an administrator without an enrolled factor is presently admitted with one factor. We state this plainly rather than claim a control we have not finished; it is being completed and this page will change when it is.
• Least privilege, with production access limited to those whose role requires it. Grants require documented approval from someone other than the requester.
• Access is reviewed monthly against a register of who holds what, and every grant and change is recorded.

Application security

• Per-record authorization. Every request is checked against what that specific user is entitled to see: you can reach only submissions, exams, and courses you own or are an instructor-member of.
• Tenant isolation is regression-testedin continuous integration, so a change that would let one course see another’s data fails the build.
• Row-level security in the database, plus security headers including HSTS and framing restrictions on every response.
• Rate limiting on authentication and abuse-prone endpoints.
• Secrets are never committed to source control: they live in the platform’s encrypted environment configuration.

AI processing

• Grading sends page images and text to our AI model providers — xAI, Google, OpenAI, and Meta (listed with what each receives in the Privacy Policy). Our agreements with OpenAI and Google prohibit training on your data. We have not executed a data processing addendum with xAI or Meta, so we make no such representation for content sent to them — Section 3 of the Privacy Policy states plainly what that means.
• Requests are configured so prompts and outputs are not retainedfor the provider’s default retention window where the provider offers that control. It is not available to us on every provider we use; the Privacy Policy names where it is not.
• An instructor approves every grade. AI output is a draft; nothing reaches a student until a human has decided it should.

Change management

Production deploys only from our main branch, which is protected: every change requires a pull request, an approving review from another person, and passing automated checks: type checking, linting, build, backend linting, and database migrations applied against a clean database. Every production version traces back to a reviewed change.

Dependencies are monitored automatically for known vulnerabilities, with fixes raised as pull requests.

Monitoring and logging

• Authorization failures are logged as structured events for anomaly review.
• An audit log records authenticated actions on records. Stated precisely: a signed-in user can read their ownentries (not anyone else’s), and because the browser appends some diagnostic entries directly, an account holder can also add entries to their own log. It is an operational record, not a tamper-proof forensic log, and we describe it that way rather than overstate it.
• Error monitoring excludes personal data by configuration, and session replays are fully masked: no student text, inputs, or media are captured.

Backups and recovery

The database is backed up daily by our infrastructure provider with roughly a week of retention, and we maintain a documented restore procedure that we have tested against real data. The most recent drill restored a full copy with row counts matching production exactly. The application itself is stateless, so recovery is a redeploy from a reviewed commit.

To be precise about the trade-off: because backups are daily rather than continuous, our worst-case data-loss window is up to 24 hours. Continuous point-in-time recovery is available from our provider and we will enable it when scale or a customer requirement calls for it.

Incident response

We maintain a written incident response plan covering detection, containment, eradication, notification, and post-incident review. If an incident affects student or personal data, we notify affected institutions without undue delay, targeting 72 hours, with known scope and remediation. Incidents receive a documented root-cause analysis.

Data retention and deletion

Deleting a course, exam, or submission removes it from your workspace immediately and it is permanently destroyed (records and stored files) after a recovery window. Deleting an account begins a 30-day reversible grace period, after which everything is destroyed except limited billing records kept in de-identified form. Details are in the Privacy Policy.

Compliance and documentation

Available to institutions on request:

• FERPA data processing addendum: we act as a school official under your direction; students are not parties and do not hold accounts.
• HECVAT: completed higher-education vendor assessment.
• VPAT / accessibility conformance report: see also our accessibility statement.
• Subprocessor list: published in the Privacy Policy and kept current.

Reporting a vulnerability

Email security@ravengrader.com with:

• a description of the issue and its potential impact;
• steps to reproduce (proof-of-concept if possible);
• the affected URL, endpoint, or component.

Please do not open a public GitHub issue for a security problem, and please do not access, modify, or exfiltrate data beyond the minimum needed to demonstrate the issue.

If a report involves student coursework or personal data, tell us immediately and stop testing. Describe what you saw rather than retrieving more of it.

Our commitment to you

• We acknowledge reports within 2 business days.
• We provide a remediation timeline after triage, and keep you updated.
• We will not pursue legal action against good-faith research that follows this policy, meaning no privacy violations, no data destruction, and no service degradation.
• We credit reporters who wish to be acknowledged, once a fix has shipped.

Scope

In scope:

• ravengrader.com and its application and API
• The RavenGrader Canvas LTI integration

Out of scope:

• Third-party services we use: please report those to the vendor directly
• Social engineering of our staff, customers, or students
• Physical attacks
• Denial-of-service and volumetric testing. We serve live courses; an outage during an exam window affects real students.

A note on student data

RavenGrader processes coursework on behalf of educators and institutions, and that data is protected under FERPA. Please structure your testing to avoid it: use your own account and your own uploaded material wherever possible.

Research that deliberately accesses another user’s student records falls outside the safe harbor above. If you encounter such data incidentally, the right move is to stop, tell us, and delete anything you retrieved.

Supported versions

RavenGrader is a continuously deployed SaaS application. Only the current production deployment is supported.

Machine-readable policy

Our contact details are published as /.well-known/security.txt in the format defined by RFC 9116.

Contact

RavenGrader, Inc.
Security: security@ravengrader.com