Polarisk

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 data boundary between worker, clinician and employer Three columns. The worker sees their own questionnaire and their own result and advice. The clinician sees the answers, the drafted findings and the clinical note for their own cases, and holds the clinical record. A gold wall separates the employer, whose account is refused at the clinical record. The employer sees who is due and overdue, the fitness outcome with its validity, and recommended adjustments. The fitness outcome is the only thing that crosses the wall. THE WORKER SEES Their own questionnaire Their own result, and the clinician's advice THE CLINICIAN SEES The answers Drafted findings and the clinical note For the cases they are responsible for Holds the clinical record THE WALL THE EMPLOYER SEES Who is due and overdue The fitness outcome and its validity date Recommended adjustments Not the answers, not the history, not the note AN EMPLOYER ACCOUNT IS REFUSED AT THE CLINICAL RECORD The fitness outcome is the only thing that crosses
Fig. 1 What each party can see in the health surveillance module. The employer's account is refused at the clinical record itself, and the only thing that crosses the boundary is the fitness outcome with its validity and any recommended adjustment.

The shape of the risk

Two modules, two different protections

Polarisk runs two products with very different data profiles, protected by different mechanisms. They need reading separately.

Data profile by module
Psychosocial moduleHealth surveillance module
What it holdsAnonymous survey responsesNamed workers' clinical records
Protected byk-anonymity: no figure is published for a group below five, computed on a grid we fix and no viewer can change, applied to the headcounts you declareRole: the employer's account cannot read clinical detail, and any route around it is evidenced
Employer seesGroup averages onlyFitness outcome, validity and adjustments
Individual identifiableNot from any figure we publish, and not from combining them. The exact guarantee, and its limits, are set out under this table.To the signing clinician only
Special category dataNoYes: health questionnaire answers and clinical assessment
The guarantee, precisely. What we guarantee is that every published figure is computed over at least five responses, on a grid we fix. That is a statement about how each figure is built. It is not by itself a proof that nothing can be inferred from the published set. A review in July 2026 found exactly such an inference, where asking for two different anonymity thresholds returned two figures whose difference covered one person; the threshold is now fixed and the viewer cannot vary it. The floor is also applied to the group sizes you declare, which we cannot verify from here, so an organisation that declares a team larger than it is would pool fewer people than the report implies. Who attested the headcounts is recorded in the signed report.
A DPIA is required for the surveillance module, and the employer must complete it as controller. We maintain a processor's contribution describing accurately what the software does, so the controller's assessment starts from fact rather than assumption. Ask and we will send it.

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 choose their own password when they accept an invitation, and workers answer on a single-use link with no account at all. Note the limit honestly: today the employer sends those invitations and distributes those links, so it holds the means to use them. That cannot be prevented in software while the employer does the onboarding, so it is recorded instead. Every clinician account shows who invited it and whether anyone has checked the registration against the public register, and every set of answers records how it arrived. Polarisk-issued clinician accounts and direct-to-worker delivery are required before a pilot at scale.
  • 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. Set on the pages and on the API separately, because the host's static header rules do not reach a serverless function; assuming they did left the API without them until July 2026.
  • 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.
Why the third rule is framed that way. Choosing the breakdown before any response arrives means the decision is not a function of the answers, so no observer can learn anything from which breakdown was published. A rule that decided later, on the data, would itself leak.

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.

Open items, current position
ItemPosition
ISO 27001 / SOC 2Not held. The controls above are implemented and tested. They are not third-party certified, and we do not imply otherwise.
Penetration testNot yet commissioned.
Independent review of the current buildInternal only, and now twice. A full internal audit on 27 July 2026 found one critical, four high and thirteen lower-severity items. A second adversarial pass on 29 July found a further critical that the first pass had recorded as a control that held: the anonymity threshold was supplied by whoever asked for the figures, and requesting two different values returned two results whose difference covered a single person. It is closed: the threshold is now a fixed policy constant, and the regression test asserts what an attacker can do rather than that the guard exists. The high findings are fixed. The remaining critical is a structural limit of any self-serve tool where the customer declares its own group sizes, described plainly in the anonymity section above rather than closed. Both passes were run by the same AI model that wrote the code being reviewed, which is not independence. No external firm has reviewed this build. Our standing rule is that security work is never self-certified, and neither pass discharges it.
Report integrity hashesEach signed report and certificate carries a SHA-256 content hash, and a frozen report is never recomputed, so re-opening a cycle cannot move a figure already issued. The hash lets two copies be compared. It is not a signature and does not defend against someone with write access to the store; we do not describe it as tamper-proof.
Vulnerability disclosureReport anything you find to hello@polarisk.co.uk. We will acknowledge within two working days. See security.txt.
Retention schedule for clinical recordsOpen. 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 credentialsOpen by design, mitigated by evidence. See clinical governance for the full description and the structural fix.
Sub-processorsNetlify (Netlify, Inc.) for hosting and storage, and nothing else. No analytics, no advertising, no AI provider today. Any addition is notified before it is enabled.
Data locationApplication data is currently stored and processed in the United States (US East). This is a transfer outside the UK. Two routes are available under our provider's DPA (Data Privacy Framework UK Extension, and the UK IDTA); which one governs employee data is being confirmed with the provider.
Professional indemnity coverBeing 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?

Netlify is our only sub-processor, for hosting and storage. Application data is currently stored and processed in the United States (US East), which is a transfer outside the UK. Netlify's Data Processing Agreement provides for two routes: its EU-US Data Privacy Framework certification including the UK Extension, which is active and currently scoped to non-HR data, and the UK International Data Transfer Addendum, which that agreement treats as executed between us under the laws of England and Wales. Because workforce health records are employee data, we are confirming with Netlify which route governs them rather than assuming, and the answer goes in writing into your data processing agreement.

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.

Book a review call Book an intro call