How data flows

This page is written not for the person choosing a tool, but for the person who approves its use: a data protection officer, a security team, an external auditor. It answers the questions of a standard assessment form — where data is stored, who receives it, who it is shared with — for a service built in an unusual way.

The unusual part is one thing: the spreadsheet you analyse is never sent to our servers. The calculation runs in your browser. This is not a promise about our discipline and not a setting we could quietly change — it is how the product is built, and below we describe how to verify it yourself.

This page does not replace the Privacy Policy, the Cookie Policy and the Terms of Use — it describes the technical side of the same thing. If the texts ever diverge, the legal documents prevail, and we treat the divergence as a defect to be fixed.

How the analysis runs

The analysis engine is written in Rust and compiled to WebAssembly. When you open the analysis page, your browser downloads the module from our server the same way it downloads the page's images and scripts. After that only your device works:

  • you choose an XLSX file, and your browser reads it;
  • parsing the spreadsheet, every calculation, the class matrix and the recommendations all run on your device;
  • the report is built there too, and the XLSX export is assembled in the browser.

The file is not uploaded to the server — not in full, not in parts, not in any intermediate form. Tens of thousands of rows take about three seconds, and there is nowhere to compute them except on your machine — which is visible in the fact that the speed depends on your hardware, not on our load.

Diagram: the file, the calculation and the results stay in the browser; only signing in, buying access and the contact form leave it
Diagram: the file, the calculation and the results stay in the browser; only signing in, buying access and the contact form leave it

How to check without taking our word for it. Open your browser's developer tools, the Network tab, and run an analysis. Between choosing the file and seeing the report there will not be a single request that sends data — neither to our domain nor to any other. The check takes a minute and needs no access to our code.

What is sent to our servers

The list is exhaustive. The application has exactly three groups of endpoints that accept anything from the browser, and there are no others.

Account and sign-in. Registration, sign-in and sign-out, session renewal, password reset and change, resending the confirmation e-mail, signing in with Google. What travels: your e-mail address, your password (only its hash is stored on the server), your user name and your interface language.

Buying access. Starting a purchase, returning from the payment page, cancelling a subscription, requesting a refund, the purchase history and the issuing of an invoice or a credit note. What travels: identifiers of the payment session, the subscription and the plan. Card details never pass through our servers at all: payment happens on the payment provider's page, to which your browser navigates in full.

A message from the contact form. Only if you use it: your name, e-mail address, subject, message text, interface language and the page you sent it from.

Beyond that, the web server keeps an ordinary technical log: IP address, requested address, time and browser string. It is what lets us notice an outage or an attack, and every website has one.

There is no endpoint that accepts the file or the results of an analysis. That is a verifiable statement rather than a policy: no such request handler exists in the code, so there is no setting that could turn one on.

What never leaves

  • the file itself and any part of it;
  • the rows of the spreadsheet, the column names and their contents;
  • the results of the analysis: classes, coefficients, totals, the matrix;
  • the recommendations built from your data;
  • the report you export.

From this follows the thing you are most likely here for: we do not know what you analysed, and we do not even know whether you ran an analysis at all. We have no "number of calculations" metric — it cannot be collected without sending us the data, and we do not receive it. For the same reason our refund rules do not depend on whether you used the service: we have no way to check.

The flip side of the same property, and it is worth knowing: we cannot restore your analysis. Closing the tab takes it with it, because no copy existed anywhere except your browser.

What stays in your browser

  • cb_access_token — the token that unlocks the engine's full mode. Stored in local storage, valid for no more than two hours and never longer than the paid period.
  • cb_cms_jwt — the cookie holding your session on the site. Marked httpOnly, so page scripts cannot read it, and it lives for up to seven days.
  • The record of your answer to the cookie banner — including the answer "no".
  • The file itself — in the page's memory only, while the page is open. It is not written to local storage, to the browser's database or to the application's temporary files, and it disappears with the tab.

Everything listed is visible in your browser's developer tools and can be deleted by you at any time. The full list with retention periods is in the Cookie Policy.

Who else is involved

Our sub-processors and what each one is for:

  • the hosting provider — the site and the database of accounts and purchases run on its infrastructure;
  • the payment provider (Stripe) — payments, subscriptions, refunds, invoices; payment takes place on its pages;
  • the mail relay — address confirmations, password reset links, purchase notifications and replies to enquiries;
  • Google — signing in with Google, if you use it, and page analytics.

None of them receives the file, the rows or the results of an analysis: that data is not held by us and therefore not by our contractors either.

About analytics — plainly

On every page of the site, including the analysis page, a Google Analytics tag is loaded. We say so here plainly, because you will see it yourself in the first minute of any check, and staying silent about the obvious would devalue everything else on this page.

What it does and does not do:

  • it counts page views: which address was opened, where the visitor came from, the language and the device type;
  • until you answer the cookie banner, the tag runs in the "denied" state: it is loaded, but it sends no events and creates no cookies of its own;
  • it does not receive your file, rows, results or recommendations. They are not present in the page's document in a form a third-party script reads, and the tag does not read them;
  • it is not used for advertising or profiling.

If a third-party script on a data-processing page is unacceptable in your organisation as such, write to us. That is a reasonable requirement, and it is solved by configuring the environment, not by arguing about what the tag collects.

What the pages do not carry

  • Fonts are served from our domain: they are bundled into the site's build, and the browser makes no request to third-party font services.
  • Images come from our domain even when their source is our content management system: the browser never contacts it.
  • The analysis engine is loaded from our domain and makes no calls of its own.
  • There are no ad networks, third-party chat widgets, social counters or session recording services on the site.

What we do not have

We prefer to say this ourselves rather than leave you to find it.

  • We do not hold an ISO/IEC 27001 certificate or a SOC 2 report.
  • We do not have an independent penetration testing report.
  • We do not run a 24/7 incident response service or a formal certified vulnerability management process.
  • We have not appointed a data protection officer: the scale of our processing does not require one.

We are a small supplier, and the list above honestly reflects our size. What matters here is something else: a certificate confirms that an organisation protects the data it has received well. We do not receive the data of your analysis — there is nothing to protect on our side. The risk that certification removes is, in this part, removed differently: not by a procedure, but by the absence of the data.

None of this reasoning applies to what we do receive — accounts, purchases, enquiries — and there the usual measures are in place: encrypted connections, passwords stored as hashes, restricted access to servers, backups, logs. Judge them by the ordinary standard, as you would any other supplier.

Edition and tailored documents

The date of the current edition is shown at the top of the page. We commit to updating this text in the same release that changes anything described here: any new call to the server, any new third-party script on the analysis page. An outdated description here is not marketing imprecision — it is a false statement made to an assessor.

If your internal decision needs documents for your specific case — a completed security questionnaire, a section for a data protection impact assessment (DPIA), an annex to the contract — write to checkbusiness.pl@gmail.com. We prepare such documents individually.