Privacy Policy - version 2026-10-12

Version 2026-10-12, published October 12, 2026, effective on publication. This editorial update simplifies the introduction and update-notice wording. It does not change our data processing, your rights, or your consent choices, and does not require a new acknowledgement. The previous version of October 11, 2026 (2026-10-11) is archived.

Controller and Contact

The controller of personal data processed through PoliData is Allan Kirui, an individual who operates PoliData and is based in Poland. PoliData is not yet operated through a registered business; when it is, we will publish a new version of this policy naming that business. Because the controller is established in the European Union, there is no representative under Article 27 of the GDPR. Email privacy@getpolidata.com for data-protection requests, including a postal address for correspondence, and support@getpolidata.com for product support.

Scope and Data We Collect

Account and organization data: name, work email, hashed password (if you set one), organization, role, timezone, default jurisdiction, invitations, legal-document acceptance records, and a profile photo if you add one.

Interface preferences: your language, theme, start page, and the order and visibility of navigation items, saved with your account.

Sign-in and account security data: sign-in sessions and the devices they come from, security events, two-step verification, passkeys, Google or Microsoft accounts you connect or sign up with, and email address changes, as described in Sign-in and Account Security below.

Workspace data: alerts, watchlists, saved searches, digest settings, notification history, reports, collaboration activity, and support communications.

Search history: the legislative records you open, the searches you run, and how you use Explore suggestions while search personalization is on, and topics you pick when you first sign in or add in Explore, as described in Search History and Personalization below.

Technical and security data: IP address, user agent, request path, session timing and revocation metadata, security events, and audit records.

Billing and trial data: selected plan and currency, billing contact and address, Stripe customer, Checkout and subscription identifiers, trial eligibility and dates, invoice and payment status, cancellation state, and webhook processing records. Card details are handled by Stripe rather than stored by PoliData.

Research Access data: institution, academic role, institutional email domain, project description, optional ORCID identifier, application status and review notes, and grant and renewal dates.

Usage and abuse-prevention data: request counts per account and IP address over short time windows, counts of distinct records viewed per day, sign-up and email-request rates, bot-challenge results, and API request counts per API key each hour and per workspace each calendar month, which members of your workspace can see under Usage in their account.

Public legislative data: names, official roles, affiliations, contact details published by official institutions, votes, bills, interests, and legislative activity concerning public officials and institutions.

Optional analytics data: page paths without query strings or URL fragments, referrer, browser, operating system, device type, screen size, language, approximate location, and approved product events.

Purposes and Legal Bases

Purpose

Legal basis

Provide accounts, workspace features, alerts, collaboration, support, and billing

Performance of a contract or steps requested before entering one

Provide the sign-in methods you choose (password, authenticator app and recovery codes, passkeys, or a Google or Microsoft account), create your account with a Google or Microsoft account if you choose to, keep you signed in for as long as you choose, change your email address when you ask, and save your interface preferences

Performance of a contract (providing the features you choose)

Show the profile photo you choose to add to members of your workspace

Consent, which you give by adding a photo and can withdraw at any time by removing it

Keep sign-in sessions and security events, show your devices, email you about new sign-ins and security changes, and limit repeated failed sign-in steps

Legitimate interests in protecting your account and the service against unauthorized access

Show owners and administrators of a team workspace their members' security events, with an approximate network, browser, and operating system, let them download them, show which members use two-step verification, and let an owner require it

Legitimate interests of the workspace and of PoliData in securing shared workspaces

Interpret the text of your searches with an AI provider to find related records and add related Polish and Dutch search terms

Performance of a contract (providing the search you request)

Keep a private history of the records you open, the searches you run, and how you use suggestions, to choose and order your search suggestions

Legitimate interests in providing relevant search within the service you use; you can object at any time by switching personalization or suggestion engagement off, which stops recording and deletes that history

Show a record that people in at least five organizations opened recently as a Popular suggestion, with only the number of organizations

Legitimate interests in helping users find records of wide professional interest; you can object at any time by switching suggestion engagement off, which stops your views from being counted

Enforce one trial per customer and organization, reconcile provider events, and prevent repeated trial abuse

