Zgodny z RODO, art. 28 (powierzenie) i art. 26 (współadministrowanie)

Polityka prywatności dla agencji i software house

Przetwarzasz dane klientów swoich klientów — to podwójna odpowiedzialność. Umowy powierzenia, sub-powierzenie do Google i Meta, łańcuch narzędzi SaaS. Wygeneruj politykę prywatności, która to wszystko porządkuje — w 5 minut.

Darmowy
Bez rejestracji
Client-side
30 000+
firm IT i marketingowych w Polsce

Agencje, software house'y, freelancerzy. Świadomi technicznie, ale często bez dedykowanej polityki prywatności własnej strony — bo „przecież robią to dla klientów".

2 role
administrator + podmiot przetwarzający

Administrator własnych danych (CRM, pracownicy, kontrahenci) i jednocześnie procesor danych klientów (kampanie, bazy, aplikacje). Każda rola ma inne obowiązki RODO.

10–30
narzędzi SaaS w typowym stosie technologicznym

Google, Meta, HubSpot, Slack, Jira, AWS — każde to odbiorca lub sub-procesor danych. Większość to firmy amerykańskie wymagające opisu transferu do USA.

Specyfika branży IT i marketingu

Dlaczego agencja i software house potrzebują dedykowanej polityki?

Ogólny wzór z internetu nie wystarczy. Przetwarzacie dane w podwójnej roli, operujecie na dziesiątkach narzędzi SaaS i budujecie łańcuch sub-powierzenia, który wymaga precyzyjnego opisu.

Administrator vs. procesor — podwójna rola

Administrator danych własnych klientów (CRM, oferty, faktury) i procesor danych klientów swoich klientów (kampanie, bazy, aplikacje). Polityka prywatności musi jasno rozgraniczać obie role i obowiązki z nimi związane.

Umowy powierzenia (DPA)

Art. 28 RODO wymaga umowy powierzenia z każdym klientem, którego dane przetwarzasz. DPA musi określać: przedmiot, czas trwania, charakter i cel przetwarzania, kategorie danych, obowiązki i prawa stron.

Sub-powierzenie — łańcuch SaaS

Klient powierza dane agencji, agencja przekazuje je do Google Ads, Meta, MailChimp, HubSpot. Art. 28.2 RODO wymaga zgody klienta na każdego sub-procesora. Polityka musi opisywać ten łańcuch.

Transfer danych do USA — masowy

Google Analytics, Meta Pixel, Salesforce, HubSpot, AWS, Stripe, Slack — typowa agencja wysyła dane do kilkunastu firm amerykańskich. Każdy transfer wymaga mechanizmu zabezpieczającego (DPF, SCC) i opisu w polityce.

Audyt narzędzi trzecich

RODO wymaga, by procesor korzystał wyłącznie z sub-procesorów zapewniających odpowiednie gwarancje (art. 28.1). Agencja powinna prowadzić rejestr narzędzi z informacją o DPA, lokalizacji serwerów i mechanizmach transferu.

Dostęp developerów do danych produkcyjnych

Programiści software house'u mają dostęp do baz danych klientów — user data, logi, PII. Polityka musi opisywać zasady dostępu, środki bezpieczeństwa i procedury na wypadek naruszenia (art. 32 i 33 RODO).

Checklista

Co musi zawierać polityka prywatności agencji i software house?

Art. 13 RODO wymaga konkretnych informacji. Oto elementy, które nasz generator uwzględnia automatycznie dla firm IT i marketingowych.

Dane administratora (nazwa firmy, NIP, KRS, adres, email, IOD)
Opis podwójnej roli (administrator vs. procesor)
Cele przetwarzania (sprzedaż, realizacja usług, marketing, rekrutacja)
Podstawy prawne (umowa, uzasadniony interes, zgoda, obowiązek prawny)
Informacja o umowach powierzenia z klientami (art. 28)
Lista sub-procesorów i narzędzi SaaS
Transfer danych do USA (DPF, SCC) — dla każdego odbiorcy
Cookies, piksele śledzące, analityka na własnej stronie
Zasady dostępu pracowników/developerów do danych
Okresy przechowywania (umowy, projekty, faktury, marketing)
Prawa osób (dostęp, usunięcie, przenoszenie, sprzeciw)
Informacja o prawie do skargi do UODO

Wygeneruj politykę dla swojej firmy

Generator automatycznie zaznacza opcje typowe dla agencji i software house'ów: podwójna rola, narzędzia SaaS, transfer do USA, cookies i analityka, B2B marketing. Wystarczy, że uzupełnisz dane swojej firmy i stos technologiczny.

Otwórz generator

Wszystko działa w przeglądarce. Dane nie trafiają na żaden serwer.

Uwaga

Najczęstsze błędy RODO w agencjach i software house'ach

Paradoks branży: budujecie rozwiązania RODO-compliant dla klientów, a własna polityka ma luki. Oto najczęstsze z nich.

Brak rozróżnienia ról administrator/procesor

Polityka traktuje agencję wyłącznie jako administratora, ignorując rolę procesora. To dwie odrębne odpowiedzialności z różnymi obowiązkami — polityka prywatności dotyczy roli administratora, ale musi informować o obu.

Nieudokumentowane sub-powierzenie

