CursusOS / Platform / Permissions and data protection

Permissions are the hardest part. They were built first.

A school holds safeguarding records, medical data and children's addresses.
Access control is not a settings page. It is the product.

Book a demo See full functionality

cursusos.com/roles

Roles and access

Role × scope × clearance × purpose

MappingsRolesClearancesAudit

Roles

Grant events

Revocation triggers

Groups, not user listsBy design

Read, write and manage are separateBy design

Export is a separate permission, always loggedBy design

Every temporary grant carries an expiryBy design

Role

Forty modelled roles, from Principal to librarian, each with defaults across all four permission layers.

Scope

Own, team, department, phase or whole school. Which records the job actually reaches.

Clearance

Safeguarding, vetting, disciplinary, medical and pay are clearance-gated rather than role-gated.

Purpose

The layer most systems omit. Duty of care is relational and time-bound, and the model treats it that way.

Four layers

Access control a head teacher can actually operate.

Role says what job somebody holds. Scope says which records that job reaches. Clearance says whether restricted classes of data are in reach at all. Purpose is the layer most systems omit: duty of care is relational and time-bound, so a teacher with the right role and the right scope still must not browse the record of a child they have never taught.

cursusos.com/roles

Roles and access

40 roles · 4 layers · mapped to Workspace Groups

MappingsRolesClearancesAudit

classroom_teachers@ · people:read, attendance:writeActive

pastoral_leads@ · + pastoral:manageActive

dsl@ · safeguarding clearanceRestricted

inspector_2030@ · read-only, expires 14 MarTime-bound

Modelled roles

Grant events

Revocation triggers

Grants

Access is never simply on.

Each grant is tied to a specific event: who granted it, on what action, and when it expires. Nine grant events and six revocation triggers are modelled, so leaving, changing role, ending a placement and finishing a temporary cover arrangement all remove access without anybody remembering to do it.

Role

What job they hold. Forty modelled, from Principal to librarian, each with defaults across all four layers.

Scope

Which records that job reaches: own, team, department, phase or whole school.

Clearance

Whether restricted classes are in reach at all: safeguarding, vetting, disciplinary, medical, pay.

Purpose

The relational, time-bound layer. Being able to see a register, mark one, and change the rules that govern registers are three different powers.

Permissions

Full functionality

Every workflow below is specified with its trigger, its actor, the screen it happens on, the step sequence, the permissions and the edge cases.

Ask about any of it

01Why permissions were built first

A school holds safeguarding records, medical data and children's addresses. Access control is not a settings page. It is the product.

The permission model was specified and built before any module that depends on it.
Every screen in the platform is written against it rather than checking it afterwards.
There is no administrator account that quietly sees everything.
A permission that cannot be explained to a head teacher in one sentence is treated as a design fault.

02Read, write, manage and export

Being able to see a register, mark one, and change the rules that govern registers are three separate capabilities.
Export is a separate action from read, everywhere, and it is always logged.
Bulk operations carry their own permission, because the risk is different in kind.
Nobody inherits export rights by virtue of seniority alone.

03Restricted data classes

Safeguarding, vetting, disciplinary, medical and pay are clearance-gated rather than role-gated.
Clearance is granted to named individuals for named reasons and reviewed on a cycle.
Restricted records never appear in search results for people without the clearance, rather than appearing and refusing.
Every read of a restricted record is logged with the reader, the time and the purpose asserted.

04Nine grant events, six revocation triggers

Grants attach to events: appointment, role change, placement start, cover assignment, inspection window, board term, hire booking, agency involvement, temporary escalation.
Revocation attaches to leaving, role change, placement end, cover end, window expiry and manual withdrawal.
Every temporary grant carries an expiry date at the moment it is created.
Nothing depends on somebody remembering to take access away.

05Audit and accountability

Full audit of reads, writes, exports and permission changes, attributed to a person rather than a service account.
Automated writes attributed to the trigger that caused them.
Audit is queryable by record, by person and by time window, which is what makes an incident answerable.
The audit trail itself is not editable by anyone in the product.

06Data protection and residency

Data protection built to the school's own regulatory position, with retention rules per data class.
Documents held in the school's own Google Workspace tenancy rather than in a vendor silo.
Subject access and erasure handled as governed workflows with evidence of completion.
Retention, purge and anonymisation are named actions with reasons attached, never silent deletions.

Continue