Security and data handling
Answers for your CIO, DPO and procurement team
This page summarises OneRubric’s Security and Data Handling document, the standard vendor risk-assessment answers annexed to every contract. Where a guarantee differs by deployment model it is labelled Hosted or Self-hosted.
Hosting options
Two deployment models, one codebase
The multi-tenant isolation layer stays on even in a single-tenant install, so a self-hosted build is identical to the hosted one and security patches apply cleanly.
Managed SaaS, operated by OneRubric
- Each institution is an isolated tenant at <slug>.onerubric.click. The data-access layer injects the tenant predicate on every scoped query; the edge binds each request to its host tenant and re-verifies membership against the live database on every request; suspended tenants are write-blocked.
- Data region pinned at provisioning: NYC3 (US), FRA1 (DE), LON1 (UK), BLR1 (IN) or SGP1 (SG). Never moved without 30 days’ notice.
- Cross-tenant defects found in security review were remediated and are covered by a two-tenant regression suite plus a lint guard forbidding the unscoped database client outside an audited allowlist. We state this rather than claim a stronger guarantee than is tested; a CISO may request the evidence.
- Sub-processors: DigitalOcean (hosting and database), Together.ai (AI, default), Stripe and Paystack (billing), Resend (email), Sentry (error tracking). Each under a DPA no weaker than ours, with a no-training clause. 30 days’ written notice of any change, with a right to object.
Single tenant, on infrastructure you control
- A Next.js application server, a Postgres 14+ database and, optionally, an Ollama server for AI, all on VMs or managed services in your own account or data centre. No shared component across customers.
- OneRubric the company has no sub-processors in this model and no operational access to your data absent an explicit, time-bounded support grant.
- No telemetry, no analytics SDK, no marketing pixels. Outbound traffic in normal operation is limited to OAuth, your SMTP relay and SAML metadata refresh. Error tracking is off by default.
- You control upgrades: we publish the release, your operator applies it. There is no auto-upgrade and no kill switch. Source access and one customer-commissioned audit per contract year are in every contract.
A managed-deployment option runs the self-hosted stack inside your own cloud account with OneRubric operating it. You still own the account, the data and the infrastructure.
Data minimisation
What we store, and what we never store
Stored
- Email address, role and optional display name from your identity provider
- Course metadata: code, name, faculty, programme, campus, level
- Quantitative scores per aspect and anonymous free-text comments
- Action plans, expectations, pulses, disputes and investigation records
- Audit events, notifications and admin-to-faculty message threads
- Institution configuration and branding
Retention defaults to “until the operator deletes”. Customer-driven retention schedules are supported as a customisation.
Never stored
- Student names beyond what the email address contains
- Matric numbers, national IDs or passport numbers
- Grades, transcripts or any academic-record data
- Demographic details: race, religion, gender, disability, sexuality
- Fee or financial data
- Location, device or browser-fingerprint data; student IP addresses beyond transient proxy logs you control
- Faculty HR data: home address, salary
- Biometric data; third-party cookies
Anonymity contract
Comments link to a course, never to a student
A submission writes the student’s email to the evaluation record only. The review row that holds the comment and rating carries no email column, and aggregation never joins it back to identity. Even a user with full database access cannot trivially attribute a comment to a student through the application data model.
Course aggregates, category breakdowns and comments are withheld below a per-institution anonymity threshold of distinct responses, configurable from admin settings, so one student’s feedback cannot be re-identified in a small class.
The same rule applies to AI processing regardless of provider: the model receives aggregate statistics and an anonymised array of comments; it never receives the identity column. This is enforced at the data-shaping layer and covered by automated tests.
Lecturers get a fair process in return: a comment that breaks the rules can be formally disputed; a head or admin adjudicates; an upheld dispute hides the comment, removes it from the leaderboard and deletes its AI embedding atomically.
AI data flow
Where inference runs, by model
Mistral 7B via Ollama, inside your network
- The digest builder assembles aggregate stats plus anonymised comments and sends them over loopback or private HTTP to your Ollama server. No outbound AI traffic.
- Ollama should sit on a private subnet, never publicly addressable; TLS if it crosses a network boundary.
- Nothing is retained beyond the response shown to the user; no transcripts are saved by default.
Together.ai by default, OpenAI optional
- The same anonymised context block travels over TLS to the contracted inference provider. Student emails and per-student rows never cross the boundary; this is enforced in code and tested.
- Together.ai operates under a DPA with zero-day prompt retention and a contractual prohibition on training. OpenAI is off by default; EU residency can be requested if it is enabled.
- The provider is fixed by deployment configuration and is not switched silently. Token usage is metered per tenant per month.
Sign-in and provisioning
Institutional SSO only. No passwords, by design.
Email-and-password sign-in is not supported. Identity ownership is proven at your identity provider; roles and scopes are enforced at the server boundary.
Google Workspace and Microsoft Entra
Both providers register only when configured. For Entra, the single-tenant directory GUID is required; the multi-tenant authorities (“common”, “organizations”, “consumers”) are rejected on both configuration paths so no other Microsoft 365 organisation can complete sign-in. Google’s email_verified is enforced.
SAML 2.0
Signed assertion and signed response both required. Every validated assertion is recorded once in a database-backed single-use guard that fails closed, bounding replay. 30-second clock-skew tolerance. A cross-tenant domain gate refuses an asserted email that does not belong to the host tenant. RelayState accepts only same-site relative paths. Works with Okta, OneLogin, KeyCloak, ADFS and Shibboleth.
SCIM 2.0 and magic-link invites
Automated provisioning and de-provisioning of users and groups from Okta or Entra; magic-link invitations for everyone else. Offboarded users are blocked at the middleware layer; a demoted user’s session ends on the next token round-trip.
Roles, scopes and server actions
Heads and deans hold scope rows for specific departments or schools. Every scoped query checks them at the server-action or API boundary, not in the UI. Impersonation by an operator is read-only, flagged in the session and written to the audit log with both identities.
Encryption and secrets
- HTTPS only; the platform refuses to start with a plain-HTTP public URL in production. TLS 1.2+ at the proxy, TLS 1.3 recommended, HSTS in the sample proxy config.
- TLS to Postgres and, where it crosses a network boundary, to Ollama.
- Encryption at rest is provided by the storage layer (AES-256 on all managed-Postgres providers; LUKS or equivalent self-hosted).
- SMTP passwords and stored API keys are encrypted with AES-256-GCM before they reach the database, as versioned authenticated blobs so tampering is detected.
- Secrets live in environment variables on the application server; the first operator claims access with a single-use bootstrap token, not a pre-claimed email.
Logging and audit trail
- Every privileged mutation writes an audit event: actor, stable action id, target, action-specific metadata, timestamp.
- Append-only at the application level: there is no UI to edit or delete audit rows. Browsable and filterable by administrators; exportable to CSV.
- Application logs record requests, errors and auth events. They never contain request bodies, row contents, OAuth tokens or secrets.
- Rate limiting on unauthenticated endpoints is cluster-wide, with a per-instance fallback.
Backups and recovery
Standard-contract commitments
Figures are the initial commitments in the standard contract and may be adjusted in an executed Data Processing Agreement.
| Model | Backups | RPO | RTO |
|---|---|---|---|
| Hosted, standard | Daily full snapshots kept 7 days; continuous point-in-time recovery over the trailing 7 days; weekly cross-region copy kept 30 days, same-region residency unless a secondary region is named in the contract | ≤ 15 min | ≤ 4 h |
| Hosted, premium | As standard, plus a hot standby replica in a customer-approved secondary region (priced add-on) | ≤ 15 min | ≤ 1 h |
| Self-hosted | Daily pg_dump with an off-box upload pattern from the runbook; you own frequency, retention and residency, and the quarterly restore drill | 24 h | 8 h |
- Customer-initiated full data export is always free and not tied to contract status: a portable per-tenant JSON dump, per-period ZIPs, per-course PDFs and audit CSV.
- Hosted: tenant data is retained for the contract term plus 90 days after termination for a final export, then purged from the live database and from snapshot lineage as snapshots roll off.
- Incident response: SEV-1 initial response within 4 hours, 24/7; initial notification within 24 hours of a confirmed incident; written summary within 5 business days; post-mortem within 15.
- Critical upstream CVEs are triaged within 48 hours and patched within 5 business days unless a contract specifies tighter.
Compliance posture
What we can show, and what we do not yet hold
Frameworks
- GDPR: OneRubric is the Processor under Article 28; the institution is the Controller. The standard DPA is annexed to every contract. Hosted DSAR handling: acknowledgement within 5 business days, substantive response within 30 calendar days.
- Ghana Data Protection Act 843: data-handling defaults meet the requirements for educational records; a Ghana-specific compliance statement is available for procurement files.
- FERPA-equivalent regimes: self-hosted records never leave the institution; hosted customers are covered under the “school official” exception with the contractual restrictions it requires.
- UK DPA 2018, South Africa POPIA, Nigeria NDPR and Kenya DPA 2019 statements are available. AI use is advisory only and not classified as high-risk under the EU AI Act.
Certifications we do not yet hold
- SOC 2 Type II — we follow the practices but do not currently hold the audit report. On the roadmap, customer-funded.
- ISO 27001 — the same.
- WCAG 2.1 AA — built on accessible primitives and semantic HTML, with no formal audit yet. We commit to fixing any specific issue raised.
Each contract includes source-code access, the right to commission one independent security audit per contract year, written answers from the lead engineer within 5 business days, and termination on 30 days’ notice with a full export.
What we explicitly do not do
- Sell, share or monetise customer data in any form
- Use customer data to train AI models, general or customer-specific
- Allow one tenant to access another tenant’s data
- Embed third-party analytics, marketing pixels or fingerprinting scripts
- Read or copy customer data without explicit, time-bounded support authorisation
- Ship updates that auto-install without operator action
- Use customer logos or names in marketing without written consent
- Retain self-hosted customers’ database backups on our infrastructure
Request the full document
“OneRubric — Security and Data Handling” (v1.0) covers eighteen sections, including the sub-processor register, shared-responsibility matrix, incident severities and change management. We send it ahead of any contract conversation.
Vulnerability reports follow coordinated disclosure; ask for the security contact through the contact page.