Least privilege, by default
A new role starts with nothing and is granted what it needs. Nobody sees a safeguarding note because a permission was left switched on from a previous term.
Security & data protection
Pupil data is the most sensitive data a school holds.
Everything below describes how MyPortal is built and operated. If you need it in a form your governors or DPO can sign off, ask and we will send the full documentation.
Principles
Assume it will be audited
Every read and write against pupil data is attributable. If a school is ever asked who saw a record and when, the answer exists rather than having to be reconstructed.
The school owns the data
Your data is yours, in a documented schema, exportable in full, at any time, at no charge. That is a design constraint, not a support policy.
Safeguarding
Some records must be harder to reach.
Safeguarding and SEND information is not simply another field on a form. MyPortal treats these records as a separate access boundary: visible to the designated staff, invisible to everyone else, and logged either way.
- Separate permission scopes for safeguarding and SEND
- Access recorded with user, record and timestamp
- Records follow the pupil on transfer, under the same controls
- Staff see the existence of a record only where policy allows
Controls
What that means in practice.
-
Identity
OAuth 2.0 and OpenID Connect, so MyPortal signs in against the identity provider your school already runs. Multi-factor and conditional access stay where you manage them.
-
Access control
Permissions are enforced server-side on every request. Hiding a button is a courtesy to the user; the API is where the decision is actually made.
-
Auditing
Access to sensitive records — safeguarding, SEND, medical, documents — is logged with the acting user, the record and the time.
-
Document handling
Attachments are held outside the database in controlled storage, served through the same permission checks as the record they belong to.
-
Data residency
Hosted deployments run in the United Kingdom. Self-hosted deployments run wherever your school decides, including entirely on your own infrastructure.
-
Secure development
Changes are peer-reviewed and covered by an automated test suite. Anything touching pupil data, permissions or safeguarding gets a second, security-specific review.
Data protection
The questions your DPO will ask.
- Who is the controller?
- The school is the data controller for its pupil and staff data. Block acts as a processor, working on your documented instructions under a data processing agreement.
- Where is the data held?
- In the UK for hosted deployments. If you self-host, it never leaves your infrastructure at all — we have no standing access to a self-hosted instance.
- How do we handle subject access requests?
- A pupil record can be exported in full, including the audit history attached to it, so an SAR is a task for your DPO rather than a support ticket to us.
- What happens if we leave?
- You take a complete export in a documented format, and we delete what we hold to an agreed schedule. There is no exit fee and no proprietary lock on your own records.
Found something? Tell us.
We would far rather hear about a vulnerability from you than from a school. Report it to hello@myportaledu.com. We will acknowledge it, keep you updated, and credit you if you would like us to.
The same address takes anything else you need, including a security questionnaire to complete.