What runs where, and what leaves.

Which one applies is decided with you before anything is built, and written down. I do not let a project drift from the first into the second without saying so, because the security answer changes when it does.

The deliverable is a single HTML file. It carries its own charting library and its own fonts. It has no script tags pointing anywhere, no stylesheet links, no images loaded from a server, no analytics, no error reporting, no telemetry. Opening it makes zero network requests of any kind.

• No infrastructure. Nothing to provision, patch, or pay for.
• No credentials. There is no account, no login, no session, no password to manage or revoke.
• No network egress. Not restricted egress — none.
• Works offline. From a local download, a network drive, or SharePoint.
• Nothing to breach on my side. Because I hold nothing.

What is inside the file

Usually the data itself, pre-aggregated. That matters: the file is the data, so wherever it gets forwarded, the data goes with it. Before anything is embedded I check whether it is personal data, whether it is commercially sensitive, whether every embedded column is actually read by a chart, and whether the grain is finer than the questions need. If a view is weekly-by-team, I embed weekly-by-team — not per-person-per-minute.

One file, one audience. If two teams should not see each other's numbers, they get two files with two slices of data, not one file with a filter someone can clear.

After delivery, distribution and access control are yours — your file share, your permissions. I say that explicitly at handover so it is never an assumption.

A note on sharing it: some mail systems quarantine HTML attachments as a matter of policy, so the reliable way to distribute it is your own file share, SharePoint or intranet rather than email. Once it is there, opening it is a double-click and there is nothing to install.

What you give up for that

The same property that makes this shape safe — no server, no account, nothing of yours held anywhere — takes four controls off the table. If your reviewer needs any of them, the honest answer is that this shape is the wrong one, and I would rather say so here than be found out in the review.

• No revocation. Once a file is delivered, everyone holding a copy holds all of the data in it, permanently. There is no access to withdraw, because there was never any access to grant.
• No audit trail. Nothing records who opened it, when, or how many times. A tool that could tell you that would need the server and the account this shape does not have.
• Deletion does not reach it. Everything I commit to deleting is on my side. A copy already inside your organisation — in a mailbox, a laptop, a backup — is genuinely difficult to find and remove, and an erasure request that touches it is your problem, not mine. That is worth knowing before you send personal data into one.
• Plain on disk, and quiet past DLP. The file is not encrypted at rest beyond whatever your storage does, and most data-loss tooling does not inspect data embedded in an HTML file — so it can travel where the equivalent spreadsheet would have been stopped.

Three things reduce this rather than solve it: embedding the coarsest grain that answers the question, one file per audience, and a visible “data as of” date so an old copy announces itself. Where the controls above are genuinely required, that is an argument for shape two with the dashboard behind your own single sign-on — or for a platform, which I will tell you.

What actually runs when you open it

Worth being precise about, because “it just opens in a browser” can be heard as “nothing executes”, and that is not quite right. The file renders charts, filters and drill-downs, so it runs code — its own, inlined, with no network access.

A dashboard can either carry its data baked in, or ship as a viewer you point at your own export. Which one you get is decided with you rather than defaulted, because the trade runs in both directions:

• Baked in — the file is the data, so wherever it is forwarded the data goes with it. Nothing parses anything; there is no input.
• A viewer — the file is no longer the data, so the four limits above largely stop applying: an empty viewer can be forwarded harmlessly and your export never travels with it. The cost is that a spreadsheet parser is code processing a file I did not generate.

So, plainly: nothing leaves, and the only thing that runs is a parser I wrote, on a file you chose, inside the browser sandbox. It is a few hundred lines using the browser's own decompression and XML parsing rather than a large third-party spreadsheet library — deliberately, so the code you are trusting is small enough to read.

Four behaviours follow from the same principle as the rest of this page, and you can watch all of them on the demos while the network tab stays empty:

• It says what it needs before you go and find a file — the expected columns are listed next to the picker.
• A missing column is refused by name and changes nothing on screen. It never half-loads.
• An ambiguous date column is refused rather than guessed. 01/02/2026 is 1 February here and January 2 in the US; if nothing in the file settles it, you get told instead of charts built on the wrong months.
• Where a view cannot be built from your export, it says which. Rather than leaving sample data sitting there looking like an answer.
• A European export reads as a European export. Semicolon separators, decimal commas, non-breaking-space thousands, currency symbols and Windows-1252 accents are all read from the file rather than assumed from your browser's locale. The convention is settled per column, from that column's own values.
• Every inference is shown, not assumed. After a file loads, a panel names the delimiter, the encoding, the decimal separator, the date order it settled on and any rows it skipped, with the reason. A dashboard that is confidently wrong is worse than one that refuses, because it gets forwarded and nobody re-checks a chart.

