SECURITY AND DATA
The detailed version.
For the person who asks how it is built before they ask what it costs. What Staffbook holds, what it refuses to hold, and how the system that keeps your staff records is itself kept. The short version lives on the front page.
What it holds, and what it never will
The boundaries are structural. They are not settings, and no future update quietly moves them.
Training and DBS renewals, the Schedule 2 recruitment checklist, supervisions, rotas, the home’s own checks, tasks and the audit trail. The working file for the people and the building.
There is no child record in Staffbook and no field intended for one. It does not replace a care records system and does not try to. That is a boundary, and it is also the point: trying Staffbook never puts a young person’s data anywhere new.
Certificate number, dates and status. There is nowhere to type what a disclosure says, on purpose.
Disciplinary and safeguarding records about staff open to the Responsible Individual only, behind a fresh password check, and every open is written to the audit trail.
A support worker sees their own record and the published rota. Wages are visible to the Responsible Individual and nobody else, enforced in the database rather than promised in a policy.
How it is protected
Staff records are the sensitive kind. The protections are in the database and the infrastructure, where they cannot be forgotten by a screen.
Every table in the database carries row level security scoped to your organisation. The screens are a convenience; the database is the control. Even a bug in a page cannot cross the boundary, because the boundary is not in the pages.
An automated suite signs in as different providers and different roles and tries to read across the boundary: a support worker into manager screens, one organisation into another. A change does not ship unless every attempt fails.
Certificates and documents live in private storage. Opening one issues a link that dies after sixty seconds, and the open is logged against the person who did it.
Append only. There is no edit and no delete, for anyone, including the owner of the organisation. That is what makes it worth showing an inspector.
Everything travels over HTTPS, enforced for a year at a time in the browser itself. The app cannot be framed inside another site, and nothing in it is allowed to appear in a search engine.
The database is backed up every day on managed infrastructure, so a mistake is a restore rather than a rebuild.
No privileged key is ever sent to a browser. The scheduled jobs that send the Monday digest carry their own secret and can do nothing else.
Passwords are handled by the platform’s authentication system and never pass through Staffbook’s own code. Multi-factor authentication is there for every account, and the sealed section asks for the password again even inside a signed-in session.
Where it runs
Staffbook runs on Vercel and Supabase, large managed platforms, and your data stays in the UK. Alert emails go through Resend from EU infrastructure. When you leave, your data is exported to you and deleted, in the same month you leave.
The data processing agreement comes first, before any data moves: it is the opening document of onboarding, not an afterthought. The authorised sub-processor list lives in it, and if that list ever changes you hear about it in advance.
Staffbook is built in Manchester, and the person who answers a data question is the person who wrote the code. Staffbook Ltd is registered in England and Wales, company no. 17402902. ICO registration: ZC227838. The plain-English version of what is held and why is the privacy notice. Data questions go to hello@staffbook.co.uk and get answered by a person.
The things providers ask first
No. A support worker sees their own file, their own tasks and the published rota, and can record a premises check. Everything else needs a manager login, and the sealed records need the Responsible Individual.
You can leave any month. Your data is exported to you in files a human can read, spreadsheets and the documents themselves, and then deleted.
An evidence pack: one zip for a named person or the whole home, the spreadsheets plus the certificates, with a plain README. Generating it is itself logged, so the handover is on the record too.
Schedule 4 staff records carry a fifteen-year retention duty, and that duty is the provider’s. While you are with Staffbook, everything is held and dated. When you leave, the export is built to BE that record: plain files, complete, readable in fifteen years without us.
A manager is working in it the same afternoon. Support workers get a login, see their own list, and tick things off. If anything needs explaining, that is a defect, and you tell the person who can fix it.
Fifteen minutes, on a call, on a demo home with a year of records in it. If Staffbook does not obviously beat the spreadsheet you run today, keep the spreadsheet.
Book a look Or write to hello@staffbook.co.uk