Legitimate interests in fair, secure subscription administration and fraud prevention

Assess Research Access eligibility, enforce one free account per person, and administer grants and renewals

Performance of a contract at your request; legitimate interests in limiting free access to eligible researchers

Protect accounts, prevent abuse, maintain audit trails, diagnose failures, and secure the service

Legitimate interests in operating a secure and reliable service

Keep a record that a data export or erasure was carried out, with the account's ID and a keyed one-way hash of its email address

Legitimate interests in being able to show that data-protection requests were carried out

Process and publish public legislative information for research and civic transparency

Legitimate interests in public-interest legislative research and transparency

Measure optional product usage with Umami Cloud

Consent

Meet accounting, tax, data-protection, and lawful disclosure duties

Legal obligation

Sign-in and Account Security

Each time you sign in, PoliData creates a sign-in session on our servers. It records when the session started and when it was last used, the IP address it started from and the most recent one, your browser's user agent and the browser, operating system, kind of device (computer, phone, or tablet) and, when the browser reports it, device model (for example iPhone or Pixel 8) read from it, the approximate city and country of the most recent of those IP addresses, how you signed in (password, passkey, or a Google or Microsoft account), whether you completed a second step and whether you chose to stay signed in, and a one-way hash of a random identifier kept in a cookie in your browser, as described in the Cookie and Storage Notice. We find the city and country in a location database kept on our own servers (DB-IP Lite); your IP address is not sent to anyone for this, and we keep only the city and country, never coordinates. We use sessions to keep you signed in, to show your active sessions, with their device and approximate city, in the Devices list under Sign-in & security in your account, where you can end any of them, and to email you, naming the device and approximate city, when your account signs in on a device that has not signed in to it in the last 90 days. When you sign in, with any method, you choose whether to stay signed in on that device. If you tick Keep me signed in, the session lasts until it has gone unused for 30 days, and 90 days at most. If you do not, which is the default, it ends 12 hours after you sign in, and your browser deletes the sign-in cookie when it closes (a browser that restores your previous session may keep it, but the 12 hours still apply). A session also ends when you sign out or end it. Changing or resetting your password, changing your email address, turning off two-step verification, removing a passkey, or disconnecting a Google or Microsoft account also ends some or all of your other sessions, as does locking an account or suspending or deleting a workspace.

We record security events, such as signing in, confirming your identity before a sensitive change, turning two-step verification on or off, using or replacing recovery codes, adding or removing a passkey, connecting or disconnecting a sign-in method, changing your password or email address, and ending sessions, each with the time, IP address, and browser user agent. A request to change your email address is recorded without the requested address; both addresses are recorded once you confirm the change. Codes, secrets, passwords, and sign-in tokens are never recorded. We email you about new sign-ins, password changes, two-step verification changes, recovery codes used or replaced, repeated failed second steps, passkeys and sign-in methods added or removed, new API keys, and email address changes.

Owners and administrators of a team workspace can see these security events for its members in the workspace audit log: when each happened, what it was (for example how you signed in), the approximate network it came from (the first three numbers of an IPv4 address or the first three groups of an IPv6 address), and the browser and operating system, but never the full IP address or the browser's user agent. For an email change they see the old and new addresses once you have confirmed it. They can download the audit log as a CSV file, and each download is itself recorded in the log. They can also see which members have not turned on two-step verification. An owner can require two-step verification for the workspace; members who have not set it up then cannot use the workspace until they do, and while it is required, owners and administrators are emailed when a member sets it up. Members are told about this view under Sign-in & security in their account. We keep these security records as controller and show workspace owners and administrators this view of them to protect the shared workspace; the organization that runs the workspace is responsible for how it uses what it sees, for example under its own employment rules. In a personal workspace, only you can see your security events.

If you turn on two-step verification with an authenticator app, we store the app's secret key encrypted and your 10 recovery codes only as keyed one-way hashes, with the time each code is used. The setup QR code is drawn in your browser. Keep your recovery codes somewhere safe and separate from your password. When a second step fails, we record the time, the IP address, and the kind of attempt. After 10 failures in 15 minutes we pause further attempts, and after 20 in 24 hours we lock the second step until you reset your password by email. If you lose your second factor, support can reset it only after checking your identity by means other than the account itself.

