Security and Compliance Overview

This document is for school leaders, IT teams and data-protection reviewers evaluating Plus Up. It describes how the platform is built and operated by Plus Up (licence: to be issued by the Umm Al Quwain Free Trade Zone). Questions: privacy@plusup.net.

Current status

Plus Up is not yet used by any school with real data. The service at https://plusup.net is a demonstration: it holds fictional data only and runs on a temporary server outside the United Arab Emirates, so no real learner, family or staff data may be entered into it. Before the first school uses Plus Up with real data, the service, its database, its file storage and its backups move to a data centre in the United Arab Emirates, and the steps these documents mark as required before real school data is handled are completed. The company's licence details are added to these documents when its trade licence is issued.

1. Summary

• School data is hosted only in the United Arab Emirates: the service in a UAE data centre, with geo-redundant copies of the database backups and stored files at a second UAE location. No school data leaves the country, and none is accepted before this hosting is in place.
• Every school has its own isolated workspace; isolation is enforced by the database, not only by the application.
• Encrypted in transit and at rest; learners' religion, medical details, office notes, behaviour descriptions, messages and family contacts carry a second, field-level layer of encryption.
• Role-based access for eight school roles; a learner's private details open only to leadership, the office, the learner's own teachers and their heads of department; two-step verification; sign-in throttling and lockout; audit log.
• Every uploaded file is type-checked. Files up to 100 MiB are scanned for malware before download; larger staff-uploaded videos are not scanned.
• For real school data: daily database backups kept for 14 days and stored geo-redundantly; previous file versions kept for 20 days and deleted files for a further 14 days. A restore exercise is required before real school data is handled and then every three months.
• No advertising, no analytics trackers, no sale of data. Only essential cookies.
• Aligned with the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021) and the record-keeping expectations of school regulators; a Data Processing Agreement is part of every subscription.

2. Architecture and hosting

• Location. For real school data, the service, its database and file storage run in a data centre in the United Arab Emirates; geo-redundant copies of the database backups and of stored files are kept at a second UAE location. The domain registry is then the only component outside the UAE, and it holds no school data. Today's demonstration runs on a temporary server outside the UAE with fictional data only (see Current status).
• Network. Traffic reaches the service only over HTTPS. The database and the file-scanning service accept connections only from the service's private network, never from the internet.
• Database. A managed PostgreSQL database service with storage encryption, automated daily backups retained for 14 days and stored geo-redundantly, and a separate, less-privileged database role for the application.
• Files. A private object-storage container with encryption at rest, TLS enforced, versioning (previous versions kept 20 days), soft delete (deleted files recoverable for 14 days) and no public access. Downloads use short-lived signed links; nothing is served from the application domain.
• Secrets. Encryption keys, database credentials and integration secrets are kept in a managed key vault and given to the running service, never stored in code or images.
• Releases. The repository includes automated tests and linting, and its deployment workflow is designed to run them before deployment. The deployment gates and an independent security review must be verified before real school data is handled; database changes are applied as part of the release.

3. Tenant isolation

Each school is a tenant. Every table that holds school data carries the school's identifier, and PostgreSQL row-level security policies guarantee that a request can read or write only the rows of the school the signed-in user belongs to. The application adds a second, independent fence by scoping every query to the current school. The application's database role cannot bypass these policies, and the server refuses to start if it is connected with a role that could.

4. Identity and access