How much it will take. Measured through the picker on an Apple M3 with 8 GB, in Chrome 152, rather than estimated: a 48 MB CSV of 390,000 rows parses in 1.7 seconds, and a 9.3 MB workbook of 85,000 rows in 7.5 seconds. The published ceilings are 50 MB for CSV and 10 MB for XLSX, and a larger file is refused with the number rather than left to freeze the tab. XLSX is the lower of the two because unzipping a workbook and walking a DOM over every cell costs roughly twenty times more per megabyte than reading text — not because it needs more memory.

Values are text, never markup

Every value that comes from your data is written to the page as text, never as HTML. A spreadsheet cell containing a script tag is a realistic accident, not a hypothetical attack, and it renders as visible characters rather than executing. Dependencies are pinned to exact versions, taken from the official release artifact, and recorded in the file header so you can review them if an advisory lands later.

This is the part that stopped being hygiene and became load-bearing the moment a dashboard could read a file you chose, so the test is now in the build rather than in a checklist. Two paths get it, because they are genuinely separate: a hostile value baked in at build time, and the same value arriving through the file reader. Two specific cases are covered by name — a cell containing <img onerror>, and one containing </script>, which would otherwise close the element the data sits in and have the remainder of the file parsed as HTML. The build fails rather than writing a file that could do that.

This is where the honest answer changes, so it gets the most detail.

Where the code runs

In order of preference:

1. Inside your own account — your Azure subscription or your Google Cloud project, your scheduled job, your storage. In practice that is an Azure Function or a Cloud Run job on a schedule; on Workspace an Apps Script trigger is often enough and needs no cloud project at all. Data never crosses a boundary, you can see it and kill it, and there is no bus-factor problem if I disappear. This is the default I argue for.
2. My EU-region infrastructure, with credentials you own — used only when you have nowhere to run it. Data does cross to me, so it goes in the Article 30 register and a data-processing agreement is signed first. Nothing persists between runs: the source extract is deleted as soon as the aggregate is built, and every copy is gone within seven days of the engagement ending. The cost of that is worth stating — when a run produces a number you do not believe, there is no extract left here to check it against, so I will ask you to send it again.
3. A VPS I administer — only when neither of the above fits.

Access — the exact permission to ask for

The pipeline reads. It does not write back to the source system and it does not hold a credential that could.

The same principle on either platform: grant access to one container, not to a directory. Both make the narrow grant harder to set up than the broad one, which is exactly why the broad one is so common.

If a vendor asks for the broad option to read one folder, push back — including if the vendor is me. Credentials are per-project and never reused across clients. After consent I check the granted scopes in the console, because what was requested and what was granted are not always the same thing, and I recommend you check them too.

Secrets

A managed secret store in your own account, in an EU region, with access granted to the job's own identity rather than to a person: Azure Key Vault with a managed identity on Microsoft, Secret Manager with a service-account identity on Google. Elsewhere, that platform's native equivalent. The rule is the same in every case — a person's credentials are never what the job runs on.

Secrets are injected at runtime as environment variables. Never committed, never logged, never pasted into a chat message or a ticket. Rotation never requires a code change — if rotating a key means editing code, the design is wrong. Keys are rotated at handover and whenever anyone with access leaves.

What happens when it fails

A stale dashboard looks exactly like a fresh one. That is the failure mode that actually hurts, so it is designed against directly:

• Sanity checks run before publish — row count within an expected band, no all-null key column, totals within tolerance of the previous run.
• If a check fails, the job stops and keeps yesterday's good output. It does not publish something wrong.
• Every published file carries a visible “data as of” timestamp, so a stale copy is obvious to the person reading it and not just to me.
• Failures alert me the same day. A missed run alerts too — silence is treated as a failure, not as success.
• Logs record events, not payloads: what ran, when, how many rows, what failed. No personal data in log lines.

Who "me" is, and what happens when I am not there. Alerts go to my email and my phone. There is one person behind that, so the honest version is that I am occasionally on a plane or asleep, and there is no rota behind me — you should know that before you depend on it. What protects you is not my availability but the design above: a failed check does not publish, so the dashboard keeps serving yesterday's good output with its own “data as of” date visible on it. Nothing updates silently and nothing goes wrong quietly while I am unreachable; the worst case is that the numbers stop moving and everyone can see that they have. If you need a guaranteed response window, that is a support contract and I would rather tell you I do not offer one than sell you a promise I would break.

During setup I trigger a deliberate failure and confirm the alert actually arrives, rather than assuming it would.

Minimisation

I take the columns I need and leave the rest. If a file has names, emails, salaries or free-text notes the dashboard never shows, they get dropped at the first processing step rather than carried around. Where an identifier is needed only to join or count, it gets hashed or replaced. I verify this by diffing the columns in the source extract against the columns the deliverable actually uses — anything in the first list and not the second has to be justified or removed.

Residency

Subprocessors

Any third party that touches your data — hosting, vault, error tracking, email — is listed by name and purpose in the Article 30 register. I do not add one mid-project without telling you first. Adding a service is a two-step change: register row first, integration second.

