Back to homeSajama Campus

Security & Data Protection

How we protect your school's data

Last changed: 28 September 2026

Sajama Campus uses role-based access, school-scoped APIs and database policies to protect school records. These controls require correct deployment and ongoing review; this page is not a security or legal certification.

Encryption

  • In transit: Production connections should use HTTPS for pages, API calls and uploads. Hosting and proxy configuration must preserve it.
  • At rest: Production database storage relies on the managed provider’s encryption controls. Backups and exported files require appropriate protection too.
  • Passwords: Production sign-in uses Supabase Auth. Invitation and reset tokens are hashed before storage; invitation emails do not contain account passwords.
  • Sensitive fields: Access is controlled by role and school. Not every record field has separate application-level encryption.

Authentication & Access Control

  • Multi-layer auth: JWT validated against Supabase (not trusted from cookies alone). Role checked from database on every request.
  • Role-based access: Five roles (platform operator, school admin, teacher, student and parent) have different permissions. Users can only see data their role permits.
  • School isolation: School administrators are scoped to their own school; students and parents are scoped to their own or linked records. Authorized platform operators can review multiple schools.
  • Invite-based accounts: Teachers and students receive cryptographically secure invite links (bcrypt-hashed, 24-hour expiry) to set their own passwords.
  • Rate limiting: Login, password reset, and OTP endpoints are rate-limited (IP + account level) with escalating lockouts to prevent brute-force attacks.

Infrastructure

  • Hosting: Production records are hosted through Supabase. A provider’s certifications do not certify this application or a school’s practices.
  • Row Level Security: Policies constrain direct client access. Privileged server queries bypass RLS, so server routes separately check identity, role and school scope.
  • Security headers: CSP, HSTS, X-Frame-Options, X-Content-Type-Options, and more, all set on every response.
  • No caching of personal data: All portal pages set Cache-Control: no-store to prevent data leaking through shared browsers or proxies.

Payment Security

  • PCI DSS Level 1: All payments processed by Paystack. Sajama Campus never touches card numbers.
  • Webhook verification: Paystack webhooks verified with HMAC-SHA512 and timing-safe comparison.
  • Idempotent fulfillment: Payment effects applied exactly once, even if webhooks and verify callbacks both fire.
  • Server-side pricing: Prices are fixed in server code. Clients cannot modify amounts.

Monitoring & Audit

  • Audit logs: Recorded operations include action, actor and timestamp where available. The console displays stored events, not an assumed complete history.
  • Login tracking: Authentication events may include IP and user-agent information for security investigations, separate from optional aggregate analytics.
  • Request logging: Application/security logs support investigation. Recorded database probes show sampled reachability, not an independent uptime SLA.

Compliance

  • Ghana Data Protection Act, 2012 (Act 843): Schools and Sajama must establish lawful processing, appropriate notices and applicable registration/documentation. Review records are evidence tracking, not a declaration that every legal obligation is satisfied. See our Privacy Policy.
  • PCI DSS: Payment processing delegated to Paystack (PCI DSS Level 1). We never store card data.
  • Data retention: Optional aggregate analytics and health samples have a 90-day retention policy enforced by the configured cleanup job. School and financial records follow separate retention obligations.

Report a Security Issue

If you discover a security vulnerability, please report it responsibly to security@sajamacampus.com. We take all reports seriously and will respond within 48 hours.