Privacy Notice

This is the binding version of the Transparency Pact. The Pact is the plain-language promise; this notice is what has to be true underneath it for the promise to be keepable. If the two ever conflict, that is a bug in the Pact — tell us and the Pact gets corrected, because it is meant to be an honest summary of this document, not a friendlier alternative to it.

Every section below carries a pointer to the section of LEGAL-DATA-SPEC.md it implements, so that the notice and the engineering specification can be reviewed against each other line by line.

This site takes no payments. There is no shop, no checkout and no payment provider, so there is no payer, no payment metadata and no accounting record — and this notice is shorter than it will one day need to be. The numbering of data classes and purposes below follows LEGAL-DATA-SPEC and therefore has gaps where the payment-related entries would sit. That is deliberate: it keeps the two documents comparable, and it makes visible exactly what would come back if the site ever started selling something.

1. Who is responsible#

Controller within the meaning of Art. 4(7) GDPR:

Adrian Blümlein, Jurastraße 2a, 86641 Rain, Deutschland

Email for all data protection matters: support@the1millionrun.com

We have not appointed a Data Protection Officer. This is a solo operation below the § 38 BDSG twenty-person threshold, and the public leaderboard is not "regular and systematic monitoring" within the meaning of Art. 37(1)(b) or (c).

2. What we hold#

Every category of personal data this system touches. If it is not in this table, it is not in the database.

D9, D10, D11 and D13 do not exist here. They are the supporter entry, payment metadata, accounting records and refund records — the data a shop generates. This site does not take payments, so none of it is collected.

D7 is the category to pay attention to. Bank statements and revenue dashboards contain the runner's customers' personal data — third parties who never agreed to anything here. That is why evidence goes to the Verifier Board and is never published, in any form, ever. What the public sees is whether evidence was submitted, whether the Board accepted it, and why.

D16 does not contradict that, and the difference is the whole point. The operator's own run publishes its evidence (section 12), and what is published is a separate, redacted copy in a separate place — never the original file, and never anybody else's file. The private evidence store stays private for every run on this site, the operator's included. Customer names, account numbers and anything else identifying a third party come out before publication; where a document cannot be redacted without destroying what makes it evidence, it is not published and the gap is stated instead.

D17 stores what was said, not who said it. Objections arrive by email at the address in section 1. What goes into the register is the objection and the answer. The sender's address is not stored with it and is not published, because a register of people who complained about the operator would be a worse thing to hold than the problem it solves.

3. Why we hold it, and on what legal basis#

One row per purpose, not per data class. This is the list. It is closed: a purpose that is not named here is one we are not allowed to add later without coming back to you first (Art. 5(1)(b)).

P5 and P6 are absent. They are payment processing and the bookkeeping that follows it. With no payments there is no transaction to process and no statutory retention obligation arising from one.

Our legitimate interests under P7 and P12 are keeping the platform available and its record trustworthy. Under P8 the interest is building the dataset this platform exists to build; the balancing test is in section 6. You can object to processing based on Art. 6(1)(f) at any time under Art. 21 — see section 8.

Providing your data is not a statutory requirement, but for runners it is a contractual necessity: without a name or pseudonym, a country, a category and a premise there is nothing to put on the board, and the contract cannot be performed.

4. Why the leaderboard is a contract, not consent#

There is no checkbox on "show my run publicly", and that is deliberate.

Consent under Art. 7(3) can be withdrawn at any time, for no reason, and withdrawal must be as easy as giving it. If public display rested on consent, any runner could withdraw at any moment — including one about to be disqualified — and we would be obliged to take the run off the board. The leaderboard would be editable by the people it judges.

Art. 6(1)(b) is the basis instead, because public listing is not a side effect of this service. It is the service. A runner who does not want to be listed cannot be given the thing they signed up for.

You keep your Art. 17 and Art. 21 rights, which are handled in section 9 by de-identification rather than deletion. That is disclosed up front — in Pact §4, in Ruleset §11.1, and again on the confirmation screen before you confirm anything.

5. What you accept, and how#

At registration, two separate, non-pre-ticked boxes, each recording the version number of the document accepted:

1. I accept Ruleset v1.0 — the contract.
2. I accept the Transparency Pact v1.0 — the data deal, including P8 and P9.

