Trust Center

Your Trust is Our
Foundation

Orchedule™ is built with security, privacy, and reliability at its core. Here you'll find a transparent account of how we protect your institution's data, uphold your privacy, and keep the platform dependable.

Security
Privacy
Reliability
Responsible Disclosure
Last reviewed: May 2025  ·  Applies to all Orchedule™ plans
Security

Built Secure from the Ground Up

Security is an architectural requirement, not an add-on. Every component of Orchedule™ is designed to protect institution data against modern threats.

Tenant Isolation
Core Architecture

Every institution that subscribes to Orchedule™ operates in a completely isolated PostgreSQL schema — a separate database namespace that is structurally incapable of sharing rows with any other institution. This is not a row-filter or a permission guard; it is a hard architectural boundary enforced at the database engine level.

Schema-per-tenant
Each institution's tables, indexes, and sequences live in their own PostgreSQL schema, completely separate from all others.
Middleware Enforcement
TenantMainMiddleware sets the active schema on every single request before any view code runs — there is no way to reach another tenant's data by mistake.
Separate Migration History
Schema migrations are applied per-tenant independently, allowing safe, isolated schema evolution without touching other institutions.
Public Schema Boundary
Only shared infrastructure (subscriptions, tenant registry) lives in the public schema. Institution scheduling data never touches it.
Encryption in Transit

All data exchanged between your browser and Orchedule™ is encrypted using TLS 1.2 / TLS 1.3. Plain-text HTTP is rejected in production.

Encryption at Rest

Sensitive fields — including SIS credentials and integration tokens — are encrypted using Fernet symmetric encryption before being stored.

Role-Based Access Control

Two access tiers keep permissions minimal by design. Admin & Registrar users have institution-level access. Basic users are scoped to a single academic unit (Department, Program, or Track) — they cannot see or modify anything outside it.

CSRF & XSS Protection

Django's CSRF middleware protects every state-changing request with a validated token. Django's template engine auto-escapes all output, preventing cross-site scripting by default.

Scanner & Bot Defense

A custom ScannerBlockMiddleware runs at the very front of the middleware stack, dropping automated exploit probes before they reach any application logic.

Controlled CORS Policy

Cross-origin requests are restricted to an explicit allowlist of trusted origins. No wildcard origins are permitted, limiting exposure to cross-site request forgery from unknown domains.

Security Baseline — What Is Active Today
  • Secrets managed via environment variables — never hard-coded or committed to source control
  • Four-layer Django password validation (similarity, minimum length, common passwords, numeric-only)
  • Django SecurityMiddleware and XFrameOptionsMiddleware active (clickjacking protection)
  • CSRF protection on all state-changing requests (CsrfViewMiddleware)
  • Template auto-escaping active on all rendered output (XSS protection by default)
  • Database statement timeout set to 30 seconds — prevents runaway or injection-based query attacks
  • API rate limiting: 100 requests/hour for anonymous, 1,000 requests/hour for authenticated users
  • OAuth 2.0 with scoped tokens (read / write / read-write) for all API integrations
  • CORS restricted to an explicit allowed-origins list — no wildcard
  • Vulnerability scanner blocking at the earliest middleware position
  • django-tenants schema isolation — hard database boundary between every institution
Privacy

Your Data. Your Control.

We collect only what is necessary to run the platform and never sell or share institution data with third parties for commercial purposes.

Data Minimization

We collect only the data required to deliver the service. No behavioral tracking for advertising.

Data Ownership

Your institution owns its data. You can request a full export or deletion at any time.

Retention Policy

Scheduling data is retained while your subscription is active. Post-termination data is purged within 90 days upon request.

Sub-processors

Infrastructure is hosted on Render (cloud PaaS). Email is handled by a dedicated private mail server. No data is sold to third parties.

What We Never Do
  • Never sell your institution's data to third parties
  • Never use data for advertising or behavioral profiling
  • Never store plain-text passwords — all credentials are hashed
  • Never share any data between tenants — architectural isolation guarantees this
Reliability

Always On When You Need It Most

Academic scheduling has hard deadlines. We engineer for the availability and performance your institution can depend on.

All Systems Operational
Web app  ·  API  ·  Database  ·  Email
99.5% Uptime Target
Hosted on Render with auto-restart and health checks
Daily Automated Backups
PostgreSQL backups with point-in-time restore capability
Scheduled Maintenance Windows
Maintenance is announced 48 hours in advance via email
Disaster Recovery
Recovery time objective (RTO) targeted at under 4 hours
Performance Monitoring
Health endpoints polled every minute; auto-recovery on failure
Incident Notifications
Affected tenants notified within 1 hour of a confirmed incident
Responsible Disclosure

Found a Vulnerability? Tell Us.

We welcome responsible security research. If you've discovered a potential security issue in Orchedule™, please report it privately so we can address it before it affects our users.

How to Report

Email your findings to support@orchedule.com with a clear description of the vulnerability, steps to reproduce, and the potential impact. We aim to acknowledge reports within 3 business days.

Please do not publicly disclose the vulnerability until we have had a reasonable opportunity to resolve it (typically 90 days).

Our Response Process
  • Day 1–3: Acknowledge receipt and assign severity classification.
  • Day 4–14: Reproduce, assess, and develop a patch or mitigation plan.
  • Day 15–90: Deploy fix and notify affected institutions if required.
  • Post-fix: Coordinate on public disclosure timing. Reporters of valid issues will be credited if they wish.
Contact

Questions? We're Here.

For security reports, privacy questions, or any trust-related inquiries, reach us directly:

support@orchedule.com