Least privilege, by default
A new role starts with nothing and is granted what it needs. Nobody sees a record they should not because a permission was left switched on from last year.
Security & data protection
You are handing us data about other people.
Everything below describes how our products are built and operated, and applies to both of them. If you need it in a form your governors, your DPO or your insurer can sign off, ask and we will send the full documentation.
Assume it will be audited
Every read and write against sensitive data is attributable. If you are ever asked who saw a record and when, the answer exists.
The customer 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.
Controls
What that means in practice.
Identity
OAuth 2.0 and OpenID Connect, so our products sign in against an identity provider you already run. 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 is logged with the acting user, the record and the time — and kept long enough to be worth having.
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 you decide, including entirely on your own infrastructure.
Secure development
Changes are peer-reviewed and covered by an automated test suite. Anything touching personal data, permissions or payments gets a second, security-specific review.
Sensitive records
Some records must be harder to reach.
A safeguarding note, a medical need, a consent form, a photo ID held because the law requires it — these are not simply more fields on a form. Our products treat them as a separate access boundary: visible to the people who are supposed to see them, invisible to everyone else, and logged either way.
- Separate permission scopes for the most sensitive categories
- Access recorded with user, record and timestamp
- Records stay under the same controls when they move
- Staff see that a record exists only where policy allows
Data protection
The questions your DPO will ask.
Who is the controller?
You are. A school is the controller for its pupil and staff data; a salon or clinic is the controller for its client records. 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 record can be exported in full, including the audit history attached to it, so an SAR is a task you can complete yourself 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.
Schools have a further set of questions — safeguarding as an access boundary, SEND and medical records, what follows a pupil on transfer. Those are answered in detail on myportaledu.com.
Found something? Tell us.
We would far rather hear about a vulnerability from you than from a customer. Report it to hello@blocksoftware.uk and it goes straight to Rowan Richards, who owns security here. We will acknowledge it, keep you updated, and credit you if you would like us to.
Send us your security questionnaire
Most organisations have one, and most of them ask the same forty questions. We are happy to complete yours, or to talk it through with your IT partner directly.