A passkey lets you sign in with your device's screen lock, such as a fingerprint, face scan, or PIN, instead of a password. Your device checks the fingerprint, face, or PIN itself; it never leaves your device and never reaches PoliData. We store the passkey's public key and credential identifier, a signature counter, the name you give it, when it was added and last used, and details your device reports about it: the ways it can connect (such as USB, NFC, Bluetooth, or built in), and whether it is backed up or synced. When you create a passkey, we give your device a random identifier for your account together with your email address and name, so the device can show which account the passkey belongs to. A public key cannot be used to sign in on its own. If a password manager or Apple, Google, or Microsoft saves or syncs your passkey, that happens between you and that provider.

Where offered, you can create your PoliData account with a Google or Microsoft account, or connect one under Sign-in & security in your account, and then use it to sign in. This is your choice. When you sign in or sign up through one of these providers, your browser goes to the provider, which sends us a signed token. From it we keep the provider, the provider's identifier for your account, and the email address the provider gave when you connected it or created your account with it, together with when that was and when you last used it. For sign-in, we ask Google only for your account identifier and email address; Microsoft also sends the account's name and sign-in name, and we use the sign-in name as the address when there is no email. When you create an account this way, we also ask Google for your name, and we use the name either provider sends to fill in the signup form, where you can change it before you submit it. We keep only the name you submit, as for any account, and never your picture. The provider's email address becomes your account's address. If Google confirms that it manages that address, because it is a Gmail address or the address of a Google Workspace account, we create your account when you submit the signup form. Otherwise we email a 6-digit code to that address and create your account only when you enter the code on the same signup page, with five tries. The code is kept only as a keyed one-way hash with the unfinished sign-up and is deleted along with it. The unfinished sign-up, with what the provider sent and what you entered in the form, stays open for 30 minutes while you choose a plan, accept the Terms, and enter the code if one is needed. An account created this way has no password until you set one with Forgot password. We never use the provider's email address to sign in to, or connect the provider to, an existing PoliData account: if one already uses that address, we ask you to sign in to it and connect the provider there. We keep a one-way hash of each token only until it expires (about an hour) so that it cannot be used twice. Google and Microsoft are independent controllers of the sign-in they provide to you: each handles it under its own terms and privacy policy, not on our behalf, and we send them none of your PoliData data. The provider learns that you are signing in to, or signing up for, PoliData. For a work or school Microsoft account, the organization that manages the account controls its own sign-in records: it may see that you signed in to PoliData and may restrict the connection. You can disconnect a provider at any time while you keep another way to sign in, which also ends the sessions started through it.

To change your email address, you first confirm your identity. We then email a confirmation link to the new address and a notice to your current one. The link works for 24 hours; the pending change, with both addresses, is deleted a day after it is used or expires. When you confirm, we change the address, sign out your other sessions, update your billing email with Stripe if you own the workspace, and email the old address a link that undoes the change for 7 days, kept until a day after it is used or expires. While that link works, no other account can be created, invited, or changed to use the old address or another address that reaches the same inbox. Undoing the change restores the old address and puts the account back in a clean state: it signs out every session, requires a password reset, removes every passkey, authenticator app, recovery code, and connected sign-in method, revokes the API keys and pauses the webhooks created from the account in the 7 days before the change was requested or since, and emails both addresses a list of what was removed. If someone started a new account with the old address, or an address that reaches the same inbox, after the change was requested and has not confirmed it, undoing the change deletes that unfinished account.

A profile photo is optional, and only you can add, change, or remove yours; workspace owners and administrators cannot add one for you. If you add one, we crop it and re-encode it as a 256 by 256 pixel image without the original file's metadata, such as camera details or location, and store only that copy. Members of your workspace can see it next to your name. We show it with your consent, which you can withdraw at any time by removing the photo.