Plus two optional, clearly separated, unticked boxes:

3. You may use my name and run in case studies, interviews and partner material (P10)
4. Send me the newsletter (P11)

Boxes 3 and 4 are not required to complete registration and refusing them changes nothing about your run. That is Art. 7(4), and it is enforced in the form, not just promised here.

What we record for each is the scope, the version, a cryptographic hash of the exact text you were shown, the time, the method, a hashed IP address and the user agent — not a boolean. Every version of the Ruleset and the Pact stays published at a permanent address, so "you accepted the Pact" can always be resolved to the precise words you accepted.

6. Insights: legitimate interest, not consent#

We aggregate run data to produce statistics about how ventures actually make money, and over time those statistics may be published, shared or sold. The Pact says so on day one, because a purpose not named at collection is a purpose we may not use later.

This happens in two steps, and the split matters:

Step 1 — computing aggregates from run data. Legal basis Art. 6(1)(f), supported by Art. 5(1)(b), under which further processing for statistical purposes is not incompatible with the original purpose, and by Art. 89(1), which requires safeguards in exchange: minimisation, pseudonymisation where possible, and no output that identifies anybody. Our balancing test: the source data is already public by the runner's own choice, the output identifies nobody, and the purpose was disclosed before collection rather than discovered afterwards. You can object at any time under Art. 21, and we honour it by excluding your run from all future aggregate computation.

Step 2 — publishing or selling the result. If the output is genuinely anonymous, the GDPR does not apply to it (Recital 26). That is why the standard in section 7 is not bureaucracy: it is the entire legal foundation of the insights product.

We deliberately do not ask for consent for this. If we did, every runner could withdraw it later, the dataset would develop holes over time, and a buyer would be buying something we could not guarantee. Legitimate interest plus a real anonymisation gate is both more honest and more robust than a consent checkbox we would eventually have to work around.

7. What "anonymised" means here#

Not an adjective. A gate, with numbers, applied before anything leaves the building.

The test is the motivated intruder test: could somebody with reasonable effort and access to other available information re-identify an individual from what we release? Our case is unusually hard for one specific reason, and we would rather state it than hope nobody notices: the most powerful tool for re-identifying our aggregates is our own public leaderboard. If we published "median time to $100,000 in Profit%, Germany: 214 days" while exactly one German Profit% run existed, we would have published a named person's private figure.

So every published or sold aggregate must satisfy all of the following:

1. k ≥ 10. No published figure may derive from fewer than 10 distinct runs. k ≥ 20 for anything sold commercially.
2. No quasi-identifier stacking. Every cell of every cross-tabulation (category × country × tag × time band) must meet k on its own, not just the total.
3. Everything continuous is banded. Durations and revenue in bands; dates to month or quarter, never to a day.
4. Outliers are suppressed, not rounded. The fastest and slowest runs are the most identifiable points on the board.
5. No free text, ever. Premises, notes, messages and reasoning are never aggregated. They cannot be banded and they are inherently re-identifying.
6. No differencing. Two releases whose difference isolates a single run are a leak even if each passes on its own. Every release is registered and checked against the previous ones.
7. Objecting and withdrawn runs are excluded from all future computations.
8. Active runs are excluded. Only completed runs — finished, verified, retired, disqualified — enter the dataset.

Every release is recorded with its contents, recipient, minimum cell count, quasi-identifiers used, suppressions applied, the differencing check, the leaderboard cross-check and who approved it. If anyone ever asks how we know a release was anonymous, that register is the answer.

The honest consequence: we cannot sell insights early. With a handful of runs, nothing we compute is anonymous whatever we call it. The product is planned for 50 or more completed runs, not for month three.

8. Your rights#

You have all of these. Where there is a self-service path, use it — it is faster than we are. We answer within one month (Art. 12(3)), extendable by two further months for complex requests, in which case we tell you inside the first month.

Withdrawing consent does not affect the lawfulness of processing carried out before you withdrew it.

If you are just reading the site, we hold nothing about you but the server log entry described in section 10, which expires on its own. There is nothing to export and nothing to erase.

9. What erasure actually does#

This is the section most privacy notices leave vague. Ours cannot afford to, because the Pact makes a blunt promise — you can always stop being identifiable, you cannot make the run un-happen — and this is the table that makes it defensible rather than evasive.

