Security Schedule (Schedule 2 to the DPA)

1.1 EDULEDGA INNOVATIONS LIMITED (RC 9591803) ("EduLedga") implements the measures below, which are designed to meet section 24(1)(f) and (2) and section 39 NDPA (including pseudonymisation or encryption where appropriate, confidentiality, integrity, availability and resilience, timely restoration, periodic risk assessment, regular testing and updating). Measures may be improved over time without reducing the overall level of protection.

2.1 A designated Data Protection Officer (Ajay Chukuniku Daniel) oversees data protection; the founders are accountable for security. Policies: Data Protection Policy, Data Breach Response Policy, Account & Security Rules, AI Usage Policy, Data Retention & Deletion Policy. Annual review and NDPA compliance audit (Article 10 GAID). DPIAs before high-risk changes (Article 28 GAID).

3.1 All personnel sign confidentiality and IP assignment agreements before access; receive data protection and security training within thirty (30) days of joining and annually; and have access removed on the day they leave.

4.1 Production runs on a Hostinger virtual private server in France, using containerised services (application frontend and backend, PostgreSQL database, Redis cache) behind a reverse proxy that terminates TLS. EduLedga's own AI model is self-hosted within the same infrastructure and is used for all AI Features other than AI drafting of lesson notes and, where enabled, teacher-reviewed comment suggestions. Those two functions call DeepSeek's API over TLS, with the API key held server-side: lesson-note requests carry curriculum content only, and comment-suggestion requests carry only the minimum fields listed in the DPA (clause 12.4). No user identifiers are sent.

4.2 Server access is restricted to named EduLedga engineers using key-based authentication; no shared accounts. Firewall rules expose only the ports required for web traffic.

4.3 Operating system and dependency updates are applied regularly, with critical security patches prioritised.

5.1 In transit: all traffic to eduledga.io and School subdomains is encrypted with TLS (HTTPS), with certificates issued automatically.

5.2 At rest: Integration credentials (for example any future DNEMIS service credential) are stored encrypted and are write-only through the application.

5.3 Passwords are stored using a one-way hashing algorithm; plaintext passwords are never stored or logged.

6.1 Tenant separation: each School's data is logically separated, and application queries are scoped to the School and Campus of the signed-in user.

6.2 Role-based access control: permissions are assigned by Role (base roles, administrative sub-roles and School-defined custom roles), applying least privilege. Parents see only linked children; students see only their own records; bursars do not see medical notes; the full-school export is not available to bursars.

6.3 Authentication: session-based authentication with session expiry; password reset by verified email or phone; multi-factor authentication for administrative roles.

6.4 EduLedga support access: platform administrators may access a School's tenant only to resolve a support request, investigate a security issue or comply with law. Support access uses an impersonation function whose use is recorded. Access is limited to the minimum necessary.

7.1 Audit trail: the Platform records create, update and delete actions on records (who, what, when), viewable by authorised School administrators. Read access (viewing a record) is not currently logged; EduLedga will notify Schools if this changes.

7.2 Application and server logs are retained for twelve (12) months and protected from alteration. Health checks monitor availability.

8.1 Input validation and parameterised database access; protection against cross-site request forgery and common web vulnerabilities; rate limiting on authentication and public forms (including the demo form); dependency monitoring; code changes deployed through an automated pipeline from the main code repository.

8.2 Security testing: periodic vulnerability assessment and a Vulnerability Disclosure Policy for external researchers.

9.1 Sensitive fields restricted by role and excluded from AI Features, analytics snapshots and default exports. The DNEMIS module sends only aggregate figures and only when authorised and instructed. Demo environments contain fictional data only and reset at midnight WAT.

10.1 Card and bank details are entered only on Paystack-hosted payment pages. EduLedga does not receive or store full card numbers, CVV, PINs or OTPs. Payment confirmations are verified server-side with Paystack before records are updated.

11.1 EduLedga takes nightly encrypted backups of the database and uploaded files at 02:00 WAT, stored off-server in the European Union, keeping seven (7) daily and four (4) weekly copies (a maximum of 35 days), with a quarterly restore test. Recovery objectives are set out in the SLA.

12.1 Incidents are handled under the Data Breach Response Policy: immediate internal reporting; containment; assessment; notification of the School within twenty-four (24) hours of awareness; support for the School's 72-hour NDPC notification; reporting to ngCERT within 72 hours of detection where section 21 of the Cybercrimes Act (as amended) applies; and post-incident review. A breach register is maintained (section 40(8) NDPA).

13.1 Sub-processors are bound by written terms with equivalent protections and assessed before engagement (Article 34(3) GAID).

14.1 Secure deletion at the end of retention periods and after termination, as set out in the DPA and the Data Retention & Deletion Policy.

15.1 These measures are reviewed at least annually and after any significant incident or architectural change (section 39(2)(e) to (g) NDPA).