Your school's data is precious. Here is exactly how Inter-College protects it — no vague promises, just the controls we've actually built.
JWT-Based, Short-Lived
Every login issues a JWT access token and a refresh token. Access tokens expire in hours, not days, and refresh tokens rotate and are blacklisted once used — a leaked token doesn't stay valid indefinitely.
Nine roles, enforced where it matters most
Every account carries a role, and the portal shows each role only the modules that belong to it. Server-side permission classes back that up on the areas we hardened first — staff and payroll, school settings, tenant administration and billing.
Schema-Per-Tenant Architecture
Inter-College runs on a schema-per-tenant model: each school's students, staff, fees, and records live in their own PostgreSQL schema, not shared rows filtered by an ID column that a query might forget.
Rate Limiting & Validation
The public signup endpoint provisions a real database schema on every call, so it is rate-limited per IP. Requests are validated on every write, and the API only answers the app domains we list.
Beyond the pillars above, here is what else is already in place.
The backend test suite runs against real Postgres and Redis services on every push and pull request. The frontend is type-checked, linted, and built before anything merges.
Django's SecurityMiddleware, CSRF protection, and password validators are on by default. Production forces SSL redirects and secure, HTTP-only cookies.
The public tenant-signup endpoint provisions a real database schema per request, so it's rate-limited per IP to prevent abuse of a genuinely expensive operation.
The API only accepts requests from an explicit allowlist of app domains — not a wildcard — so a random website can't call it on a logged-in user's behalf.
Because each school lives in its own database schema, isolation doesn't depend on every query remembering a school_id filter — the database enforces the boundary.
No two-factor authentication, no audit log of who changed what, no encryption at rest beyond what the host provides, no automated backups on a schedule, and no self-service export or account deletion. All five are real gaps and we would rather name them here.
We're onboarding our first schools right now. Security questions get answered directly by the engineers who built the platform — no ticket queue, no runaround.
We're a pre-launch platform finalizing our production hosting setup. We're happy to walk any prospective school through the current infrastructure and data-residency details directly — just reach out.
Each school's records live in their own PostgreSQL schema, so nothing is stored in a shared table that a missing filter could expose. That is a structural property of the database layout rather than a permission check. We are still hardening the API's per-role checks module by module, and we are happy to walk a technical evaluator through exactly where that work stands before you commit.
Not on an automated schedule inside the product today — that is honest and it is being fixed. Ask us before you go live and we will tell you precisely what backup arrangement is in place for your school at that moment, in writing.
Neither is built. There is no record of which user changed a given record, and accounts are protected by a password alone. If either is a requirement for your board, tell us — it moves up the list.
Your school's data stays yours. Ask us at any time and we'll produce a complete copy of your records; on termination we hand over that copy and delete your school's schema on request. A self-service export you can run yourself from the portal is on the roadmap, not shipped yet.
We're built with data minimization and role-based access as core design choices, and we support exporting or deleting a school's data on request. We haven't pursued formal compliance certification yet — we're happy to discuss your specific requirements directly.
Not yet. We're a pre-launch platform without the customer base to justify a formal audit program today. Independent security review is on our roadmap as we onboard schools — until then, we're glad to walk technical evaluators through the actual codebase and architecture.
We're onboarding our first schools now. Talk to our team directly about your school's specific security and data requirements.