A decision that named you is rewritten where it named you. Board reasoning, review notes and checkpoint notes are free text, they are public, and "we de-identified the record" would mean nothing if your name survived inside a paragraph. So on an erasure request your former display name and your run's former web address are replaced with Runner #N inside those notes as well. The finding itself is untouched — only the name goes. The rule that reviewers write "the Runner" rather than a name (Ruleset §7.5) comes first; this is what catches the one that got through.

When you ask, we tell you in the response exactly what was deleted, exactly what was kept, and which provision requires us to keep it. Not a form letter.

One consequence worth stating plainly, because it will surprise somebody: a disqualified runner asking for total removal gets the same treatment as anyone else. The identity goes, the evidence goes, the decision and its reasoning stay. That is Art. 17(3)(a), and it is the reason the platform is worth anything.

When a runner is erased, the web address their run used stops working and returns 410 Gone. There is deliberately no redirect to the run's new address: a list pairing the old URL with the new one would preserve the name we were asked to remove and tie it to the record that survived. Old links lead nowhere, on purpose.

10. How long we keep things#

Each of these is executed by a scheduled job, not by intention. A retention policy nobody runs is worse than none, because it documents the breach.

Three details in that table are easy to misread, so they are spelled out:

"The end of the run" means a run that actually ended — verified, unverified, retired, disqualified or expired. While any run of yours is still active or inactive, nothing above starts counting. A run that goes quiet for years is still a run, and its timer is still going.

A refused application is deleted, not de-identified. No timer ran, no number was published and no decision is on the public record, so there is nothing to preserve. After six months the application, your record and the consent entries attached to it are removed outright. The six months exist so that a re-application or a challenge is still possible.

If you hold more than one run, your contact address survives until every one of them has been over for twelve months. We are not going to delete the address we need to reach you about a run that is still going.

11. Who else processes your data#

We use the following processors under Art. 28 data processing agreements.

Sending and receiving are two different providers on one domain, and it is worth knowing which is which, because the second one holds your words. Mail we send you leaves through Resend from noreply@. Mail you send us arrives in a mailbox at IONOS on support@ — and that includes every request under section 8, every objection to the operator's published evidence, and every appeal. A request for erasure is itself personal data, so the mailbox that receives it is named here rather than treated as plumbing.

Everything we send carries support@ as its reply address, so replying to any of it lands in that mailbox and nowhere else.

There is no payment processor, because there are no payments. If that changes, Ko-fi and PayPal join this table and this notice is republished with a new date before the first payment is possible — not afterwards.

The database and all file storage are in an EU region, chosen at creation and not changeable afterwards. That was deliberate.

International transfers. Where a processor above processes data outside the EU/EEA, the transfer rests on: Vercel — certified under the EU-U.S. Data Privacy Framework (DPF). Resend — certified under the EU-U.S. Data Privacy Framework (DPF), including the UK Extension. Supabase — EU Standard Contractual Clauses (SCC); the database and file storage themselves stay in the EU region regardless (see above). Checked August 2026 — this area has changed before and processor status should be re-verified periodically, not assumed.

The support@ mailbox is hosted in Germany, at IONOS, a German company. Every message you send us — including a request to see, correct or erase your data, and including an objection to the operator's published evidence — stays inside the EU from the moment you send it. There is no third-country transfer on that path and therefore no transfer mechanism to rely on.

That is stated here rather than left in a table because it is the one route that touches people who are not runners and never accepted anything: anybody may write to us, and what they write is personal data before we have even read it.

You can request a copy of the safeguards in place by writing to the address in section 1.

12. The Verifier Board, and the one run it does not verify#

Verification runs on two tracks (Ruleset §10.2), and they are different enough that a single paragraph describing "how runs are verified" would be wrong about one of them.

Your run — and every run that is not the operator's — is verified by the Board. Board members are the only people outside the operator who see financial evidence (D7), and the only people who see a sealed identity (D6) before it is published.

That relationship is papered, not assumed. Every Board member signs an agreement before seeing anything, containing processor terms under Art. 28, confidentiality, no onward disclosure, and return-or-deletion on leaving. Access is through named accounts — never a shared login — and every single access to an evidence file is logged with the run, the member and the timestamp. That last part is a column, not a promise: the member's account address is matched to a seated verifier and recorded against the access, so "logged with the member" resolves to a name and not to a blank. Board members are bound by the recusal rules in Ruleset §10.3.

