Data Processing Agreement
The agreement under Article 28(3) GDPR between you (controller) and plugwith.me (processor). It covers every piece of personal data we handle on your behalf: the click events from your links, the logins you create for your team, and the personal data you put into your link pages. It includes the transfer clauses, the full annexes, and the country-specific terms. In German law this document is the Auftragsverarbeitungsvertrag (AVV).
This agreement is already in force. You do not have to sign anything. It is part of the Terms of Service and applies on every plan, including the free plan, from the moment you create your first link. It is the complete agreement, not a summary — Annexes I to IV are the processing description, the security measures, the subprocessor list and the non-EU terms. If your compliance process needs a countersigned PDF, write to info@plugwith.me and we will send one within five business days, free of charge.
Which version applies to you. Version 3.2 was published on 21 August 2026 and takes effect on 21 September 2026. The gap is the 30 days' notice section 18.1 and section 2.3 of the Terms promise before a change binds an existing account — most of version 3.0 to 3.2 clarifies or adds protections, but section 7.8 places a new obligation on you, and a new obligation is exactly what a notice period is for. Until then, version 2.2 continues to govern accounts that existed on 21 August 2026. Accounts created on or after that date accept this version at signup, so it binds them from the day they sign up. You can accept it early from the dashboard; you can object in text form to info@plugwith.me before the effective date, and either party may then terminate at that date with a pro-rata refund.
1. Who this agreement is between
1.1 This agreement ("DPA") is between:
- the natural or legal person holding an account at plugwith.me, as controller ("you", "Customer"); and
- Eray Yilmaz, sole proprietor trading as plugwith.me, Europaring 90, 53757 Sankt Augustin, Germany, as processor ("we", "Provider").
1.2 Subject matter. We host short links and link-in-bio pages for you, serve them to your visitors, and record traffic statistics about them. Providing that service is the subject matter of the processing.
1.3 Duration. This DPA starts when you first create a link and runs for as long as we process personal data for you. Sections 12, 15, 16 and 18 survive its end.
1.4 Who determines what. You determine the purposes of the processing. You also determine the essential means: which links exist, where they point, which countries are blocked, which pixels run, who on your team gets a login. We determine the non-essential technical means — the database layout, the classification logic, the caching, the field names — as any processor does under Article 28. Deciding how to implement your instruction does not make us a controller.
1.5 Precedence. Where documents conflict: the Standard Contractual Clauses in section 14 come first, then this DPA, then the Terms of Service. The Privacy Policy describes our own controller processing and does not change this DPA.
1.6 Form. This DPA is concluded electronically. Article 28(9) GDPR allows electronic form, and neither party needs to sign it for it to bind. Your own supplier terms, procurement DPA or security questionnaire do not apply and do not amend this DPA unless we accept them in a separate document signed by us.
2. What this covers — and what it does not
2.1 Covered ("Customer Personal Data"). Three streams, all described in Annex I:
- Visitor click events — what we record when someone opens one of your links.
- Team logins — the people you give access to your account (Agency plan and above).
- Personal data inside your content — creator names, photos, background videos, profile text, destination URLs and anything else you type or upload.
2.2 Not covered — our own controller data. Your account, your billing data and your support emails are processed by us as controller, not as processor. That is covered by the Privacy Policy, not by this DPA. Stripe is an independent controller for payment data, not our subprocessor for it.
2.3 Not covered — marketing pixels. If you switch on a Meta, Google, TikTok or Snap pixel, that pixel runs in the visitor's browser and sends data straight to that provider. Nothing passes through our systems, we get nothing back, and we have no contract with them for it. For that processing you are the controller — in some setups jointly with the provider under Article 26 GDPR — and you need your own arrangements. We are not a processor, controller or joint controller for it. See Cookie Policy § 3.
2.4 Not covered — where your links point. Once a visitor leaves our page, the destination site processes their data on its own account. We have no control over it and are not a processor for it.
2.5 Purely private use. If you use the Service for a purely personal or household activity, Article 2(2)(c) GDPR means the GDPR does not apply to your processing and no processor relationship arises. This DPA then has no subject matter. It applies as soon as your use is professional or commercial, however small.
2.6 If you are yourself a processor. Where you act for someone else (for example, an agency acting for a creator), you warrant that you are authorised to appoint us as subprocessor on your client's behalf and to give us the instructions in this DPA. Module Three of the Standard Contractual Clauses then applies (section 14.2).
3. Your instructions
3.1 We process Customer Personal Data only on your documented instructions, including for transfers to a third country, unless Union or member-state law requires otherwise. If a law requires it, we tell you before processing, unless that law forbids us from telling you on important grounds of public interest.
3.2 What counts as an instruction. Together, these are your complete documented instructions: this DPA, the Terms of Service, and everything you configure in the dashboard — the links you create, the settings you choose, the team logins you issue, the exports you ask for, and the support requests you send. Nothing else is needed for an instruction to be documented.
3.3 Extra instructions. Any instruction beyond that must be sent in text form to info@plugwith.me. Where an instruction needs work the Service does not provide as standard, we may charge a reasonable fee, agreed with you in advance, and we may set a reasonable deadline.
3.4 Unlawful instructions. If we believe an instruction breaches the GDPR or other Union or member-state data protection law, we tell you without undue delay. We may suspend that instruction until you confirm or change it. Suspending it is not a breach of the Terms and does not entitle you to a refund or to damages.
3.5 Our own legal duties are not your instruction. Removing illegal content, answering a valid order from a court or authority, and meeting our duties under the Digital Services Act are acts we perform as controller under a legal obligation. Doing them is not a breach of this section. Our notice-and-action mechanism is at plugwith.me/report.
4. What we never do
4.1 We do not process Customer Personal Data for our own purposes, apart from the anonymous statistics in section 5.
4.2 We do not sell it, share it for cross-context behavioural advertising, rent it, or use it for advertising of any kind.
4.3 We do not combine it with personal data we hold from any other source.
4.4 We do not use it to train, fine-tune or evaluate any machine-learning model, and we require the same of every subprocessor (section 6).
4.5 We run no analytics vendor, no CRM, no session recording, no advertising network and no data broker on any surface that touches Customer Personal Data. There is no third-party script anywhere on this service.
5. Anonymous statistics
5.1 You instruct and permit us to produce anonymous, aggregated statistics from Customer Personal Data — for example, how many taps arrive from inside an in-app browser, split by app and device class. We may use and publish those statistics, including for research, security and marketing, during and after the term.
5.2 What "anonymous" means here. Only counts and percentages leave the aggregation. No output identifies, names or allows the identification of a visitor, of you, of one of your links or of one of your destinations. Small groups are not published: a bucket must contain at least 50 records before it is reported separately, and a whole sample must contain at least 2,000 records before any figure from it is published at all. Buckets below the floor are merged into an "other" line.
5.3 We do not attempt, and do not permit anyone else to attempt, re-identification of the underlying records. Recital 26 GDPR applies to the result: once anonymous, it is no longer personal data and no longer subject to this DPA.
5.4 You can object to the use of your account's data for published statistics at any time by writing to info@plugwith.me. We will exclude your links from future aggregation. Figures already published are not recalculated, because they contain nothing traceable to you.
6. No artificial intelligence in the processing
6.1 The Service contains no AI system within the meaning of Article 3(1) of Regulation (EU) 2024/1689 (the AI Act). We are neither a provider nor a deployer of an AI system in delivering it. Bot detection, device classification and geo-blocking are fixed, rule-based filters — pattern matches written by hand, with no model, no inference and no learning.
6.2 There is no automated decision-making producing legal or similarly significant effects on any individual within the meaning of Article 22 GDPR, and no profiling. A blocked bot or a geo-blocked visit is a technical filter on a request, applied on your instruction, not a decision about a person.
6.3 No Customer Personal Data is used for AI training, fine-tuning, evaluation or retrieval augmentation, by us or by any subprocessor.
6.4 If any of this changes, we will notify you under the subprocessor procedure in section 11.2 before the change takes effect, and you may object on the same terms.
7. Your obligations and warranties as controller
This section is what lets us process lawfully. Each point is something only you can guarantee.
7.1 Lawfulness. You are responsible for the lawfulness of the collection and of your instructions. You warrant that you have a valid legal basis under Article 6 GDPR for every processing operation you instruct, including the click statistics and any pixel you enable, and that you meet your own information duties towards visitors under Articles 12 to 14.
7.2 Consent. Where consent is the basis — in particular for marketing pixels, and for any storage or access on the visitor's device that is not strictly necessary — obtaining, recording and being able to prove that consent is your duty. Our consent banner is a technical aid: it stores the visitor's choice in that visitor's own browser and sends us no record of it, so we cannot supply you with evidence of consent and do not claim to.
7.3 No special categories. You must not instruct processing of data in the special categories of Article 9 GDPR, of data on criminal convictions under Article 10, or of data relating to children. The Service is built for adults and is not designed, secured or priced for any of that. If you do it anyway, you do it outside your instructions and section 16.4 applies.
7.4 Uploads are public. Images and background videos you upload are stored in publicly readable buckets, because they have to be fetched by every visitor's browser and used as share previews. Anyone who has the URL can open them. You warrant that you hold the rights and, where a person is shown, the consents needed to publish them, and you must not upload anything you would not publish on an open web page.
7.5 Your team. If you create logins for your staff, you are their controller. You must have a legal basis for it, tell them their data is processed here, choose passwords that meet the rules the dashboard states, hand them over securely, and remove people who leave. We cannot know when someone leaves your company; only you can.
7.6 Your account details. Keep your account email address current. It is where breach notices under section 12 and subprocessor notices under section 11 are sent. A notice sent to the address on your account counts as delivered.
7.7 You have assessed our measures. You confirm that you have reviewed Annex II and consider the measures appropriate to the risk of the processing you instruct, as Article 28(1) GDPR requires of you when choosing a processor. If your processing needs a higher level of protection than Annex II describes, do not instruct it here; tell us instead, and we will say whether we can meet it and on what terms.
7.8 Indemnity. You will hold us harmless against third-party claims, fines and reasonable legal costs to the extent they arise from (a) your breach of this DPA or of your duties as controller, (b) an instruction that infringes data protection law, (c) content, uploads or destinations you supplied, or (d) processing you carried out outside these instructions. This does not apply to the extent the claim is caused by our own breach of this DPA, by our negligence, or by processing we carried out contrary to your lawful instructions. We will notify you of any such claim without undue delay, will not settle it without your consent (not to be unreasonably withheld), and will give you reasonable opportunity to take over the defence at your cost.
8. Confidentiality
8.1 Every person we authorise to process Customer Personal Data is bound by a confidentiality obligation that survives the end of their engagement, or is under an appropriate statutory duty of confidence.
8.2 Access is limited to the people who need it to deliver the Service. Today that is the proprietor and any staff or contractor expressly authorised in writing.
8.3 Everyone acting under our authority processes Customer Personal Data only on our instructions, as Article 32(4) GDPR requires.
9. Security
9.1 We implement and maintain the technical and organisational measures in Annex II. They meet Article 32 GDPR having regard to the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing as well as the risk to individuals.
9.2 We may change those measures as technology and threats change, provided the overall level of security is not reduced. Material changes are published in Annex II with a new date.
9.3 Annex II describes the measures for the Service as offered. It is not a promise of measures a specific plan does not include, of a bespoke configuration, or of any control we have not described there.
9.4 Security within your own sphere is yours: your credentials, your team's credentials, your second factor, your devices, the destinations you link to, and the pixels you enable. We enforce a second factor at our API once you enable it, but we cannot enable it for you.
10. Help with your own duties
10.1 Requests from individuals. Taking into account the nature of the processing, we help you meet requests under Chapter III GDPR by appropriate technical and organisational measures, so far as that is possible. Because the click events contain no identifier for any visitor, we are technically unable to find, export, correct, restrict or delete the records of one specific visitor inside them. We will confirm that in writing to you or to a supervisory authority on request. This is a consequence of data minimisation, not a refusal.
10.2 For the data we can locate — your team logins and your content — the dashboard gives you direct control, which is normally faster than asking us.
10.3 If a visitor contacts us. We do not answer on your behalf. We pass the request to you without undue delay and tell the person we have done so.
10.4 Articles 32 to 36. Taking into account the nature of the processing and the information available to us, we help you with security, breach notification, data protection impact assessments and prior consultation. This DPA, its annexes and the Privacy Policy are designed to give you what a DPIA needs; you do not have to ask for them.
10.5 Article 28(3)(h) information. We make available all information necessary to demonstrate compliance with Article 28 GDPR.
10.6 Fees. The help described above is free. Where your request goes beyond it — bespoke reports, filling in a supplier questionnaire, an unscheduled audit, forensic work beyond what section 12 requires — we may charge our reasonable time at a rate agreed in advance.
11. Subprocessors
11.1 General authorisation. You give a general written authorisation for us to engage subprocessors. Those engaged today are listed in Annex III and, in current form, at plugwith.me/subprocessors, which is the authoritative version.
11.2 Notice. We tell you in text form at least 30 days before we add or replace a subprocessor. Notice goes to your account email address; you can also subscribe a compliance mailbox at plugwith.me/subprocessors.
11.3 Objection. You may object within 30 days of that notice, on reasonable grounds relating to data protection, stating them. We will then make reasonable efforts to offer the Service without that subprocessor, or to propose a change that resolves your concern. If we cannot within a reasonable period, either party may terminate the affected part of the Service on 30 days' notice, and we refund prepaid fees for the unused period pro rata. That refund is your sole remedy for an objection. Using the Service after the effective date without objecting counts as approval.
11.4 Flow-down and liability. We impose on every subprocessor, by contract, data protection obligations that are in substance the same as ours here — in particular sufficient guarantees of appropriate technical and organisational measures. Where a subprocessor fails to meet its data protection obligations, we remain fully liable to you for its performance (Article 28(4) GDPR).
11.5 Emergency replacement. If a subprocessor has to be replaced at short notice for security or continuity reasons, we may do it immediately and will tell you without undue delay, with reasons. Your right to object then applies afterwards.
11.6 Not subprocessors. A vendor that never receives Customer Personal Data is not a subprocessor. That includes the pixel providers in section 2.3, the destination sites in section 2.4, and our own mailbox and accounting providers, which touch only our controller data.
12. Data breaches
12.1 We notify you without undue delay and in any event within 48 hours of becoming aware of a personal data breach affecting Customer Personal Data. That gives you a day to meet your own 72-hour deadline under Article 33 GDPR.
12.2 "Becoming aware" means having a reasonable degree of certainty that a security incident has led to personal data being compromised, in line with EDPB Guidelines 9/2022. A period of investigation to reach that certainty is not delay.
12.3 Content. The notice goes to your account email address and states, so far as known: the nature of the breach; the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed; and a contact point. Where we cannot give everything at once, we give it in phases without further undue delay.
12.4 Who notifies whom. We do not notify supervisory authorities or data subjects on your behalf unless you instruct us to and we agree. We help you with any notification you make.
12.5 Not an admission. Notifying you is not an acknowledgement of fault or liability.
12.6 Costs. Investigation, containment and notification on our side are at our cost. Forensic work, reports or support you request beyond that is chargeable under section 10.6, unless the breach was caused by our breach of this DPA.
13. Audits
13.1 We make available all information necessary to demonstrate compliance with Article 28 GDPR, and allow for and contribute to audits, including inspections, by you or an auditor you mandate.
13.2 How this works in practice. In the first instance we satisfy it with this DPA and its annexes, the current subprocessor list, our security page at plugwith.me/security, and the independent audit reports and certifications of our subprocessors where we are allowed to pass them on. Where that is genuinely not enough to demonstrate compliance, you may audit on site or remotely, subject to all of the following:
- once per calendar year;
- at least 14 days' written notice;
- during normal business hours, without unreasonably disrupting our operations;
- under an appropriate confidentiality agreement;
- the auditor must not be a competitor of ours;
- at your cost, including our reasonable time at a rate agreed in advance;
- no access to data of other customers, to our source code, or to credentials.
13.3 Extra audits are allowed where a supervisory authority requires one, or after a personal data breach affecting your data. Those are not counted against 13.2 and, in the breach case, are at our cost.
13.4 Data centres. We do not operate any, so we cannot grant physical access to one. For our subprocessors we pass on the reports and certifications they make available.
14. International transfers
14.1 Where the data is. Customer Personal Data is stored in the United States, in AWS region us-east-2 (Ohio), by our subprocessor Supabase. Pages are served from a global edge network, so processing also happens wherever the visitor is. Netlify and Stripe are certified under the EU–US Data Privacy Framework. Supabase is not, so that transfer rests on the Clauses below.
14.2 Standard Contractual Clauses. Where Customer Personal Data is transferred to a country without an adequacy decision, the parties incorporate by reference the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914, as follows:
- Module Two (controller to processor) where you are a controller, and Module Three (processor to processor) where you are yourself a processor;
- Clause 7 (docking clause): applies;
- Clause 9: Option 2, general written authorisation, with the 30-day notice period in section 11.2;
- Clause 11: the optional independent dispute-resolution body is not used;
- Clause 17: governed by the law of Germany;
- Clause 18(b): the courts of Sankt Augustin, Germany;
- SCC Annex I.A, I.B and I.C are populated by parts A, B and C of Annex I below; SCC Annex II is populated by Annex II below; the list of subprocessors under Clause 9 is Annex III below.
14.3 United Kingdom. Where UK GDPR applies, the parties incorporate the International Data Transfer Addendum to the EU SCCs issued by the Information Commissioner (version B1.0). Tables 1 to 3 are populated by this DPA and its annexes; Table 4 selects "neither party" as the party that may end the Addendum under section 19; the ICO is the competent authority.
14.4 Switzerland. Where the Swiss FADP applies, the SCCs apply with references to the GDPR read as references to the FADP, "member state" read so that Swiss data subjects can enforce their rights in Switzerland, and the FDPIC as competent authority.
14.5 Transfer impact assessment. We have carried one out for the transfers in Annex III. It is published in full in Privacy Policy § 7.1 and forms part of this DPA. In summary: the click events contain no IP address, no raw user agent, no cookie or device identifier and nothing linking two events by the same visitor, so a compelled disclosure would produce records that identify nobody. There is no special-category data and no content of communications. Team logins and content are a small volume of business-contact and published-content data. On that basis we consider the safeguards adequate. We will tell you without undue delay if we become unable to comply with the Clauses, and you may then suspend the transfer or terminate.
14.6 Government access. Unless legally prohibited, we will: tell you about any legally binding request from a public authority for Customer Personal Data; challenge requests that look unlawful or excessive, including under the Clauses; and disclose only the minimum permitted. We maintain no direct or indirect back door, and no authority has ever asked us for one. Where notification is prohibited, we will use best efforts to obtain a waiver and will document the request for later disclosure. We publish moderation and disclosure actions in the register linked from plugwith.me/report.
14.7 Region change. Moving the database to another region is a change of the transfer situation. We will notify it under section 11.2 before it takes effect. We are evaluating a move of the production project to an EU region, which would end the storage transfer.
15. Deletion and return
15.1 At your choice, we delete or return all Customer Personal Data when we stop providing the Service, and delete existing copies, unless Union or member-state law requires us to keep it.
15.2 The default is deletion. If you do not instruct otherwise within 30 days of termination, we delete.
15.3 Timing. Account data, team logins, link configuration and uploads are deleted from production within 30 days of termination. Raw click events are deleted by the automated retention job described in Annex I, at the latest within 90 days. Encrypted backups holding the data expire on their normal rotation, in any event within a further 90 days, and are not accessed in the meantime except to restore service.
15.4 Return. You can download your links and settings yourself from the dashboard as a JSON file, at any time and also during the 30-day window. On request within that window we supply anything else we hold for you — including your analytics — in a structured, commonly used, machine-readable format, free of charge. After the window, a restore is only possible if a backup still holds the data, and we may charge our reasonable time for it.
15.5 Legally required retention. Data we must keep by law — in particular invoices and accounting records, which German law requires us to keep for ten years — is kept and blocked from every other use.
16. Liability
16.1 Liability under this DPA follows Article 82 GDPR and, in all other respects, the liability provisions of the Terms of Service, including any cap and any exclusion of indirect and consequential loss agreed there. This DPA does not create a second, separate liability regime.
16.2 Article 82(2). As processor, we are liable for damage caused by processing only where we have not complied with obligations the GDPR directs specifically at processors, or where we have acted outside or contrary to your lawful instructions.
16.3 Rights of individuals are untouched. Nothing here limits a data subject's rights under Article 82 GDPR or under the Standard Contractual Clauses, and no allocation between us affects them.
16.4 Allocation. Between us, each party bears the part of any fine, claim or damage that corresponds to its own share of responsibility. To the extent a claim results from your instruction, your content or your breach of section 7, you bear it, and section 7.8 applies. To the extent it results from our breach of this DPA, we bear it.
16.5 No double recovery. Where the same loss could be claimed under both this DPA and the Terms of Service, it can be recovered once.
16.6 Nothing in this DPA excludes liability that cannot be excluded by law, including for injury to life, body or health, for intent, and under the German Product Liability Act.
17. Records, contact and supervision
17.1 Records. We keep the record of processing activities carried out on your behalf required by Article 30(2) GDPR, and make the entries relevant to you available on request.
17.2 Data protection contact. info@plugwith.me, Eray Yilmaz, Europaring 90, 53757 Sankt Augustin, Germany, +49 156 79 729 585. Please put "Data protection" in the subject line.
17.3 Data protection officer. We have assessed Article 37 GDPR and § 38 BDSG and are not required to designate one: our core activity is not large-scale regular and systematic monitoring — the click events carry no identifier that would allow any individual to be monitored — we process no special-category data on a large scale, and we do not employ 20 or more people on automated processing. The contact point in 17.2 answers data protection matters. If a designation becomes mandatory, we will make it and publish the details.
17.4 EU representative. Not required. We are established in the European Union, so Article 27 GDPR does not apply.
17.5 Supervisory authority. The authority competent for us is named in Annex I.C. You may always complain to the authority of your own member state.
18. Changes and general terms
18.1 Changes. We may amend this DPA where a change in the law, a decision of a supervisory authority, a court ruling or a change in the Service requires it, following the notice procedure in section 2.3 of the Terms. An amendment must never reduce the level of protection. The version and effective date at the top of this page always show what is in force; we keep the change history in the table at the end.
18.2 Governing law. German law applies, excluding the UN Convention on Contracts for the International Sale of Goods.
18.3 Jurisdiction. The exclusive place of jurisdiction is Sankt Augustin, Germany, so far as mandatory law permits and without prejudice to Clause 18 of the Standard Contractual Clauses. Where you are a consumer, the statutory rules on jurisdiction apply instead.
18.4 Severability. If a provision is or becomes invalid, the rest stays in force, and the invalid provision is replaced by a valid one that comes closest to what the parties intended.
18.5 No waiver. Not enforcing a right on one occasion does not waive it.
18.6 Assignment. You may not assign this DPA without our written consent. We may assign it to a successor in a merger, reorganisation or sale of the business, on notice to you; your right to terminate under the Terms is unaffected.
18.7 Notices. Text form (email) is enough for every notice under this DPA. Ours go to your account email address; yours go to info@plugwith.me.
18.8 Language. English is the binding version. Any translation is for convenience. Where German law prescribes a specific wording, that German wording prevails for that passage only.
18.9 Entire agreement. This DPA and the Terms of Service are the entire agreement on the processing of Customer Personal Data and replace every earlier arrangement on it, including earlier versions of this document.
Annex I — Description of the processing
A. List of parties
Data exporter / controller: the account holder, identified by the registration details in their plugwith.me account. Contact: the account email address. Activities relevant to the transfer: publishing short links and link-in-bio pages, giving team members access to the account, and reviewing traffic statistics. Role: controller (Module Two), or processor (Module Three) where acting for a third party.
Data importer / processor: Eray Yilmaz, trading as plugwith.me, Europaring 90, 53757 Sankt Augustin, Germany. Contact: info@plugwith.me, +49 156 79 729 585. Activities relevant to the transfer: hosting and serving the Customer's link pages, operating the account and its team logins, and recording aggregate traffic statistics. Role: processor.
B. Description of the processing
Three streams. Each is described separately because the data, the people and the retention differ.
B.1 Visitor click events
| Categories of data subjects | End visitors who open a URL of the form plugwith.me/<slug>, or the same page on a custom domain the Customer has connected. |
|---|---|
| Categories of personal data | Per page open and per button click: the slug; a timestamp; a coarse device class (ios, android, desktop, other); a coarse browser or in-app-browser class (e.g. safari, chrome, instagram, tiktok); an ISO 3166-1 alpha-2 country code derived at the edge from the IP address; flags recording whether bot protection or the geo-block filtered the request and why; and, for button clicks, the button label and the destination URL. |
| Held only in the request, never stored | The IP address and the full user-agent string, used to derive the country, detect bots and apply rate limits. The city, used only to render a "near <city>" badge in the page sent back to that same visitor. Neither is written to our database. Netlify holds them in its own access logs as our subprocessor. |
| Stored on the visitor's device, not by us | The consent choice for marketing pixels (browser local storage, key pw_consent, no identifier, expires) and, where an age gate is used, a per-session confirmation flag. Neither is transmitted to us. |
| Not an identifier | Analytics beacons carry a short token so that only a page we served can report a click. The token is a keyed hash of the slug and a time window. It is identical for every visitor of that page in that window, so it identifies the page, never the person. No cookie, device identifier, fingerprint, session id or account id is set or stored, and nothing links two events by the same visitor. |
| Special-category data | None is requested or intentionally processed. Slugs and destinations are chosen by the Customer, so a destination may reveal an interest in adult content; the Customer is responsible for the lawfulness of that (section 7.3). No health, biometric, genetic, political, religious or trade-union data is processed. |
| Data concerning children | None. The Service is for adults. See section 14 of the Privacy Policy. |
| Frequency | Continuous, on each request. |
| Nature of the processing | Collection, classification, structuring, storage, aggregation, retrieval for display in the Customer's dashboard, and erasure. |
| Purpose | Giving the Customer reach and click statistics for their own links, and protecting those links against automated and geographically excluded traffic. |
| Retention | 90 days for raw rows, enforced by an automated deletion job that runs daily; rows whose link no longer exists are deleted in the same run. On plans sold with a full analytics history (currently Business), raw rows are kept for the contract term instead and deleted on termination under section 15. Statistics derived from these rows are anonymous and are kept indefinitely (section 5). |
B.2 Team logins (Agency plan and above)
| Categories of data subjects | The people the Customer authorises to use its account — its employees, freelancers or agency staff. |
|---|---|
| Categories of personal data | Email address; display name, if given; role (manager, staff, viewer); active or suspended; whether a verified TOTP second factor exists; who created the login; timestamps. Authentication credentials are held by our subprocessor's authentication service as a bcrypt hash; the password the Customer chooses is passed straight to it and is never stored by us in readable form. |
| Special-category data | None. The Customer must not enter any. |
| Frequency | On creation, on each change by the Customer, and on each request the person makes. |
| Nature of the processing | Collection, storage, authentication, authorisation, suspension and erasure. |
| Purpose | Letting the Customer share its account with named people, at a role it chooses, and withdraw that access. |
| Retention | Until the Customer removes the person, or the account ends. Removal deletes the authentication user first, so access stops immediately, and the membership row second. |
B.3 Personal data inside the Customer's content
| Categories of data subjects | Anyone the Customer chooses to feature or name — typically the creators whose pages the Customer builds, and any person shown in an uploaded image or video. |
|---|---|
| Categories of personal data | Creator and profile names; profile photographs; background images and short videos; profile text, button labels and alt text; destination URLs; geo-block lists; pixel identifiers. Whatever the Customer types or uploads. |
| Public by design | Uploaded images and videos are stored in publicly readable buckets and are reachable by anyone with the URL, because every visitor's browser and every share preview has to fetch them. Limits: images up to 2 MB (JPEG, PNG, WebP); background media up to 20 MB (JPEG, PNG, WebP, MP4, WebM). |
| Frequency | On each change by the Customer; read on each visitor request. |
| Nature of the processing | Storage, publication, retrieval and erasure. |
| Purpose | Rendering the pages the Customer has configured. |
| Retention | Until the Customer deletes it, or the account ends (section 15). |
B.4 Subprocessor processing
Subject matter, nature and duration as set out in Annex III. No subprocessor receives more than what the row describes.
C. Competent supervisory authority
Bayerisches Landesamt für Datenschutzaufsicht (BayLDA), Promenade 27, 91522 Ansbach, Germany.
This is the authority for the processor's main establishment in the sense of Article 4(16) GDPR — the place of central administration, which is in Bavaria. The postal address in the imprint is in North Rhine-Westphalia; competence follows the establishment, not the correspondence address, which is why the two name different states. Where the exporter is established in another member state, the authority of that member state is competent for the exporter, and a data subject may in any case complain to the authority of their own habitual residence (Article 77(1) GDPR).
Annex II — Technical and organisational measures
Measures as at 21 August 2026, implemented under Article 32 GDPR. Where a measure is delivered by a subprocessor, that is stated. This annex populates Annex II of the Standard Contractual Clauses.
| Area | Measures |
|---|---|
| Pseudonymisation and minimisation | Event records are designed to carry no identifier of any individual: no IP address, no raw user agent, no cookie, no device identifier, no account identifier, and no field linking two events by the same visitor. The user agent is reduced at the edge to one of four device classes and a short browser class, and the IP address to a two-letter country code, before anything is written. Analytics beacons are authenticated by a keyed hash of the page and a time window, which is deliberately identical for every visitor of that page. Nothing that is not needed for the stated purpose is stored. |
| Encryption | TLS 1.2 or higher on all connections, with HSTS (max-age one year, includeSubDomains, preload). Data at rest is encrypted by the database and object-storage providers (AES-256). Account passwords are stored only as bcrypt hashes by the authentication provider; operator console passwords only as PBKDF2-SHA-256 with 210,000 iterations and a per-row salt. Secrets live in the hosting provider's encrypted environment store, never in source control. |
| Access control — people | Production access is limited to the proprietor and to persons expressly authorised in writing, each under a confidentiality obligation. Multi-factor authentication is required on every provider console that offers it (hosting, database, payments). Access rights are reviewed when a role changes and withdrawn on the day an engagement ends. |
| Access control — system | Every database table has row-level security enabled with no public policies, so no browser can reach the database directly; all access runs through server-side edge functions holding the service-role key. Customer sessions are signed JWTs verified server-side on every request; where the customer has enabled TOTP, every API call below aal2 is refused, not merely the login form. The operator console uses an HttpOnly, Secure, SameSite cookie carrying an HMAC-SHA-256 session token with a server-side expiry, and its login is rate-limited to 10 attempts per 15 minutes per IP address. Team access is re-read from the database on every request, so removing somebody takes effect immediately rather than when their token expires. |
| Separation | Every multi-tenant query is scoped by tenant_id, including analytics, which is scoped by an explicit slug list because event rows are keyed by slug. Creation and update paths are separated so that no write can move a record between accounts. Development and production run as separate projects with separate credentials; production data is never copied into development. |
| Input and transmission integrity | Slugs are validated against a strict pattern; injection and path-traversal attempts are rejected at the edge, with the screening bounded so that it cannot be used to burn CPU. The click beacon is origin-checked, token-checked, slug-validated, capped at 2 KB and sanitised before storage, with a per-IP and per-link ceiling on top of the general limit. Values that will be navigated to pass a scheme deny-list; values embedded in HTML, in attributes and in inline scripts each pass the escape appropriate to that context. Uploads are limited by type and size per bucket. A Content Security Policy enumerates every permitted script and connection host, and is set both at the edge and on statically served paths; X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a restrictive Permissions-Policy and Referrer-Policy: strict-origin-when-cross-origin are set globally. |
| Availability and resilience | Serverless deployment across a global CDN with automatic failover between points of presence (Netlify). Managed Postgres (Supabase); see Restoration below for what is backed up, by whom, and against which failure. Rate limiting of 60 requests per IP per minute. Analytics writes are fire-and-forget, so a logging failure can never break page delivery. Static assets are immutable and cacheable, so cached pages keep serving through a database incident. |
| Restoration | Two independent layers, because they fail differently. (1) Ours: a scheduled job takes a daily logical export of every table except the analytics events — accounts, team logins, link configuration, subscriptions and invoice records — into a private, service-role-only bucket, retained 35 days and rotated automatically. It covers the common failures: a bad migration, a mistaken deletion, a write that corrupted rows. It is held in the same project as the live data, so it does not cover loss of that project. (2) The provider's: Supabase's own backups of the database cluster cover infrastructure failure, under its documented restore procedure and the retention of our plan. Restoration is exercised when the schema changes materially. Infrastructure and application code are in version control and can be redeployed from source. The analytics events are deliberately excluded from (1): they are deleted after 90 days in any case, so backing them up daily would mean storing what we have promised to destroy. |
| Testing and evaluation | An automated suite runs the real edge handlers against a stubbed database before each release, covering routing, cacheability, access gates, tenant scoping, escaping, the API authentication paths and the whole role matrix for both employee systems. It also asserts published commitments — that no third-party script is loaded, that the consent gate ships inert, that the retention period in these documents matches the deletion job. Production is re-checked after each deployment. The application runtime has no third-party runtime dependencies, which is the cheapest supply-chain control available. |
| Purpose limitation and instruction control | Processing happens only through the documented application paths, which implement the instructions in section 3.2. There is no ad-hoc export path, no analytics vendor and no support tool with access to Customer Personal Data. The operator's own console is scoped to the operator's own organisation, so browsing a customer's links, destinations or statistics is not something the software permits. Staff, where engaged, get written instructions and a confidentiality undertaking. |
| Subprocessor governance | Each subprocessor is engaged on Article 28-compliant terms with flow-down of these obligations, including the prohibition on AI training. The list is published and versioned, with 30 days' notice of change and a right of objection. |
| Deletion | Raw events are deleted by a scheduled daily job after 90 days, together with rows whose link no longer exists; the period is held in one place in the code and the test suite fails if these documents stop naming the same number. Account data is deleted from production within 30 days of termination and expires from backups within a further 90 days. Data under statutory retention is blocked from every other use. |
| Incident response | Documented procedure: detect, contain, assess within 24 hours, notify affected controllers within 48 hours, notify the supervisory authority within 72 hours where required, remediate, record. A responsible-disclosure channel is published at plugwith.me/security, with a target of 30 days to fix a critical or high-severity issue. |
| Governance | Record of processing under Article 30(2). Data protection assessed at design time for each feature, with the reasoning kept in the repository next to the code it constrains. Published commitments are asserted by tests rather than remembered, so a document and the software cannot drift apart silently. |
Annex III — Subprocessors
Authorised subprocessors as at 30 August 2026. The current version, with change history and a notification subscription, is at plugwith.me/subprocessors and is authoritative. A row marked with a date takes effect on that date and not before — the notice period in section 11.2 runs first.
| Subprocessor | Processing carried out | Location of processing | Transfer safeguard |
|---|---|---|---|
| Netlify, Inc. 512 2nd Street, San Francisco, CA 94107, USA |
Hosting, global CDN, execution of the edge functions that serve link pages and receive click events, rate limiting, access logs, derivation of the country code from the IP address | Global edge network; EU points of presence (including Frankfurt and Amsterdam) serve EU visitors. Company established in the USA. | EU–US Data Privacy Framework; EU SCCs Module Three; UK Addendum |
| Supabase, Inc. Delaware, USA — operations also in Singapore |
Managed Postgres storing accounts, team logins, link configuration and click events; authentication and session issuance; object storage for uploaded images, background media and invoice PDFs; delivery of authentication emails | United States — AWS us-east-2 (Ohio). Support and operations access possible from the USA and Singapore. |
EU SCCs Module Three; UK Addendum; Swiss annex. Not DPF-certified — the Clauses are the sole instrument. See 14.5. |
| Resend, Inc. 2261 Market Street #5039, San Francisco, CA 94114, USA From 30 September 2026 — announced 30 August 2026 under section 11.2 |
Delivery of the single confirmation email sent to an account holder after their account has been erased on request. No other message of any kind passes through it. | USA | EU SCCs Module Three; Resend DPA |
| Stripe Payments Europe, Ltd. 1 Grand Canal Street Lower, Dublin 2, Ireland — with Stripe, Inc., USA |
Payment processing, subscription management, invoicing and tax determination. Relates to Customer account data, never to visitor data. Stripe acts as an independent controller for payment data. | Ireland and the USA | EU–US Data Privacy Framework; EU SCCs; Stripe DPA |
Not subprocessors. Meta, Google, TikTok and Snap are not our subprocessors. Where you enable one of their pixels, their scripts run in the visitor's browser and send data to them directly; nothing passes through our systems and we have no contract with them for it. See section 2.3.
No other content delivery network is involved. The Supabase browser client used by the customer area is served from our own domain at a pinned version with a recorded checksum; the esm.sh dependency disclosed in earlier versions of this DPA was removed in July 2026. No third-party script is loaded anywhere on this service.
No AI or machine-learning vendor is engaged, and none receives Customer Personal Data. See section 6.
Annex IV — Country-specific terms
plugwith.me is sold worldwide. These terms apply in addition, and only where the law named applies to your use of the Service. Where they conflict with the main body, they prevail for that law only.
IV.1 United States — California and comparable state laws
Where the California Consumer Privacy Act as amended by the CPRA, or a comparable state law (including Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, Delaware and their successors), applies, we act as your service provider or processor as those laws define the term. We:
- process personal information only for the business purposes in this DPA and your instructions;
- do not sell it and do not share it for cross-context behavioural advertising, as those terms are defined;
- do not retain, use or disclose it outside the direct business relationship or for any purpose other than performing the Service, including not for our own commercial purposes;
- do not combine it with personal information from another source, except as those laws permit;
- comply with the applicable obligations and notify you if we determine we can no longer do so;
- flow the same restrictions down to every subprocessor.
You may take reasonable and appropriate steps to stop and remediate unauthorised use. This section is the contract required by § 1798.100(d) and § 1798.140(ag) CCPA. Deidentified or aggregated information under section 5 is outside these restrictions; we will not attempt to reidentify it and will contractually forbid recipients from doing so.
IV.2 United Kingdom
References to the GDPR are read as references to the UK GDPR and the Data Protection Act 2018. The transfer mechanism is in section 14.3. The competent authority is the Information Commissioner's Office.
IV.3 Switzerland
References to the GDPR are read as references to the revised Federal Act on Data Protection. "Personal data" includes data about legal entities where the FADP so provides. The competent authority is the Federal Data Protection and Information Commissioner. The transfer mechanism is in section 14.4.
IV.4 Brazil
Where the Lei Geral de Proteção de Dados (Law 13,709/2018) applies, you are the controlador and we are the operador. We process personal data only on your instructions, keep it secure, help you answer requests from titulares, and report security incidents to you without undue delay so that you can notify the ANPD and affected individuals. International transfers rest on standard contractual clauses of equivalent effect to those in section 14.
IV.5 Canada
Where PIPEDA or a substantially similar provincial law applies, we act as a service provider processing personal information on your behalf, use contractual and technical means to give it a comparable level of protection, and will tell you of any breach of security safeguards involving it without undue delay. You remain accountable for the information you transfer to us.
IV.6 Australia
Where the Privacy Act 1988 and the Australian Privacy Principles apply, we handle personal information only for the purposes you instruct, and will notify you of any eligible data breach involving it in time for you to meet your own obligations under the Notifiable Data Breaches scheme.
IV.7 Everywhere else
Where a data protection law applies that is not named here, the parties will negotiate in good faith any additional term that law requires. Until then, the standard in the main body of this DPA applies, because it is drafted to the GDPR — in practice the strictest of them.
Change history
| Date | Change |
|---|---|
| 21 September 2026 published 21 August 2026 | Version 3.2. Annex II — Restoration rewritten. The previous wording named "automated daily backups by the provider", which is true only on some plans and was therefore a claim nobody could check. There is now a daily logical export of our own, described with what it does and does not cover, and the provider's backups are named separately as the layer that covers infrastructure loss. The level of protection was not reduced; the description was made accurate. |
| 21 September 2026 published 21 August 2026 | Version 3.1. Link password protection was discontinued. It was a shared secret a visitor could pass on, so it protected nothing, while storing it made us hold a password on the Customer's behalf and obliged this agreement to warn about reuse. Removing the feature removed the warning. The clause that described it, and the mention of link passwords in Annex I.B.3, are gone. |
| 21 September 2026 published 21 August 2026 | Version 3.0. Team logins and uploaded media added to Annex I as processing streams of their own — the previous version described only click events, so two categories of data subject were undocumented. New controller warranties and indemnity (section 7), an explicit permission for anonymous aggregate statistics with published minimum group sizes (section 5), an AI Act and Article 22 statement (section 6), a records / DPO / representative section (17), a country annex for the US, UK, Switzerland, Brazil, Canada and Australia (Annex IV), and a change history. The retention period is now enforced by a daily deletion job instead of being stated only. Annex II corrected: upload limits per bucket, backup wording, and a precise description of the access controls that actually exist. |
| 4 August 2026 | Version 2.2. Provider address updated; competent supervisory authority and place of jurisdiction aligned with the place of establishment. |
| 31 July 2026 | Version 2.1. Hosting region corrected to the United States (us-east-2, Ohio); the transfer rests on the Standard Contractual Clauses because Supabase is not DPF-certified. |
| 31 July 2026 | Version 2.0. Full agreement published in place of the earlier summary, with the SCCs, the UK Addendum and the annexes. |
| 29 May 2026 | Version 1.0. First DPA summary published. |