Your interface preferences (language, theme, start page, and the order and visibility of navigation items) are saved with your account so they follow you to other devices. Your browser keeps a copy, labelled with your account identifier so it is not applied to another account, and your start page is also kept in a cookie so PoliData can open it directly. Signing out removes them from the browser, except the theme shown on screen.

Search History and Personalization

Search personalization is on by default. While it is on, PoliData records in your account the legislative records you open (record identifier, country, time, and where in PoliData you opened it) and the searches you run (search text, result type or tab, countries, parliamentary term, number of results, time, and whether you searched in Explore or the Cmd+K search). While suggestion engagement is also on, PoliData records how you use Explore suggestions: which suggestions were shown to you (the kind of suggestion, its position, and the record, topic, or search it points to), which ones you used, which ones you marked as not interested, and the number of seconds a record page was visible to you. Each entry is stored with your user account and the workspace you were using. Page paths, IP addresses, and device data are not part of this history. Opened records and searches are recorded only after you have accepted the October 4, 2026 (2026-10-04.2) or a later version of this Privacy Policy, and suggestion engagement only after you have accepted the October 6, 2026 (2026-10-06) or a later version.

We use this history only to show you personal suggestions in Explore and the Cmd+K search: records to continue with, related records, searches to run again, the same subject in another country you have access to, and topics you read most. Suggestion engagement puts the kinds of suggestions you use most first, rests a suggestion you have skipped on several visits, stops suggesting a record, topic, or search you marked as not interested for 90 days, and gives records you left within a few seconds less weight than records you read. It is separate from the abuse-prevention counters described above and is not used to throttle or suspend accounts. Within PoliData, only you can see your history, in your suggestions, in Settings, and in your account data export. Workspace owners and administrators cannot see it. We do not share it with other users except as the aggregate count described next, sell it, use it for advertising, or use it to train AI models. Suggestions show current record titles and respect your current access, so if you lose access to a country, history for that country is no longer shown.

A Popular suggestion shows a record that people in at least five different organizations opened in the last 14 days, with only the number of organizations. It never shows who opened the record or which organizations did, and a record opened by fewer than five organizations is never shown this way. Your views count toward it only while personalization and suggestion engagement are on and after you have accepted the October 6, 2026 (2026-10-06) or a later version. Popular suggestions are shown whether or not your own personalization is on.

Each user's history is limited to the 500 most recent opened records and searches, the 1,500 most recent suggestions shown, used, or timed, and the 300 most recent not-interested choices. Repeating the same search, opening the same record, or seeing or using the same suggestion within 30 minutes updates the existing entry instead of adding a new one, and time on a record page is added to its entry. Entries older than 90 days are deleted automatically, and all history is deleted when your account is deleted.

You can manage personalization in Settings under Search & personalization, or in Explore under Personalize. Settings also lists the searches you ran and the records you opened, and you can remove any of them: removing a search forgets every time you ran it and the suggestions built from it, and removing a record forgets your views of it and your time on its page. Switching personalization off stops recording and immediately deletes your history; Explore then shows general parliamentary activity instead of personal suggestions. You can also switch off recently opened records, recent searches, or suggestion engagement separately, which deletes that part of your history. Switching off suggestion engagement also stops your views from counting toward Popular suggestions until you switch it on again; switching off recently opened records also stops and deletes time on record pages; and switching off recent searches also deletes the search text kept with suggestions. You can switch off suggestions based on topics you read most, add or remove your own topics, or choose Clear history at any time. When you first sign in, we ask which topics interest you; the ones you pick, if any, become your Explore topics, exactly as if you had added them in Explore. Topics you pick or add are kept with your settings until you remove them or delete your account.

Separately from personalization, and whether or not it is on, the text of a search, including an Explore topic you open, may be sent to OpenAI, our AI provider, to compute a semantic representation (an embedding) used to find related records and, for short plain-word searches, to suggest related Polish and Dutch search terms. Search embeddings are kept only in temporary server memory and are not stored with your account. Suggested search terms are cached for up to 7 days under a one-way hash of the normalized search text, so a repeated search does not need a new request; this cache is not linked to any account.

Optional Product Analytics