Agencja korzysta z 15 narzędzi SaaS, ale klient nie wie, które z nich przetwarzają jego dane. Art. 28.2 RODO wymaga uprzedniej zgody na sub-procesorów i aktualnej listy. Brak dokumentacji to naruszenie umowy powierzenia.

Brak opisu transferów do USA

Google Analytics, Meta Pixel, HubSpot, AWS, Slack — dane lecą do USA, ale polityka tego nie wspomina. Każdy transfer wymaga wskazania mechanizmu zabezpieczającego (DPF lub SCC) dla konkretnego odbiorcy.

Developerzy z pełnym dostępem do produkcji

Programiści mają dostęp do bazy produkcyjnej klienta — PESEL-e, emaile, dane transakcyjne — bez logowania dostępu, zasad need-to-know ani procedury na wypadek naruszenia. Art. 32 RODO wymaga odpowiednich środków technicznych.

FAQ

Najczęstsze pytania o politykę prywatności agencji i software house

Czy agencja marketingowa musi mieć politykę prywatności?
Tak. Agencja marketingowa i software house przetwarzają dane osobowe w podwójnej roli: jako administrator (dane własnych klientów, pracowników, użytkowników strony) i jako podmiot przetwarzający (dane klientów swoich klientów). Zgodnie z art. 13 RODO musisz informować o przetwarzaniu danych, za które jesteś administratorem. Polityka prywatności na stronie agencji dotyczy tej pierwszej roli.
Kiedy agencja jest administratorem, a kiedy procesorem?
Administrator — gdy decydujesz o celach i sposobach przetwarzania: dane w CRM, dane pracowników, użytkownicy Twojej strony (formularze, cookies), subskrybenci newslettera. Procesor — gdy przetwarzasz dane w imieniu klienta: prowadzisz kampanie Google Ads/Meta Ads, zarządzasz bazą mailingową klienta, administrujesz jego stroną, hostujesz aplikację z danymi użytkowników. W obu rolach masz obowiązki RODO, ale różne.
Co to jest sub-powierzenie danych?
Sub-powierzenie to przekazanie danych dalej w łańcuchu przetwarzania. Klient powierza dane agencji (umowa powierzenia), agencja przekazuje je do Google Analytics, Meta Ads, MailChimp, HubSpot — to sub-powierzenie. Art. 28.2 RODO wymaga uprzedniej pisemnej zgody klienta na każdego sub-procesora. W praktyce agencja powinna prowadzić aktualną listę sub-procesorów i informować klienta o zmianach.
Jakie narzędzia SaaS muszą być w polityce?
Każde narzędzie przetwarzające dane osobowe z Twojej strony: analityka (Google Analytics, Hotjar, Mixpanel), reklama (Google Ads, Meta Pixel, LinkedIn Insight Tag), email marketing (MailChimp, GetResponse, MailerLite), CRM (HubSpot, Pipedrive), hosting (AWS, Google Cloud, Cloudflare), komunikacja wewnętrzna (Slack, Teams), zarządzanie projektami (Jira, Asana, ClickUp — jeśli zawierają dane osobowe), płatności (Stripe, PayU). Dla każdego wskaż nazwę, cel i lokalizację serwerów.
Czy software house musi mieć umowy powierzenia z klientami?
Tak, jeśli przetwarza dane osobowe w imieniu klienta — a robi to prawie zawsze. Hostowanie aplikacji z danymi użytkowników, dostęp do bazy produkcyjnej, administracja CMS-em, support techniczny z wglądem w dane — każdy z tych scenariuszy wymaga DPA (Data Processing Agreement) wg art. 28 RODO. Umowa musi określać przedmiot i czas przetwarzania, kategorie danych, obowiązki procesora i zasady sub-powierzenia.
Jak opisać transfer danych do USA?
Typowa agencja lub software house używa kilkunastu narzędzi amerykańskich. Dla każdego odbiorcy z USA musisz wskazać: nazwę firmy, cel przetwarzania, mechanizm zabezpieczający — EU-U.S. Data Privacy Framework (DPF) dla firm certyfikowanych lub standardowe klauzule umowne (SCC). Warto prowadzić rejestr narzędzi z informacją o lokalizacji serwerów i statusie DPF — ułatwia to aktualizację polityki przy zmianach w stosie technologicznym.

Polityka prywatności to za mało

Dokument informuje o przetwarzaniu danych, ale nie chroni ich przed wyciekiem. Jeśli ktoś uzyska nieautoryzowany dostęp do bazy klienta — dane użytkowników, klucze API, tokeny, credentials — masz 72 godziny na zgłoszenie do UODO (art. 33 RODO). Jako procesor musisz dodatkowo niezwłocznie powiadomić klienta (administratora). Pytanie: czy w ogóle się o tym dowiesz?

clev.one to system wczesnego ostrzegania, który wykrywa naruszenia w sekundach, nie miesiącach. Umieszczasz cyfrowe pułapki wśród repozytoriów, baz danych i dokumentacji — gdy ktoś niepowołany się do nich dobierze, dostajesz natychmiastowy alert.

Dowiedz się więcej o clev.one

Generator dla innych branż

Każda branża przetwarza dane inaczej. Wybierz swoją.