For data protection officers and IT reviewers
Security and data protection
This page is written for the person whose job is to find the problem. It sets out what the platform holds, who can read it, how it is defended, and, in the same detail, what we do not yet have. Anything marked open is open.
The shape of the risk
Two modules, two different protections
Polarisk runs two products with very different data profiles, and they are protected by different mechanisms. Treating them as one system is the fastest way to misjudge the risk in either direction.
| Psychosocial module | Health surveillance module | |
|---|---|---|
| What it holds | Anonymous survey responses | Named workers' clinical records |
| Protected by | k-anonymity: no group below five is published | Role: the employer's account cannot read clinical detail, and any route around it is evidenced |
| Employer sees | Group averages only | Fitness outcome, validity and adjustments |
| Individual identifiable | Never, by construction | To the signing clinician only |
| Special category data | No | Yes: health questionnaire answers and clinical assessment |
Access
Who can read what
- Employer administratorWho is due, who is overdue, the fitness outcome and its validity date, and any recommended adjustment. Not the questionnaire answers, not the clinical note.
- ClinicianThe questionnaire answers, the drafted findings and the clinical note, for the cases they are responsible for.
- WorkerTheir own questionnaire, and their own result and advice from the clinician.
- PolariskOperates the platform. Access to client data is not a routine part of support and is not used to browse clinical records.
Tenant isolation is enforced at the storage layer: every key is scoped by organisation, so one client's data is not reachable from another's session by construction rather than by query filtering.
Platform
Controls in place
- AuthenticationPasswords hashed with scrypt. Signed sessions with a server-held signing secret. Clinicians and workers set their own credentials; nobody else holds them.
- Worker linksSingle-use, bound to the worker at issue, spent atomically on first use so a replayed link is de-duplicated rather than double-counted. Re-issuing revokes the previous link.
- Brute forcePer-account lockout and per-IP rate limits using atomic counters, so parallel attempts cannot race past the threshold.
- Transport and headersHTTPS with HSTS, a strict Content Security Policy, X-Frame-Options DENY, nosniff, a restrictive Referrer-Policy and Permissions-Policy, and same-origin isolation.
- Input handlingRequest size capped, JSON content type required, which forces a preflight and blocks simple cross-site form posts.
- ErrorsGeneric messages with a correlation ID. Internal detail is never returned to the client.
- No third-party requests on the public siteNo analytics, no advertising pixels, no CDN scripts, no hosted fonts. Fonts are self-hosted. This is verifiable from the page source and from your own network tab, and it is enforced automatically in our build checks.
- Retention hygieneA scheduled sweep reclaims expired single-use tokens and transient artefacts. It is keyed on expiry rather than on a status flag, because a status flag can be reversed by a legitimate action and would delete live data.
Anonymity
How the psychosocial module resists re-identification
Aggregate reporting is easy to get wrong in ways that are invisible until someone attacks it. Three rules do the work:
- A floor of fiveNo figure is published for a group smaller than five people.
- Complementary suppressionSuppressing one small group is useless if it can be recovered by subtracting the others from the total, so further groups are suppressed until that arithmetic fails.
- One breakdown per cycleA single breakdown, by department or by site, is chosen at cycle creation before any response exists and frozen in the published snapshot. Two breakdowns can be cross-referenced against each other; one cannot.
Open items
What we do not yet have
Published because a reviewer who finds these listed by the vendor can trust the rest of the page, and one who finds them himself cannot.
| Item | Position |
|---|---|
| ISO 27001 / SOC 2 | Not held. The controls above are implemented and tested. They are not third-party certified, and we do not imply otherwise. |
| Penetration test | Not yet commissioned. |
| Independent review of the current build | Owed. The most recent independent audit found no critical or high findings, and its lower-severity findings were fixed and re-verified. Changes since then have not had a second pair of eyes, and our standing rule is that this work is never self-certified. |
| Retention schedule for clinical records | Open. Several streams carry statutory retention of up to forty years. The platform currently deletes nothing clinical, which is the safe direction but is not yet a policy. Agreed per client before a pilot begins. |
| Employer-issued credentials | Open by design, mitigated by evidence. See clinical governance for the full description and the structural fix. |
| Sub-processors | Hosting and storage only. No analytics, no advertising, no AI provider today. Any addition is notified before it is enabled. |
| Professional indemnity cover | Being confirmed before any signed report is issued. |
Questions
Common questions
Do you use AI on clinical data?
Not with a third-party model today. Screening is deterministic scoring against a published protocol, and any drafted assessment is a draft a clinician must accept, change or reject. No generative provider is enabled, so none appears on the sub-processor list. If one is ever enabled it is added to that list and clients are notified before it is switched on.
Where is data hosted, and does it leave the UK?
Hosting and storage are the only sub-processors. Region and any cross-border transfer are set out in the data processing agreement for your engagement, alongside the safeguards relied on. Ask before you sign rather than after, and we will put the specifics in writing.
Can we get your DPIA and DPA before committing?
Yes. The processor's DPIA contribution for the surveillance module, the data processing agreement and a DPO-facing security summary are all available on request, before any commercial commitment. The DPIA itself must be completed by you as controller; ours describes accurately what the software does so yours starts from fact.
How do you handle a breach?
There is a written breach notification procedure covering assessment, containment, notification to the controller without undue delay, and the record required under UK GDPR Article 33. Because the signing clinician is an independent controller for the clinical record, notification duties in a clinical breach run to them as well as to the employer, and the procedure reflects that.
Documentation
Request the review pack
The DPIA contribution, the data processing agreement, the security summary and the breach procedure are available before any commercial commitment. Book a call and say what your reviewer needs.