Umami Cloud analytics is disabled until you choose Allow analytics. Rejecting optional analytics does not restrict any PoliData feature. You can change or withdraw your choice at any time in Settings or through the Cookie Notice. Withdrawal stops future collection and does not affect prior lawful processing. Your browser keeps your choice; when you are signed in, we also save it with your account, with the version of this notice you made it under and when, so it applies on every device you sign in on. It is deleted with your account.

Umami does not set analytics cookies. It receives ordinary HTTPS request metadata and derives a session identifier from the IP address, user agent, and PoliData website identifier. For signed-in users, PoliData may send keyed, pseudonymous account and organization aliases together with role and default-jurisdiction categories. We do not send names, email addresses, raw account or organization IDs, legislative-item IDs, URL query strings or fragments, search text, or Web Vitals to Umami. Explore and Cmd+K search events record only the type of suggestion or result selected, a result-position range, and the country. Pseudonymous data remains personal data where PoliData can associate it with an account.

Recipients and Processors

Provider

Purpose and data

Cloudflare

DNS, edge delivery, and security, including Turnstile bot challenges on sign-up and account-email forms; IP address, browser signals, and request metadata

Mailjet

Transactional email, including security emails, which can contain the time, IP address, and browser of a sign-in; recipient, message content, and delivery metadata

Chatwoot

Support chat when used; account identity, organization, role, and support content

Stripe

Hosted Checkout, card collection, subscription administration, invoicing, fraud prevention, and payment processing. Stripe acts as our processor for some services and may act as an independent controller for its own legal, security, and payment-network purposes, as described in Stripe's privacy materials.

OpenAI

AI processing; the text of searches, to interpret them as described above, and public legislative material, to generate summaries, short translations, topic classifications, and research for articles PoliData publishes

DeepSeek

AI drafting, editing, and translation of articles and social posts that PoliData publishes; public legislative material and PoliData's own editorial drafts, instructions, and research sources chosen by our staff. No account, workspace, search, or other customer data is sent to DeepSeek.

Umami Cloud

Optional product analytics; page, device, session, event, and pseudonymous account metadata described above

Infrastructure providers

Hosting, databases, backups, monitoring, and service operation

Google and Microsoft are not our processors. If you choose to sign in or sign up with one of them, it provides that sign-in to you as an independent controller under its own terms and privacy policy, as described in Sign-in and Account Security above.

We may also disclose data to professional advisers, competent authorities, or another organization involved in a merger, financing, acquisition, or sale, subject to applicable confidentiality and data-protection duties. We do not sell personal data.

International Transfers

Some providers, including Umami Software, Inc. and OpenAI, are established in the United States or may process data outside the European Economic Area. For transfers to these providers, where required, we use an applicable adequacy decision, approved Standard Contractual Clauses, or another lawful safeguard. We do not transfer your data to Google or Microsoft: when you sign in or sign up with one of them, your browser deals with it directly, and its own privacy policy explains where it processes data.

DeepSeek is operated by Hangzhou DeepSeek Artificial Intelligence Co., Ltd. and processes the material we send it in the People's Republic of China. There is no adequacy decision for China, and no Standard Contractual Clauses are currently in place with DeepSeek. We therefore limit what DeepSeek receives to public legislative information, which can include public officials' names and official activity, and editorial drafts and research material chosen by PoliData staff. DeepSeek never receives account, workspace, search, or other customer data.

Contact privacy@getpolidata.com for information about safeguards relevant to a particular transfer.

Retention