Anything hosted

Where a deliverable is hosted rather than handed over as a file, it sits behind your own single sign-on — Entra ID with your conditional access policies on Microsoft, Google sign-in with context-aware access on Workspace — using the identity provider you already run. No separate user list for someone to forget to deprovision, which is the failure that actually happens. HTTPS everywhere, HTTP redirects to HTTPS, and I verify the certificate and the redirect before a URL is sent to you.

Separation

Development never points at production data or production credentials — separate app registrations, separate secrets, separate storage. Test data is synthetic or a minimised sample. Anything I publish publicly, including every demo on this site, is synthetic-only, generated by a seeded script; no real extract ever becomes a demo, not even lightly edited.

The bus-factor answer has to be structural too, or it is worth nothing.

• It runs in your tenant, on your credentials.
• You get full source rights and the actual source — not a compiled artifact, not a licence to use something I keep.
• Code is documented and the delivered version is tagged in a repository you hold.
• You get a runbook covering what to do when an alert fires after I am gone.
• At least once per project, before handover, I rebuild the pipeline from backup into a scratch environment and run it end to end — then write down the date, what I restored, how long it took, and what was missing. A backup nobody has restored is a guess, not a backup.
• There is no platform to stay subscribed to, no per-viewer licence, and nothing that stops working if you stop paying me.

When an engagement ends: credentials are rotated, my access is removed, and your data is deleted from my machines and from any service I stood up — the working folder, the backups that contain it, and the trash, with the specific backups named.

Ideally I am holding nothing to begin with, because the self-contained shape never required me to keep a copy. Where I did hold data, deletion is confirmed in a handover document that you countersign. The engagement is not finished until that is signed and every row in the access register has a revocation date against it.

Insurance and paperwork

Four separate things, so they are listed separately.

• Professional indemnity insurance is in place — RC Professionnelle, held in Belgium where I am established. You can have a copy of the certificate for your file; it names the insurer, the policy number and the period of cover. This is the one thing on this site that is available on request rather than published, and the reason is narrow: a certificate carries a live policy number, and putting that on a public page is an invitation to someone else to use it. Everything that can be published, is.
• The data processing agreement: I sign yours. Most legal teams already have a controller-to-processor template they would rather use than review someone else's, and I do not draft clauses myself. Where you have no paper of your own I start from a standard controller-to-processor model — or the European Commission's standard contractual clauses where they apply — reviewed by a qualified professional before I sign.
• It is signed before the first extract, not retro-fitted. Where I am processing personal data on your behalf, I do not accept a data file until the paperwork is in hand.
• There is a one-page incident plan — detect, contain, tell you, assess the 72-hour GDPR question, write it up — filled in per project with your named contact and an agreed notification window. I walk through it once at kickoff so I am not reading it for the first time during an incident.

Everything above describes how I work. You have no way to check that from a description, and I have no client list to point you at instead — so the documents themselves are published in full: the baseline runbook, the annex for each delivery shape including the Google one, and every template you would actually receive and countersign — the access register, the data-flow diagram, the incident plan, the handover checklist, the Article 30 register.

Not a summary and not available on request. If something in there is weaker than your own standard, that is a conversation worth having before we start rather than after — and it is a great deal easier to have when you can read the thing.

Including me. If a supplier cannot answer these quickly and specifically, that is information.

1. Exactly which permission are you asking for, and what else does it reach? “Read-only” is not a scope. Make them name it, then check what was actually granted in the console rather than what was requested.
2. Who owns the credential — you or us? If you cannot revoke it yourself, in a click, without asking them, you do not control your own data.
3. Where does the compute actually run, and in which region? Ask for the configured region string, not the marketing page.
4. What happens when a refresh fails? If the answer is not “it keeps the last good version and tells someone”, you will eventually make a decision on stale numbers without knowing it.
5. Does a missed run alert, or only a failed one? Most tools only catch the second. Silence is the expensive failure.
6. Name every subprocessor that touches our data. Hosting, vault, error tracking, email. If the list takes them a while to produce, it is not being maintained.
7. What do you hold at the end, and how is it destroyed? Ask for it in writing, countersigned.
8. What happens if you disappear? Do you hold the source, the credentials and the ability to run it — or a licence to something they keep?
9. What are you certified for? If the answer is a framework name without the word “certified” or an auditor attached, it is alignment, not certification. That can be fine — it just should not be sold as the other thing.
10. Does our data ever go into an AI model, and which one? Almost every supplier now uses AI tooling somewhere. The useful question is not whether they use it but where the boundary is: a chat window, a coding assistant's context, a file upload, a vendor's own training. Ask for it as a sentence you could put in a contract. My answer is in the runbook: I use AI coding assistants, and client data does not go into a model — I work against synthetic or redacted samples, which is why every demo on this site is generated rather than borrowed.