Private SQL Analytics for Regulated Data
In regulated work the blocker is rarely the analysis. It is that the convenient tool would put personal or protected data onto somebody else’s infrastructure, and that single fact changes what you are legally required to have in place.
What uploading actually triggers
Sending data to a third-party service is not just a security preference. It creates obligations:
| Regime | What a third-party upload triggers |
|---|---|
| GDPR / UK GDPR | The service becomes a processor. You need a written processing agreement, a lawful basis, an entry in your record of processing, and a transfer mechanism if their servers are outside your jurisdiction. |
| HIPAA | A vendor handling protected health information is a business associate and needs a signed Business Associate Agreement. A free web tool will not sign one. |
| PCI DSS | Any system touching cardholder data falls inside your assessment scope. |
| Contractual | Most client agreements restrict disclosure to third parties and often specify where data may be processed. |
The awkward part is that none of this is usually evaluated. Somebody has a deadline, finds a CSV tool, and pastes the file in. The obligation is created regardless of whether anyone noticed.
What changes when processing is local
If the analysis happens inside your own browser, on your own machine, no third party receives the data — so no processor relationship is created, no BAA is needed, and nothing enters or leaves your existing scope. The data stays exactly where it already was, under the controls you already have.
That is the whole argument, and it is a structural one rather than a promise about someone’s security practices.
Doing the work
- Open the tool. That page load is the only network activity involved.
- Drop your extract on the File Select panel. It becomes a SQL table named by a letter from its filename.
- Query it — filter, join, aggregate — and press
Ctrl+Enter. - Export the result if you need to. The download is generated locally.
SELECT site, COUNT(*) AS patients, AVG(length_of_stay) AS avg_los
FROM A
WHERE admission_date >= '2025-01-01'
GROUP BY site
ORDER BY avg_los DESC
Aggregating before export is worth a habit of its own: a summary by site carries far less risk than the row-level extract it came from.
Evaluating this for regulated work?
Licensing & security contact →The questions your compliance team will ask
| Question | Answer |
|---|---|
| Where is data processed? | In the browser on the analyst’s own machine. Nothing is transmitted. |
| Where is it stored? | Nowhere. It is held in memory for the life of the tab and discarded when it closes. Nothing is written to local storage or cookies. |
| Who are the subprocessors? | None, because no processing happens off the device. |
| What telemetry is collected? | None. There is no analytics, no error reporting and no beacon of any kind. |
| How can we verify that? | Open the browser’s Network tab and run a query — it stays empty. Or disconnect from the network entirely and confirm the tool still works. Full method here. |
| Can we host it ourselves? | Yes. A self-contained build for your own intranet, with a signed statement and file checksums, is available on request. |
What this does not do
Being precise about the boundary, because overselling a privacy tool is worse than not having one:
- It does not anonymise anything. The data is as identifiable after your query as before.
- It does not secure your machine. If your laptop is compromised or unencrypted, local processing does not help. Disk encryption and access control remain your responsibility.
- It does not control what you do next. Exporting a result and emailing it is a disclosure like any other.
- It does not remove your obligation to hold the data lawfully in the first place.
What it removes is one specific risk: the extra third party that a cloud tool inserts into the chain.