Security

Bank-Grade Security for
Your School's Data

Every student record, every financial transaction, every result is protected by enterprise-grade security built into the foundation of Idora. Not bolted on. Built in.

AES-256 Encryption
Row-Level Security
Immutable Audit Logs
SOC 2 Infrastructure

Security Overview

Idora is built on a security-first architecture. We don't treat security as a feature to add later — it's embedded in every layer of the platform, from the database schema to the API layer to the user interface.

Our security model is designed around three core principles:

Isolation
Every school's data is cryptographically separated at the database level.
Integrity
Double-entry accounting and database triggers make it mathematically impossible for data to be inconsistent.
Accountability
Every action is logged in an immutable audit trail with timestamps and user IDs.

Data Isolation (Row-Level Security)

Idora uses PostgreSQL Row-Level Security (RLS) to ensure that each school's data is completely isolated from every other school on the platform.

This means that even if someone gains access to our database, they cannot read your school's data without the proper authentication and authorization. RLS policies are enforced at the database engine level — they cannot be bypassed by application code.

How it works:
  1. 1. Every table in Idora has RLS enabled
  2. 2. Every query is automatically filtered by tenant_id and school_id
  3. 3. Users can only access data for schools where they have an active role
  4. 4. Role-based policies restrict operations (e.g., only accountants can manage payments)
  5. 5. Platform admins require explicit elevation to access any school's data
60+ tables protected by RLS policies. Every single table in the Idora database enforces data isolation at the engine level.

Encryption

In Transit
All data transmitted between your browser and our servers is encrypted using TLS 1.3. This includes all API calls, authentication tokens, and file uploads.
At Rest
All data stored in our database is encrypted using AES-256 encryption. This is managed by our infrastructure provider (Supabase on AWS).
API Keys
All API keys and secrets are encrypted and never stored in plain text. They are injected at runtime via environment variables.
Payment Data
Full credit card numbers are never stored on our servers. Payment processing is handled by Paystack (PCI DSS Level 1 compliant).

Double-Entry Accounting

Idora implements true double-entry accounting at the database level. Every financial transaction creates balanced debit and credit entries in the ledger.

This isn't just a UI feature — it's enforced by database triggers and constraints:

  • Transaction balance enforcement: The database will reject any transaction where debits don't equal credits. It's mathematically impossible for your books to be unbalanced.
  • Automatic ledger updates: When a payment is recorded, database triggers automatically create the corresponding ledger entries and update the invoice balance.
  • Void and reversal: Transactions can't be deleted. They can only be voided, which creates a reversal transaction that maintains ledger balance.
Why this matters: Your financial records are mathematically guaranteed to be accurate. No more reconciliation nightmares. No more "the books don't add up."

Immutable Audit Trails

Every action in Idora is logged in an immutable audit trail. This includes:

  • Fee payments and invoice generation
  • Fee waiver approvals and rejections
  • Result entries, modifications, and publications
  • Student enrollment changes
  • Staff role assignments
  • Account and permission changes

Each audit log entry includes:

Timestamp
Exact date and time (UTC)
User ID
Who performed the action
Action Type
What was done (create, update, delete)
Table & Record
Which data was affected
Old Values
Previous state (for updates)
New Values
New state (for updates)
Immutable means immutable: Audit log entries cannot be modified or deleted by any user, including platform administrators. This ensures complete accountability.

Access Control

Idora uses role-based access control (RBAC) to ensure users can only access features and data appropriate to their role:

Tenant Admin
Full access to all schools under their tenant
Principal
School-wide access: academics, staff, results, reports
Accountant
Financial management: invoices, payments, ledger, waivers
Teacher
Assigned classes only: attendance, score entry, student view
Exam Officer
Results management: sessions, templates, PIN generation
HR
Staff management: profiles, leave, departments
Cashier
Payment recording and receipt generation only
Guardian
Own children's data: results, attendance, fees

Multi-factor authentication (MFA) is available for all admin-level accounts. Session timeouts automatically log out inactive users.

Infrastructure

Idora runs on enterprise-grade infrastructure:

Supabase
Service: Database, Auth, Realtime, Storage
Location: AWS eu-central-1 (Frankfurt, Germany)
Compliance: SOC 2 Type II
AWS
Service: Serverless Functions & Object Storage
Location: AWS us-east-2 (Ohio, USA)
Compliance: ISO 27001, SOC 1/2/3
Paystack
Service: Payment Processing
Location: Nigeria
Compliance: PCI DSS Level 1
Automated Backups: Daily automated backups with point-in-time recovery
Geographic Redundancy: Data replicated across multiple availability zones
DDoS Protection: Infrastructure-level DDoS mitigation
Monitoring: 24/7 infrastructure monitoring with automated alerting

Vulnerability Reporting

We take security vulnerabilities seriously. If you discover a security issue in Idora, please report it responsibly:

  • Email: security@idora.ng
  • Include a detailed description of the vulnerability
  • Include steps to reproduce (if possible)
  • Do not publicly disclose the vulnerability until we've had time to address it
Responsible Disclosure: We ask that you give us a reasonable time (30 days) to investigate and fix the issue before any public disclosure. We will acknowledge your report within 5 business days.

Compliance

Idora is designed to comply with:

NDPA 2023
Nigeria Data Protection Act 2023 — the primary data protection law in Nigeria
NDPR
Nigeria Data Protection Regulation — implementing framework for data protection
GDPR Principles
We follow GDPR principles (data minimization, purpose limitation, accountability) as best practices
PCI DSS
Payment card data is handled by Paystack (PCI DSS Level 1). We never store card numbers

Contact

If you have questions about Idora's security practices:

Security Team:security@idora.ng
Privacy Inquiries:privacy@idora.ng
General Support:support@idora.ng
Physical Address:No 2007, Tsamiyar Zubau, Bachirawa, Kano, Nigeria

See also our Privacy Policy and Terms of Service.