Poliogo · Legal
Data Processing Addendum
Effective date: September 10, 2026
Last updated: September 11, 2026
This Data Processing Addendum ("DPA") forms part of the Terms of Service between you ("Customer", "you") and Poliogo ("Poliogo", "we", "us"). It governs our processing of personal data on your behalf and is designed to satisfy Article 28 of the EU General Data Protection Regulation and of the UK GDPR.
You do not need to sign anything for this DPA to apply. It takes effect automatically when you accept the Terms of Service, for as long as we process personal data on your behalf. If your organisation requires a countersigned copy for its records, write to us and we will execute one.
Where this DPA and the Terms of Service disagree about the processing of personal data, this DPA wins.
1. Who this agreement is between
- Processor: Poliogo, operator of poliogo.com
- Established in: Israel
- Contact for data protection questions, this DPA and sub-processor notices: support.polio.ai@gmail.com
Poliogo is not a law firm. This DPA is a contract we offer, not legal advice about your obligations.
2. Which of us decides, and which of us processes
You are the controller. You decide which repositories to connect, which of your end users see a consent banner or a rights-request form, and what happens to the documents we generate. We are the processor: we act on your instructions and for no purpose of our own.
Two things sit outside this DPA because we are the controller for them, not your processor:
- Your own account data — the name, email address, billing records and support messages belonging to the person who signed up. We decide how that is handled, and our Privacy Policy governs it.
- Our marketing pages. Analytics run on our public website only. They never run inside the signed-in product and never on a Trust Center served from your domain.
Under the CCPA as amended by the CPRA we are a service provider. We do not sell or share personal information, we do not retain, use or disclose it outside the direct business relationship, and we do not combine it with personal information from any other source.
3. Your instructions
We process personal data only on your documented instructions. Your instructions are: this DPA, the Terms of Service, and the settings and actions you take in the product — connecting a repository, running a scan, publishing a Trust Center, enabling a rights-request form.
We will tell you if we believe an instruction breaches the GDPR or another data protection law, unless we are legally barred from saying so. We will not process the personal data described here for any other purpose, and we will not use it to train machine-learning models.
If a law requires us to process personal data beyond your instructions, we will tell you before we do so unless that law forbids it on important grounds of public interest.
4. What we process, and why
Subject matter: provision of the Poliogo compliance platform — scanning a connected codebase, generating and maintaining legal documents, detecting drift, and operating the consent and rights-request surfaces you publish.
Duration: for as long as your account is open, plus the deletion windows in section 13.
Nature and purpose of processing: collection, transient analysis, storage, organisation, retrieval, disclosure to the sub-processors in section 8, and erasure — for the sole purpose of delivering the service you subscribed to.
4.1 Categories of data subject
| Category | Who they are |
|---|---|
| Your personnel | People whose details appear incidentally in a connected repository — commit authors, addresses in a comment or a .env.example, names in a test fixture |
| Visitors to your product | People who are shown a consent banner published through Poliogo and who accept, reject or configure it |
| Rights requesters | People who submit an access, deletion or correction request through a rights-request form you published |
4.2 Types of personal data
| Where it comes from | What we process | What we keep |
|---|---|---|
| Connected repositories | Dependency manifests, source text, .env.example, edge and serverless configuration — including any personal data those files happen to contain | Nothing. See section 5. |
| Consent records | An anonymous identifier minted by the visitor's own browser, the categories they chose, the policy version they were shown, their timestamp and ours, and a salted SHA-256 hash of their IP address | The record, as your proof of consent under GDPR Art. 7(1) |
| Rights requests | Full name, email address, the type of request, and anything the requester writes in the description field | The request, until you resolve it and the retention window in section 13 elapses |
| Deployment connections | Project names, production URLs and environment variable names | The names only. Values are never requested and never stored. |
We do not knowingly process special category data under GDPR Art. 9, criminal conviction data under Art. 10, or children's data. If such data reaches us inside repository content it is subject to section 5 and is never persisted.
A note on IP addresses in consent records. The raw address is never written to our database. It is hashed at the edge together with a per-project salt, which means the digest cannot be reversed to an address and cannot be used to link the same visitor across two different customers' websites.
5. Your source code
This is the clause most customers are here for, so it is stated plainly.
We do not persistently store your source code. Repository files are read into memory, matched against a library of vendor and endpoint signatures, and discarded when the request ends. They are never written to disk or to object storage. No table in our database has a column capable of holding file contents.
What survives a scan is the fingerprint: a list of the third-party services we detected, such as "Stripe", "Supabase" or "OpenAI". That list is what your documents are assembled from, and it is all that persists.
Any personal data that happens to sit inside a scanned file is therefore processed transiently and never retained. We do not read repositories you have not selected, and we never read the value of a secret.
6. Confidentiality
Everyone we authorise to process personal data under this DPA is bound by a duty of confidentiality that survives the end of their engagement, and is granted access only to what their role requires, on the principle of least privilege.
7. Security measures
We implement and maintain the technical and organisational measures below, taking into account the state of the art, the cost of implementation, and the risk to data subjects, as GDPR Art. 32 requires.
| Measure | What we do |
|---|---|
| Encryption in transit | TLS 1.3, with TLS 1.2 as the minimum version we accept. TLS 1.0 and 1.1 are refused. HTTP Strict Transport Security is set on every response with a one-year max-age. |
| Encryption at rest | Data at rest is encrypted by our infrastructure providers. |
| Scanner scope boundaries | Repository access is granted through a read-scoped application installation limited to the repositories you select. Deployment connections read project metadata and variable names only. |
| Data minimisation by design | Source code is never persisted; IP addresses in consent records are hashed at the edge before storage; environment variable values are never requested. |
| Credential handling | Provider tokens are sealed server-side and are never exposed to a browser. Account passwords are stored only as one-way hashes. |
| Access control | Access to production systems is limited to the people who need it, on the principle of least privilege. |
| Input validation | Input is validated server-side before it is stored. |
| Logging and auditability | Every document change, approval and publication is recorded with actor and timestamp. Records are appended rather than edited in place, and the history is exportable. |
| Incident response | A documented process for detecting, escalating and reporting personal data breaches. See section 10. |
| Resilience and restoration | Backups sufficient to restore availability and access to personal data in a timely manner after an incident. |
We may update these measures as the service evolves, but we will not reduce the overall level of security during the term of this DPA.
We hold no SOC 2 or ISO 27001 report. We would rather say so here than let a certification be inferred from silence. If that changes, this section will name the report and how to obtain it.
8. Sub-processors
You give us general written authorisation to engage sub-processors. Every sub-processor is bound by a written contract imposing data protection obligations no less protective than those in this DPA, and we remain fully liable to you for their performance.
Our current sub-processors are:
| Sub-processor | Legal entity | What it does for us | Where it processes |
|---|---|---|---|
| Cloudflare | Cloudflare, Inc. | Edge infrastructure — CDN, DNS, security filtering, edge compute, the platform database, and the AI model that drafts optional clause suggestions from customer-typed notes | Edge locations worldwide |
| Firebase | Google LLC | Authentication, account metadata storage and push messaging | United States |
| PostHog | PostHog, Inc. | Telemetry on our public marketing pages only — never inside the signed-in product, never on your Trust Center | European Union |
| PayPal | PayPal (Europe) S.à r.l. et Cie, S.C.A. | Subscription billing and payment processing | European Union and United States |
| Groq, Inc. | Groq, Inc. | Drafts the same optional clause suggestions when Cloudflare is unavailable; receives the typed notes, the detected service list and multiple-choice answers, never source code | United States |
Each sub-processor above that receives clause-drafting inputs is barred by its written terms from using them to train or fine-tune a model.
Google LLC (Gemini API) and OpenRouter, Inc. served the clause-drafting step from the date that feature shipped until September 11, 2026, and were listed here on that date. They were removed the same day and receive nothing. Because they were engaged before this list named them, the 30-day objection window in the next paragraph runs from September 11, 2026 for the change described in this section.
We will give you at least 30 days' notice, by email to your account address, before adding or replacing a sub-processor. If you object on reasonable data protection grounds within those 30 days, we will work with you in good faith to find an alternative. If we cannot, you may terminate the affected part of the service and receive a pro-rata refund of prepaid fees for the unused period.
9. Helping you answer your users
If a data subject contacts us directly about data we process on your behalf, we will not respond substantively. We will tell them to contact you, and forward the request to you without undue delay.
Taking into account the nature of the processing, we will assist you by appropriate technical and organisational measures — insofar as this is possible — in meeting your obligation to respond to requests under Chapter III of the GDPR. The rights-request queue in your dashboard is the primary means by which we do so: it surfaces every request submitted through a form you published, together with the export and deletion tools needed to act on it.
10. Personal data breaches
We will notify you of a personal data breach affecting personal data we process on your behalf without undue delay, and in any event within 72 hours of becoming aware of it.
The notification will describe, as far as we know it at the time: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed to address it, and a contact point for more information. Where we cannot provide all of it at once, we will provide it in phases without further undue delay.
We will not delay a notification in order to complete an investigation first.
11. Impact assessments and prior consultation
Taking into account the nature of the processing and the information available to us, we will provide reasonable assistance with your data protection impact assessments under GDPR Art. 35 and any prior consultation with a supervisory authority under Art. 36.
12. International transfers
Poliogo is established in Israel, which benefits from a European Commission adequacy decision (Decision 2011/61/EU). Personal data transferred from the EEA to us on that basis does not require an additional transfer mechanism.
Where personal data is transferred out of the EEA, the United Kingdom or Switzerland to a country without an adequacy decision — for example to a sub-processor in the United States — the transfer is made under one of:
- the European Commission's Standard Contractual Clauses (Decision 2021/914), which are incorporated into this DPA by reference and which we enter into on your behalf with the relevant sub-processor;
- the UK International Data Transfer Addendum to those clauses, where UK data is involved; or
- the sub-processor's certification under the EU–US Data Privacy Framework and its UK and Swiss extensions.
Where the Standard Contractual Clauses apply, Module Three (processor to processor) governs, you are the data exporter, and we assess the destination country's laws before transferring. Section 8 supplies the Annex I(B) description of the transfer, section 4 the categories of data and data subjects, and section 7 the Annex II technical and organisational measures.
13. Deleting and returning your data
You can export your documents, their full revision history and your consent and rights-request records from your dashboard at any time during the term.
When your account is closed, or on your written request, we will delete the personal data we process on your behalf. Account data is deleted within 30 days of closure. Content you uploaded is removed from backups within 30 days of deletion. Server and security logs age out on a rolling 90-day cycle. Consent records are kept for as long as your project is active, because they are your proof of consent, and are deleted with the project.
Source code needs no deletion clause: under section 5 it is never stored in the first place.
We will retain personal data beyond these windows only where a law requires it, and in that case we will keep processing it solely for the purpose that law prescribes, and continue to protect it under this DPA.
14. Audits and evidence
We will make available to you the information necessary to demonstrate compliance with GDPR Art. 28 and to allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.
In practice, that means:
- First, documentation. Our published security documentation, this DPA and our sub-processor list are intended to answer most assessments without a call. Send us a vendor questionnaire and we will complete it.
- Then, an audit. If documentation does not settle the question, you may audit us once in any 12-month period on 30 days' written notice, during business hours, without unreasonable disruption, and subject to confidentiality. You bear your own costs and your auditor's.
- Immediately, after a breach. The 12-month limit does not apply following a personal data breach affecting your data, or where a supervisory authority requires an audit.
15. Liability
Each party's liability under this DPA is subject to the limitations and exclusions of liability in the Terms of Service. Nothing in this DPA limits any right a data subject has under applicable data protection law, or either party's liability to a supervisory authority.
16. Term
This DPA takes effect when you accept the Terms of Service and continues for as long as we process personal data on your behalf. Sections 6, 13, 14 and 15 survive its termination.
17. Changes to this DPA
We update this DPA when what we do changes. The date at the top always reflects the current version. If a change materially reduces your rights or our obligations, we will give you at least 30 days' notice by email before it takes effect, and you may terminate the affected part of the service during that period if you do not accept it.
18. Contact
- Email: support.polio.ai@gmail.com
- For: this DPA, a countersigned copy, sub-processor notices, vendor security assessments, and data protection questions generally