Account and workspace data is kept while the account is active and during the documented 30-day workspace recovery period. PoliData does not currently delete inactive accounts automatically: an account and its data stay until you delete the account, your workspace removes you, or the workspace is deleted. Current operational schedules retain email-delivery events for 90 days; in the workspace audit log, routine sign-in and session events for 90 days and every other event, including changes to security settings, for 365 days; platform-admin audit logs for 365 days; notification rows for 180 days, pending email dispatch records for 30 days after completion, terminal outbox events for 7 days, GDPR operation logs for 1095 days, and VictoriaLogs monitoring data for 30 days. Routine sign-in events are kept for 90 days because that is long enough to look into unusual activity on an account and matches how long a device counts as known for new sign-in emails; changes to security settings are kept for a year so that an account takeover found late can still be traced to what was changed. GDPR operation logs show that an export or erasure was carried out; they keep the account's ID and a keyed one-way hash of its email address, not the address. Sign-in sessions are deleted 90 days after they end; sign-in challenges, sign-ups started with Google or Microsoft, pending email changes and connections, and undo links a day after they are used or expire; and records of failed second steps after 30 days. Your authenticator secret, recovery codes, passkeys, connected sign-in methods, profile photo, and interface preferences are kept until you remove them or delete your account. When you delete your account or are removed from a workspace, the workspace audit log keeps its entries about you until their period ends, but with your email addresses replaced by "erased user" and without the IP address and browser of the events you performed. Private search history, including suggestion engagement, is deleted after 90 days and limited to 500 opened records and searches and 1,500 engagement entries per user, and cached AI search-term suggestions expire after 7 days. Umami Cloud analytics is kept for up to 6 months under the current plan. Trial-eligibility claims and provider event identifiers are retained for as long as reasonably needed to enforce the one-trial rule, resolve disputes, and prevent abuse; raw payment-card details are not held by PoliData. Abuse-prevention counters expire automatically shortly after the window they measure: within about two days for daily counters, and about one month for monthly API counts and quotas. Research Access applications are kept while the grant is active and for 12 months after it ends or is rejected, to enforce the one-account-per-person rule. Legal, tax, dispute, security, accounting, and backup records may be retained longer where reasonably necessary or required by law.

Your Rights

Subject to applicable law, you may request access, rectification, erasure, restriction, portability, and information about processing, or object to processing based on legitimate interests. Where processing is based on consent, you may withdraw it at any time. You can object to search personalization at any time by switching it off in Settings or in Explore, which stops recording and deletes your search history. Signed-in users can download an account export, which includes search history, sign-in sessions (with the hash of the device cookie), security events, failed second steps, two-step verification and recovery-code use, passkeys, connected sign-in methods, pending email changes, the profile photo, and interface preferences, and request deletion from Settings. Deleting your account also deletes its sessions, two-step verification, passkeys, connected sign-in methods, profile photo, and preferences, and removes your details from the workspace audit log as described under Retention; for the owner of a personal workspace, this happens at the end of the 30-day recovery period. Email privacy@getpolidata.com to exercise a right. We may need to verify your identity and will respond within the legally required period.

You may lodge a complaint with the Polish supervisory authority, the Urzad Ochrony Danych Osobowych (UODO), or another competent supervisory authority. You also have the right to an effective judicial remedy under applicable law.

Security

We use technical and organizational measures designed to protect data, including encrypted transport, access controls, password hashing, server-side sign-in sessions you can review and end, which last 12 hours unless you choose to stay signed in, optional two-step verification and passkeys, encrypted authenticator secrets, protected session handling, audit logging, backups, and monitoring. No online service can guarantee absolute security. Please report suspected account compromise to support@getpolidata.com promptly.

Public Data, Children, and Automated Decisions

Public-official data comes from official legislative and transparency sources. Officials or their representatives may request correction of inaccurate information at privacy@getpolidata.com. PoliData is a professional research service not directed to children under 16. We do not use account data for solely automated decisions that produce legal or similarly significant effects. Automated abuse controls may throttle requests or temporarily suspend an account whose activity shows automated extraction. A person reviews any suspension on request, and always before it becomes permanent. Automated security controls may pause sign-in attempts after repeated failures, or lock the second step until you reset your password by email. Search personalization only changes which suggestions you see and in what order.

Changes to This Policy

We version material changes and will provide reasonable advance notice when a change materially affects account holders, unless an urgent legal or security change requires earlier effect. We announce a material change in PoliData and by email to verified account addresses before it takes effect. When a materially revised policy takes effect, we ask account holders to confirm they have read it before they continue using the workspace; exporting or deleting your data never needs it. Confirming is an acknowledgement, not consent: none of the processing described here relies on it. Optional analytics consent is requested separately and is not bundled with acceptance of the Terms.