Subject access requests with tracked deadlines, permissions that change automatically when someone’s role does, safeguarding records sealed from everyone outside the team — and an audit trail that shows every decision, ready for inspection.
The obligations become workflows, the access model becomes policy, and the evidence writes itself.
Subject access, right-to-erasure and right-to-correction requests logged, typed and tracked to completion — each with its statutory deadline visible, not remembered.
Route, resource, dashboard, report and field-level permissions, managed in a visual matrix editor. Because access is tied to job categories, it changes automatically the day someone’s role does.
User actions, role transitions and system events recorded throughout. “Who changed this, and when?” is a lookup — not an investigation.
The controls an ICO auditor would ask about, built into the same system the teams work in every day.
Configurable rules for how long each kind of data is kept — policy-driven deletion instead of “we’ve always kept everything”.
Periodic recertification of who can see what, with sign-off recorded — the access model stays deliberate as staff and roles change.
Engagement records scoped by team, with a purposeful cross-team summary layer — colleagues see that contact happened without seeing what shouldn’t travel.
The allegations register and CDM casework are invisible outside the safeguarding team — in the same platform, behind a hard wall. See safeguarding →
Bulk-email permissions and rate limiting — nobody accidentally emails every contact in the diocese on a Friday afternoon.
Phone numbers, NI numbers, postcodes and emails are redacted before any AI call, and the assistant only sees what the logged-in user can. How the privacy guard works →
An inspection-ready system isn’t one with a policy folder — it’s one where the policy is how the software behaves.— See also: the GDPR answer in the DMS FAQ · our data processing statement