There is currently no external Board. The operator is the only reviewer. This section gains the location and transfer mechanism of each member as soon as anyone is seated — until then, saying so is more useful than describing a body that does not exist.

The operator's own run is not verified by anybody, and publishes instead. It cannot be verified here: the operator would be appointing their own judges. So that one run gives up what every other run keeps. Its full revenue record is public, and the evidence behind it is published — redacted — rather than submitted privately. It is labelled verified — public evidence and never verified on its own, because those are two different claims.

What that means for your data is nothing at all, and that is the point:

• The exception attaches to the operator's run and to no other. Your evidence stays private whether or not you would prefer otherwise, because it contains your customers' data and that was never yours or ours to publish.
• What is published for the operator's run is a separate redacted copy (D16), not the private original. The private evidence store has no public path for any run on this site, including that one.
• Anybody may object in writing to what is published, with no deadline, to the address in section 1. The objection and the answer are published together (D17). The objector's address is not stored and not published.

A leaked sealed identity would be a reportable personal data breach under Art. 33 with a 72-hour clock. Board access is treated as the most sensitive path in the system, because it is.

13. Storage on your device#

None beyond what is strictly necessary to serve the page.

No analytics. No tracking. No advertising identifiers. No localStorage, no sessionStorage, no fingerprinting. The public site sets no cookies at all. The only cookies this domain ever sets are the session cookies of the operator's own administration login, which are strictly necessary for that login and are never set for a visitor.

That is why there is no cookie banner here: under § 25 TDDDG consent is required for storing or reading anything on your device that is not strictly necessary, and we store nothing. There is nothing to ask you about.

14. No automated decision-making#

There is none, within the meaning of Art. 22. No profiling, no scoring, no automated rejection.

Applications are reviewed by hand. Verification decisions are made by a human — a Board member, or the operator while there is no Board — and published with their reasoning. The 30-day settlement window and the appeals process are likewise carried out by a person and recorded afterwards; nothing in this system reaches a verdict on its own.

Where the system computes something automatically — elapsed time, a currency conversion, the sum of The Receipts, whether a declared capital total has passed the Bootstrap ceiling — it is arithmetic on figures you can check yourself, not a decision about you.

15. Complaints#

If you think we are handling your data unlawfully, please tell us first — the address is in section 1, and most of what could go wrong here is fixable.

You also have the right to complain to a supervisory authority under Art. 77, regardless of whether you contact us. The competent authority for us is:

Bayerisches Landesamt für Datenschutzaufsicht (BayLDA), Promenade 18, 91522 Ansbach, www.lda.bayern.de. You may also complain to the authority where you live or work.

16. Two things we withhold, and why#

Most notices do not mention limits like these. Both are already binding, so they are stated here rather than discovered.

A sealed run's own declaration is not in its data export. If your run is sealed, your download does not contain the sealed declaration itself — your real name, your full account list, your notes. It lists that the declaration exists, when it was made, and that it is being withheld. Everything else we hold about you is in the file.

The reason: you wrote that declaration and know exactly what is in it, so returning it to whoever is holding a signed link adds nothing for you. It is also the most damaging record on this site to disclose to the wrong person. Art. 12(1) allows us to provide information through a different channel and Art. 12(6) allows us to ask for further proof of identity where we have reasonable doubt. Ask from the contact address on file and you will get it. This applies only while the seal is on: when the run ends, the declaration is published anyway and appears in your export in full from that moment.

Evidence files are never disclosed to anyone but the Board, including under an access request from a third party, because they contain other people's data as well as the runner's. The operator's own run publishing redacted copies (section 12) is not a hole in that: those copies are separate documents, made public deliberately, and the underlying files stay exactly as unreachable as everyone else's.

17. Changes to this notice#

Every version of this notice and of the Pact stays published at a permanent address. Material changes are announced by email and on the site before they take effect, with a plain-language summary of what changed and why. Where the law requires fresh consent, we ask again rather than assume. Your run stays bound to the document versions you accepted.

Version 1.0, in effect since 21 August 2026 — the same date as Ruleset v1.0 and the Transparency Pact v1.0, because a runner accepts all three at once.