Policies & Governance

Effective Date: 6 September 2026 · Version: 2.0

Status. This Policy is the operational companion to the EduSure Privacy and Data Protection Policy and discharges our obligations under section 39 of the Nigeria Data Protection Act 2023 (security and integrity of processing) and section 40 (breach response), as directed by GAID 2025. It supersedes Version 1.0 dated 21 June 2026.

1. Purpose and scope

1. This Policy sets out how EduSure protects, backs up, restores and recovers the data held in its platform, so that a platform fault, a security incident or a data breach does not destroy the record of what parents saved and what schools were paid.

2. It covers the platform database, the paper field forms that feed it, and the third parties whose failure would affect our ability to operate.

2. Current infrastructure, stated honestly

1. EduSure is built and hosted on Base44, a managed platform-as-a-service provider. This Policy is written around what that choice actually permits, so that our commitments are verifiable rather than aspirational.

2.1 What the platform provides

• Managed hosting, database, authentication and file storage, with transport encryption and role-based access control
• Auto-generated API endpoints for every data entity
• Source and frontend code export

2.2 What it does not provide

• Direct database access: no native snapshot or file-system backup EduSure can run independently
• EduSure-controlled storage of the live database outside the provider's infrastructure
• Infrastructure located in Nigeria — hosting is outside the country, which is disclosed as a cross-border transfer in the Privacy Policy

Processor agreements. Every provider that touches personal data — hosting, payments, messaging — must be under a written data processing agreement meeting section 29 of the NDPA before it is used in production. The DPO maintains the register of processors and their agreements, and reviews it quarterly.

3. Data classification and recovery objectives

Recovery point objective (RPO) is how much data we can afford to lose. Recovery time objective (RTO) is how long we can afford to be down.

| Tier | Data | RPO | RTO | Backup | | --- | --- | --- | --- | --- | | 1 | LedgerEntry, Contribution, Disbursement, SchoolInvoice, FundingAllocation, BankTransaction, AccountingPeriod, EduFamily, Scholar, PartnerSchool, Sponsor, consent records | 24 hours | 8 hours | Daily; 12-month rolling; month-end kept 6 years | | 2 | ParentAssessment, SchoolAssessment, CaseFile, AdminTask, FeeSchedule, FieldAgent, StaffMember, BankAccount, ReminderLog | 24 hours | 24 hours | Daily; retained 12 months | | 3 | Testimonial, analytics, technical logs, cached content | 7 days | 72 hours | Weekly; retained 90 days |

1. Tier 1 month-end snapshots are retained for six years to meet the financial record-keeping obligations under CAMA 2020 and Nigerian tax law, and to support any dispute about what a parent saved or what a school was paid.

4. Backup strategy

1. We follow the 3-2-1 principle as far as the platform allows: at least three copies of critical data, on at least two different providers or media, with at least one copy held away from the primary platform.

2. A scheduled export process connects to the platform API using a read-scoped credential and retrieves every record from every entity, writing dated, version-controlled files. Each entity is written to its own file alongside a manifest recording record counts and any errors, so a partial export is visible immediately rather than discovered during a crisis.

3. The entity list in the export script is reconciled monthly against the live data model. Entities added since the last review — the ledger, the assessments, the invoice, case, task, staff and banking tables among them — must appear in the export before that review is signed off. A newly added table silently excluded from backup is the single most likely cause of an unrecoverable loss.

4. Export files hold the same sensitive data as production and are subject to the same controls: restricted access on a need-to-know basis, encryption at rest where the storage provider supports it, and credentials that are scoped, rotated and never shared.

5. Paper records

1. Completed field questionnaires are personal data on paper and are the only copy until they are uploaded. They are kept sealed in the agent's custody, uploaded to the platform within 24 hours of the interview, and held by the supervisor until the record is verified.

2. Once verified against the uploaded record, paper forms are securely destroyed by shredding. Forms awaiting upload are never left in a vehicle or a private home overnight. Loss of a completed form is a reportable data breach and is handled under Section 8.

6. Restore verification

1. An export that has never been tested is not a backup. We commit to:

• Quarterly spot-checks comparing a sample of exported records against live data for completeness and accuracy
• An annual full restore drill, reconstructing a working copy of the core records from export files alone, timed against the RTO in Section 3
• A ledger integrity check in each drill: total credits must equal total debits, and every transaction group must balance
• A client money check in each drill: the savings liability in the ledger must agree with the client bank balances
• Written outcomes for every test, recording gaps found and corrective action taken

7. Deletion requests and backups

The problem we will not pretend away. A person exercising the right to erasure is deleted from the live system, but their data may still exist in backup files taken before the request. We do not claim instant deletion from backups.

1. Where an erasure request is granted, the record is deleted from live systems within 30 days, and the identifier is added to a suppression list.

2. Backup copies containing the record are not restored into production. If a restore is ever performed from a backup predating the request, the suppression list is re-applied immediately after restoration and before the system is returned to use.

3. Backups age out on the rotation in Section 3, at which point the data is gone entirely. We tell requesters this timeline honestly rather than implying immediate erasure everywhere.

8. Breach and incident response

1. Section 40 of the NDPA requires action within 72 hours of becoming aware of a personal data breach. The clock starts at awareness, not at the moment of the incident.

| When | Action | Owner | | --- | --- | --- | | Immediately | Contain: revoke credentials, isolate the affected component, engage the platform provider | Platform lead | | Within 24 hours | Assess: what data, whose data, how many, what harm is likely. Use the most recent verified export as the reference for what existed | DPO | | Within 72 hours | Notify the NDPC with the nature of the breach, categories and approximate numbers affected, likely consequences, and remediation | DPO | | Promptly | Notify affected people where risk to their rights and freedoms is likely, in plain language they can act on | DPO | | As soon as safe | Restore from the most recent verified export where live data was altered, deleted or is no longer trustworthy | Technical lead | | Within 30 days | Root cause analysis and corrective action, recorded in the breach register | DPO with the platform lead |

1. We maintain a breach register recording every incident, including those we assess as not notifiable, with the reasoning for that assessment. If a notification is made later than 72 hours, the reason for the delay is recorded and given to the NDPC in writing.

9. Platform concentration risk and migration triggers

1. Relying on a single managed provider for core data carries concentration risk: an outage, account suspension, billing dispute or provider-side incident could affect our ability to operate regardless of any safeguard we put in place ourselves.

2. The Group will begin planning migration to independently controlled infrastructure on any of the following:

• Combined registered identities exceed 50,000
• Aggregate savings and in-transit contributions held on the platform exceed a level the board considers material
• An institutional funding round, at which point migration becomes a standard condition of investor due diligence
• Any material change to the provider's terms, pricing, ownership or data handling that increases risk to our data
• Any regulatory requirement to hold Nigerian personal data within Nigeria

Migrating before record volumes reach the millions is materially cheaper and lower risk than migrating afterwards.

10. Roles and responsibilities

| Role | Responsibility | | --- | --- | | Data Protection Officer (Gerald Ozimhede Ivhador) | Regulatory notifications, data subject requests, processor register, DPIAs, the breach register, and the decision on whether an incident is notifiable | | Platform / technical lead | Incident containment, credential revocation, provider escalation and corrective action | | Accountant | Bank reconciliation, period close, and confirming that client money in the ledger agrees with the client bank balances | | Field supervisors | Custody, upload within 24 hours, and secure destruction of paper forms | | Founder / Managing Director | Accountability for this Policy, migration decisions, and resourcing |

11. Review

1. This Policy is reviewed at least every six months, and immediately on any material change to hosting, data volume or regulatory requirement. Each review confirms that the export entity list matches the live data model and that the restore drill was completed.

12. Contact

To report a suspected data incident: edusuretech@gmail.com · 08154017624 · marked URGENT — DATA INCIDENT, addressed to the Data Protection Officer.

---

Issued under the Nigeria Data Protection Act 2023 and the General Application and Implementation Directive 2025. Version 2.0, effective 6 September 2026. Supersedes Version 1.0 of 21 June 2026.