Draft, pending review by a qualified lawyer. The bracketed items are the operator details still to be completed. This page describes what the code actually does, verified on 1 September 2026 — where practice and promise differ, we changed the code, not the words.
We copy public company registers. Most of what we hold is about companies, not people. Some of it is about people — the directors a register names, sole traders whose business is their own name, and the people who open an account here.
This page says exactly what we hold, why we say we are allowed to hold it, and how to make us stop.
We do not track you. No analytics, no advertising, no third-party scripts, no cookie that follows you anywhere.
[OPERATOR LEGAL NAME], [REGISTERED ADDRESS], company number [COMPANY REGISTRATION NUMBER].
We are the controller for everything described here. Write to [CONTACT EMAIL] about any of it.
We have not appointed a Data Protection Officer. We are not required to and we have not.
Effective [EFFECTIVE DATE]. Our terms of use are here; the cookie list is here.
What. A person's name and their role in a company. Nothing else.
Where from. Brønnøysundregistrene's roles endpoint, one request per company.
How much. 137,723 officer records across 74,456 companies. All Norwegian. No other register in this product supplies officers.
What we deliberately do not take. Brreg's API returns each person's full date of birth. Our parser never reads it, so it is never written down. We do not read personal addresses either. We skip officers the register marks as resigned.
Where it shows up. On the public company page under "Who runs it", and in the JSON version of that page. Those pages are open to anyone and every company is in our sitemap, so search engines can index a named director. Signed-in users also see a name as a "who to ask for" column. Officer names are never in a CSV export, and never in the structured data we emit for search engines.
Why we say we are allowed to. Our stated basis is legitimate interest — Article 6(1)(f). The reasoning, written out so you can argue with it:
Stating a basis is not a finding that it is lawful. That call belongs to the reviewing lawyer, and a written legitimate-interests assessment should sit behind this section before it is published.
In some registers a business is a person, and the company name is that person's name.
What we hold. 461,392 Norwegian enkeltpersonforetak and 28,104 Latvian individuālais komersants. Those are the forms we have identified as sole traders in the registers we have loaded so far; if another register we add publishes them under a form we have not yet classified, this number will be wrong until we classify it. The worldwide LEI records we also hold can name a natural person in some legal forms, and we have not counted those.
What we refused to take. Bolagsverket's Swedish file mixes companies with sole traders identified by personnummer — the national identity number of a living human being. We load only records marked as an organisation number, and the import counts and discards the rest: at the last full import that was 1,038,523 sole-trader identities and 2 deceased persons' estates, never stored. On the statistics-agency side an identifier is accepted only if it carries the company prefix, so a birth-year prefix cannot be silently truncated into something that looks like a company number.
How they are treated here. Norwegian and Latvian sole traders are excluded from the matched, pitch-ready product — the queue a salesperson works from, and anything we hand out as a lead. Norwegian sole traders can register an objection in Reservasjonsregisteret, which we do not screen, so we keep them out of that side entirely.
Be clear about the limit of that: the exclusion is a filter, not a wall. A search or an export that does not switch the commercial-buyer filter on can still return those records.
When we read a company's own website we sometimes find an email address that belongs to a named person rather than to the company — firstname.lastname@ rather than post@ or info@.
We hold 202,129 of these, and we hold them in order to withhold them. That is the point. Every address we find is classified as either a company mailbox or a personal one, and that classification is what stops the personal ones being published. Deleting them would not protect anyone — the next crawl would find them again and would not know what they were.
Where they are withheld today, verified line by line in the code: the public company page and both of its JSON versions, the /live dataset browser, the workbench listing (and the order it sorts in, so a hidden address cannot float a row to the top), and every CSV export. Only a total count is ever published.
⚠️ REQUIRED FIX BEFORE THIS PAGE GOES LIVE. One internal screen — the assignment queue a signed-in salesperson sees — selects the email address with no such check and renders it. 175,831 records are in scope. The site already publishes the absolute claim, on
/for-salespeople, that "you will never see one — not on a company page, not in the workbench, not in an export." That is true of the workbench and the export and false of the queue. The same pattern exists in the admin supplier-sourcing screen. It is a three-line fix inlib/match.ts,app/app/queue/page.tsxandlib/supply.ts. Land the fix and this section can say "never". Until then, neither this page nor/for-salespeoplemay say it.
We do not sell a personal email address, and we do not offer one as a product at any price.
Phone numbers are a different story, and we will not overclaim it. We take the first telephone number a company publishes on its own website. We do not classify phone numbers the way we classify email addresses, so a number we hold may be a direct line to a named person rather than a switchboard. If a number on a company page reaches you personally and you would rather it did not, tell us and we will remove it.
If you sign up we hold your email address, a display name you choose, your role and your plan, and your password — stored as a scrypt hash, never as text anyone here can read.
Legal basis. We need this to give you the account you asked for — Article 6(1)(b), performance of a contract. You do not have to give us any of it; you simply cannot have an account without it. If you buy a plan, we also keep what tax and accounting law requires us to keep — Article 6(1)(c).
While you are signed in we hold a session record: a hash of your session token (so a stolen database yields no working sessions), your browser's user-agent string as sent, and a hashed IP address.
Be straight about that hash: it is a truncated SHA-256 of the IP address with no salt. An IPv4 address has few enough possible values that anyone holding the hash could work backwards to the address. So we treat it as pseudonymised personal data, not anonymous data, and so should you.
We also keep a log of sign-ups, sign-ins, failed sign-ins and sign-outs, holding the email address and that hashed IP. It exists to lock out password guessing and to let us see what happened to an account. Basis: legitimate interest in keeping accounts secure — Article 6(1)(f).
We record what you export — the row count and the filter string, which is a record of what you searched for — and any search you save. Basis: legitimate interest in running and metering the service, and in understanding what is worth building.
Payments. Billing is by invoice. There is no payment processor in this product and no card details anywhere in it. If you ask to upgrade, we store the plan you asked for and any note you wrote. Plans are free, £19, £49 and £149 a month.
If you claim a company profile or write to us, we keep what you sent and the address you sent it from, for as long as it takes to deal with it and to show what we did.
The web server in front of this application receives your IP address on every request, as every web server does, and it passes a copy to the application so we can rate-limit sign-in attempts. [REQUIRED before publication: confirm what the nginx access log actually retains and for how long, and state it here. If raw IP addresses sit in a log file, this page must say so — the "we hold a hashed IP" sentence above is about the database, not about the web server, and a reader will otherwise take it as a claim about everything.]
The application, the web server and the database all run on a single server.
[HOSTING COUNTRY] — this must be established before publication and it changes what this section says. If that server sits outside the EEA and the UK, then holding European register data on it is an international transfer, and this page needs a transfers section naming the safeguard relied on and the assessment behind it. Do not guess this from the IP address. Get it from the hosting contract.
We would rather tell you the truth than quote a number we do not honour.
Register records. We hold a company's record for as long as the register publishes it, and we refresh it from the register. Registers keep dissolved companies for years; we mirror that.
Account records. Your account and the things attached to it stay until you ask us to remove them.
Sessions. A session record is deleted from the database when you sign out, and when an expired or long-idle session is next presented. The cookie itself stops working 14 days after sign-in, or after 7 days without use. Session rows that are never presented again are not currently purged by anything — they sit in the table until someone deletes them by hand.
Everything else — sign-in logs, export logs, saved searches, activity notes, profile claims — currently has no set retention period and no deletion job. That is a gap, not a policy, and we are not going to describe it as one. [REQUIRED: set the periods, implement the job, then state the periods here.]
If we hold personal data about you, you can ask us to:
We do not rely on consent for anything on this site, so there is no consent for you to withdraw. If we ever add something that needs consent, we will ask before it runs.
How. Email [CONTACT EMAIL]. There is no self-service button: a person reads your message and does the work by hand. We may have to ask you for enough information to be sure who you are, so that we do not hand your data to somebody else. We will answer within one month of being able to identify you, and if a request is complex we may take up to two further months and will tell you why within the first month. [REQUIRED: this promise is only keepable once [CONTACT EMAIL] is a real, monitored mailbox with someone answering it.]
What we cannot yet do, stated plainly rather than promised away:
⚠️ REQUIRED — the mechanisms behind three of those rights do not exist yet.
- Erasure is temporary. We can delete a register-derived record today, but the next scheduled import reads the register again and writes it back. A deletion is only permanent once we hold a suppression list that the import itself respects. That list does not exist.
- Objection has nowhere to land. There is an opt-out table in the database, but nothing in the served product reads it: it does not filter the search, the dataset browser, the matching engine, company pages or exports. Today an entry in it changes nothing. Our outbound pitch engine, which is the thing it was designed to gate, has never sent an email.
- The correction form works for Danish companies only. Every other company page shows a form that returns "not found" — roughly 10.5 million of the 10.6 million company pages we publish. Until that is fixed, corrections must go to [CONTACT EMAIL], and the company pages must say so.
Wire these before this section is published as written, or narrow this section to what the code does. A page that offers a right the code cannot deliver is the misrepresentation this whole draft exists to avoid.
If you think we have handled your data badly, tell us first — we would rather fix it.
You can also complain to a data protection authority: [SUPERVISORY AUTHORITY], or the authority in the country where you live, where you work, or where you think the problem happened. Complaining costs you nothing and you do not need our permission.
We collect from official registers only, plus companies' own websites. We did not get your details from a list broker, because we do not buy lists.
| Register | Country | Licence, as the register states it |
|---|---|---|
| Companies House | United Kingdom | Companies Act 2006 register data; no reuse restrictions stated by Companies House |
| Brønnøysundregistrene | Norway | NLOD — Norwegian Licence for Open Government Data |
| Bolagsverket and Statistics Sweden | Sweden | Avgiftsfri, EU High-Value Dataset regime |
| [PRH / YTJ](https://tietopalvelu.ytj.fi/) | Finland | CC BY 4.0 |
| Uzņēmumu reģistrs | Latvia | CC BY 4.0, EU High-Value Dataset |
| Registrų centras | Lithuania | CC BY 4.0 |
| [GLEIF](https://search.gleif.org/) | Worldwide | CC0, public domain |
| Company websites | Any | Facts read from each company's own public site, recorded with the page they came from |
Everything outside those six national registers comes from the worldwide LEI file, including the Danish records — we do not hold a Danish registry extract.
We also read company websites for a publicly posted mailbox, phone number or address. Every such fact is stored with the page it was found on, so we can show our working.
We hold 10,838,346 company records and publish 10,603,837 of them. Lithuanian records are held and shown on no public page.
Attribution: five of these registers require it as a licence condition, and this table is where we give it.
If you are named in one of those registers, we got your details from the register, not from you. Where data is taken from a public register covering millions of records, writing to every named person individually would take effort out of all proportion to the benefit, and the law provides for that — Article 14(5)(b) — on condition that the information is made publicly available instead. This page is that. It is public, permanently linked from every page of the site, and it names everything we hold. If you have an account, you were shown this page when you signed up.
Four cookies, all of them ours, none of them tracking you: one signs you in, one remembers where your dashboard is, one is the admin console's session, and one remembers whether you collapsed the sidebar. Dismissing our cookie notice is remembered in your browser's local storage, and that is the only thing we store there.
The full list, with lifetimes and what each one contains, is on the cookies page.
If we change what we do, we change this page, and the date at the top changes with it. If we ever add anything that tracks you, we will ask you first — properly, before it runs, not with a banner that has already set the cookie.
[OPERATOR LEGAL NAME] · [REGISTERED ADDRESS] · [CONTACT EMAIL] · [COMPANY REGISTRATION NUMBER] · [HOSTING PROVIDER] · [HOSTING COUNTRY] · [DNS PROVIDER] · [SUPERVISORY AUTHORITY] · [EFFECTIVE DATE]
[CONTACT EMAIL] must also replace the placeholder corrections@berry.example in lib/site.ts, which is currently linked from the site footer as "report a wrong record".
Two tokens from the working inventory were removed from the body on purpose:
[VAT NUMBER] belongs in the terms and on invoices, not in a privacy policy.[DPO OR NULL] and [EU/UK REPRESENTATIVE] were editorial instructions sitting inside published prose. The body now states plainly that there is no DPO. Whether an Article 27 representative (EU) or a UK representative is required cannot be answered until the operator's establishment is known — decide it, then either add a named representative section or leave the page silent because none is required. Do not ship a bracketed instruction to the reader.Classified the way claude-for-legal's policy-monitor classifies drift: REQUIRED where the page would contradict the code, ADVISABLE where the page is merely silent.
lib/match.ts:78 admits a record via the phone branch; lib/match.ts:129 and app/app/queue/page.tsx:58 then select the email with no kind check, and line 154 renders it. 175,831 records in scope (measured: named email plus a phone, on trading entities in visible countries). lib/supply.ts:102 and app/admin/supply/page.tsx:152 share the pattern. Contradicts the live claim on /for-salespeople.engine.opt_outs appears in no query builder: not lib/search.ts, lib/live.ts, lib/match.ts, lib/company.ts, lib/supply.ts or /api/export. It is admin-write and admin-display only. engine.sent_emails is empty, so the outbound engine it was designed to gate has never run.ingest/officers.ts re-inserts officer rows on every run with onConflictDoNothing. Without a suppression list the import respects, deletion is temporary.app/api/claims/route.ts:43 hard-codes country = 'DK'. Roughly 10.5M of 10.6M public company pages show a form that 404s. This also breaches AGENTS.md doctrine 2 ("every published entity has a visible correction path").currentUser() deletes only a session that is presented and idle past 7 days, so rows past their 14-day expiry are never presented and never purged. Nothing touches auth_events, export_events, activity_log, saved_segments, profile_claims, entity_officers.ingest/sources/se.ts:16 says of Sweden's Reklamsparrtyp advertising-block code "We read it and we honour it." It is read and counted in the walk-assert and never persisted — there is no column for it in db/schema.sql and no query reads it. Either store and honour it, or fix that comment. As it stands it is a compliance claim in the codebase that the codebase does not keep, and it is exactly the kind of sentence a complainant would quote. The body of this page states the opposite (we screen no marketing opt-out register), which is the true position.app/robots.ts allows / and every entity is in a sitemap shard, so 137,723 named Norwegian officer records are search-indexable. Defensible, and the body argues why, but it is the exposure most likely to draw an Article 21 objection. Consider whether the "Who runs it" block warrants noindex or a signed-in gate.components/CookieNotice.tsx, rendered at app/layout.tsx:137. It links to /legal/cookies, which does not exist yet. Ship that page with this one or the banner and this page both point at a 404.almanac.cookie.notice, set by that banner. The earlier "no localStorage anywhere" finding is stale.berry_rail, set in components/DashboardSidebar.tsx:98), not local storage. It is the one cookie set without a Secure flag — note it on the cookies page.lib/plan.ts), not the figures in CLAUDE.md.137,723 officer rows / 74,456 companies / single source no_brreg · 202,129 named and 138,993 generic emails out of 790,036 contact rows · 461,392 NO/ENK and 28,104 LV/IK sole traders · 10,838,346 entities held, 10,603,837 outside the hidden country (LT) · 175,831 named-email-plus-phone rows in the queue's pool · four cookies, one localStorage key, zero external hosts referenced anywhere in app/ or components/ · fonts via next/font/google, self-hosted at build · no SMTP/ESP dependency in package.json or .env.example · CONTACT_PREVIEW_ROWS = 10.
Add /legal/privacy, /legal/terms and /legal/cookies to app/sitemap-static.xml/route.ts (currently only /, /for-salespeople, /live, /pricing) and link them from the "about" column of components/SiteFooter.tsx, alongside the corrections link.
Every statutory reference in this draft comes from the operator's own prior research (docs/country-roadmap.md, /for-salespeople) or from general knowledge, not from a legal-research source verified in this session — treat all of them as [verify], including Article 6(1)(b), 6(1)(c), 6(1)(f), 12(3), 14(5)(b), 21 and 22. Following claude-for-legal's guidance, the GDPR articles are cited as the basis we state, and as the rights we describe, not as a conclusion that any of this processing is lawful. That call is the reviewing lawyer's.