• Roles. School administrator, principal, vice principal, head of department, dean of students, teacher, student, guardian. Each page and action is tied to a named permission; the permission matrix is reviewed with every release.
• Learners' private details (date of birth, nationality, religion, category, medical information, office notes, parents' contacts) are open to the principal, vice principal, dean and school administrator for every learner; to a teacher only for the learners they teach (in their courses, their timetabled classes, or a class they cover that day); and to a head of department also for learners in their department's courses. Every opening and every data export is written to the audit log.
• Guardians see only the learners linked to them; a link a parent asks for starts only after the learner accepts and the school office confirms it (a school can switch the office's confirmation off), and the office can remove a link at any time. Students see only themselves. Messages between classmates, and between families of the same class, are off unless the school switches them on; when they are on, other parents of the class see a parent's name as "Parent of" their child and can write to them, and the homeroom teacher, the dean and school leadership can read these conversations. Conversations between staff and a learner can be reviewed by the dean and leadership for safeguarding.
• Passwords are hashed with Argon2id and never logged. Minimum length and complexity are enforced; temporary passwords are shown once and must be changed at first sign-in. A forgotten password is reset through a single-use link sent to the account's email address; the link expires after 30 minutes, only a hash of its token is stored, requests are limited per client address and per account, and every request is audited. Learners who sign in with a username and no email address are reset by the school office from inside the platform, and a reset signs out every session.
• Throttling and lockout. Failed attempts are limited per client address and per account; ten consecutive failures lock the account for fifteen minutes. All of this is audited.
• Two-step verification (TOTP) is available to every user and mandatory for Plus Up platform owners. Repeated wrong codes lock the step for increasing periods, and the account holder is told. Recovery codes are single-use and stored hashed.
• Sessions use opaque 256-bit tokens, are stored hashed, expire after 14 days of inactivity, and can be revoked; a password change signs out every other session; disabled users are rejected on the next request.

5. Data protection

• In transit: TLS 1.2 or later with HTTP Strict Transport Security.
• At rest: database and file storage encrypted by the cloud provider.
• Field-level encryption for learners' religion and sensitive notes (medical, office notes, behaviour details), messages, meeting notes and family contacts' phones and emails, with versioned keys so that keys can be rotated without downtime.
• Minimisation. Schools enter only what they choose; nothing is collected from learners for our purposes.
• Retention. Data stays for the subscription term. Learners who leave are recorded as having left (their sign-in stops; the school record is kept). A complete deletion of a learner's record requires a purpose-built, audited process and legal review before it can be offered. After the subscription or free trial ends: 90 days to download the data or ask for a full export; unless the school renews, its data, including stored files and its audit log, is then deleted automatically from the live systems, and every remaining copy leaves the backups within a further 35 days. The IP address is removed from sign-in audit records after 12 months. The sign-in records themselves are currently kept without a time limit, including after a school's data is deleted; a retention limit is planned before real school data is handled.
• Export. The school's office and leadership download learners and parents' contacts, attendance for any date range and behaviour reports as spreadsheets, each course's gradebook and term grades, and a learner's whole record as a file for access and portability requests. A full export of everything (a ZIP file with every record as CSV files) is provided by Plus Up on request within 30 days, including during the 90 days after the subscription ends.

6. Application security

• Content Security Policy with per-request nonces, strict referrer and frame policies, and no inline scripts.
• Origin checks on every state-changing request; server-side validation of all input; parameterised queries only.
• Every upload is validated by extension, declared type and file signature, size-capped per purpose and hashed. Files up to 100 MiB are scanned by an antivirus engine before they become downloadable; larger staff-uploaded videos are an exception. Files that fail validation or scanning are deleted.
• Rate limits on sensitive endpoints (sign-in, upload intents, administrative APIs).
• Spreadsheet exports neutralise text that a spreadsheet would run as a formula.
• CI checks dependencies for published vulnerabilities; known advisories and their assessment are documented. A regular dependency-update process is planned before launch.
• The repository includes automated unit and integration tests, including tests for tenant isolation and the per-purpose file-access rule. Their required deployment gate must be verified before real school data is handled.

7. Logging, monitoring and incident response

• An audit log inside each school records significant actions (who, what, when), including every opening of a learner's private details and every data export; the school administrator can read it. File downloads are not yet recorded in that audit log.
• Application logs are kept in the UAE with the service, and the service is monitored through its health check.
• An incident-response and breach-notification procedure must be documented, legally reviewed and tested before real school data is handled. Notification deadlines and responsibilities will be confirmed with legal counsel.

8. Business continuity

• Automated daily database backups (14-day retention), stored geo-redundantly with a copy at the second UAE location; file versioning (20 days) and soft delete (14 days) on the file storage, also replicated to that location.
• A restore exercise must be completed and recorded before real school data is handled, and then every three months.

9. Compliance alignment

• UAE PDPL (Federal Decree-Law No. 45 of 2021): we act as processor under the School's control; a DPA, a subprocessor list, breach notification and data-subject assistance are built into every subscription.
• School regulators (KHDA, ADEK, SPEA, Ministry of Education): the platform supports the records schools must keep, including attendance, academic progress and behaviour, with export for long-term retention, and never shares learner data with third parties.
• Children's data: no profiling, no advertising, no direct collection; guardians act through the school.
• Payment security: schools pay by bank transfer, or by card through Stripe if they choose; card data never touches our systems.
• Independent assurance: an external penetration test of tenant isolation, authentication, upload handling, billing and the administrative functions is planned before general availability, and its summary will be available to subscribing schools on request.

10. Subprocessors

• The provider of the UAE data centre (named here before any school data is placed with it) — hosting, database, file storage, backups — UAE.
• Stripe — only for schools that pay by card — the billing contact's payment data only.

11. Contacts

Security and privacy: privacy@plusup.net. Support: support@plusup.net. Vulnerability reports from researchers are welcome at privacy@plusup.net; we acknowledge within two working days.