NakedSignal

Security

Security and data handling

The analysis comes to your data, not the other way round. The report runs on your own computer, the files that leave are designed to carry only aggregates, and you sign off everything that is released.

In an engagement

The analysis runs where your data is

Runs on your own machine

The program runs inside your laboratory, on your own computer. Your paired results never need to leave it.

Offline by design

The program needs no network connection and opens none. It has no access to your laboratory information system, network or instruments.

You sign off what is released

The files that leave are designed to carry only aggregates: the aggregate results, the report and a release statement listing each file, which you sign.

Small counts suppressed

Counts below the minimum cell size you set (5 unless you choose otherwise) are masked in anything that leaves, and so are counts that could be worked out from the totals beside them. We test this on synthetic data; it lowers the risk that a patient is singled out, it does not remove it. It protects one file at a time: repeated releases from nearly identical data can reveal more (see below).

Sample list stays with you

The list of samples that crossed a limit is keyed by your own sample reference and stays on your computer.

Settings fixed in advance

Decision limits and the re-test budget are agreed and fixed before the data are opened, and the release statement prints the settings' checksum, so a later change to them would show.

What reaches us

Aggregates only

When the program runs on your computer, we receive the signed aggregate release and nothing else. Patient names, identifiers, dates of birth and row-level results stay with you.

Repeated releases

Suppressing small counts protects each file on its own. Two releases from nearly identical data, for example a second report after a few more samples are added, can together reveal one record that neither shows alone. That is why the next versions of the program add a local release guard: it keeps a record on your computer of what has already been released and refuses a new release that differs from an earlier one by only a few records. Until that version reaches you, send one release per data set.

We do not take coded or pseudonymised extracts for a report or a study. Your own staff run the program, and we receive only the release you sign.

The check never uploads your file

The change check on this site reads your file in your browser and computes there. The file is not uploaded, so we hold no patient data from it.

Storage and access: planned, not in place

We hold no coded laboratory data today. Coded pairs arise only if a laboratory chooses to contribute them to the Analyser-Change Registry; before we accept any, we will agree in writing how they are stored, who can open them and how access is recorded. Encrypted storage and an access log are planned for that step; neither is in place now.

Retention

We hold no row-level data from you. What you release to us is kept and deleted as the written agreement says.

Your DPO decides

Your data protection officer decides what, if anything, is shared beyond the aggregate release.

This website

A static site that collects almost nothing

HTTPS everywhere

Served over HTTPS with HTTP Strict Transport Security, a content security policy that only allows scripts, styles, fonts and images from this site itself (inline scripts and styles included), and headers that stop it being framed by another site.

No cookies, no trackers

The site sets no cookies and loads no third-party fonts, embeds, advertising or tracking pixels. Page views, and a few actions on the change check and calculators, are counted with cookieless Vercel Web Analytics, which does not identify you.

Report a vulnerability

Found a security problem in this site or anything we publish? Report it through the contact form and give us reasonable time to fix it before disclosing it.

Subprocessors

Subprocessors for this website

ProviderWhat it does for this site
VercelHosting, the contact form endpoint, the payment check and Registry functions of the change check, request logs for security and operation, and cookieless page and action counts.
ResendDelivers messages sent through the contact form, and Registry summaries you choose to send from the change check, to our inbox.
GoogleHosts the mailbox that receives those messages.
StripeTakes card payments for a change report on its own payment page; we receive a record of the payment, never the card number.

Messages you send through the contact form are used only to reply to you.