Acest document este publicat în mai multe limbi. În cazul oricărei neconcordanțe între versiunile lingvistice, versiunea în limba polonă este cea obligatorie.
Versiunea 1.2 · Ultima actualizare: 29 octombrie 2026
1. Cum se citește această evidență
Aceasta este evidența activităților de prelucrare conform art. 30 RGPD pentru formexposed. Nu este o politică de confidențialitate și nici material de marketing. Rolul ei este să arate unei autorități de supraveghere, unui Client care ne auditează în calitate de persoană împuternicită sau următoarei persoane care trebuie să răspundă la o întrebare ce se prelucrează efectiv, unde sunt păstrate datele, cine le primește și cât timp rămân. O publicăm pentru că un serviciu care verifică și monitorizează formulare ar trebui să fie el însuși deschis verificării.
Trei reguli au guvernat modul în care a fost redactată.
- Măsurat, nu intenționat. O afirmație despre câmpurile de date, perioadele de stocare, destinatari sau garanții apare doar acolo unde codul programului, schema bazei de date sau o măsurătoare o susține. Ceea ce este planificat este numit „planificat”. Ceea ce este dezactivat implicit este numit „dezactivat implicit”. Acolo unde nu putem dovedi ceva, o spunem.
- Stocarea este indicată de două ori. O dată pentru fiecare activitate de prelucrare și o dată în secțiunea 6, ca imagine de ansamblu: ce rulare nocturnă șterge ce date și la ce date nu ajunge. O evidență care pretinde o perioadă de stocare ce se aplică doar unei părți a datelor este mai rea decât una care numește punctul deschis.
- Punctele deschise sunt menționate în text, nu într-o notă de subsol. Secțiunea 8.1 enumeră măsurile încă neimplementate, secțiunea 10 punctele deschise cu măsurile planificate. O evidență este un instrument de lucru, nu un certificat.
Câmpuri de date în loc de nume de tabele. Pentru fiecare activitate de prelucrare enumerăm datele stocate ca câmpuri în limbaj simplu. Numele tabelului din baza de date urmează între paranteze, astfel încât un auditor să poată găsi locul, de exemplu „încercări de autentificare (login_attempts)”. Listele de câmpuri au fost derivate din schema bazei de date, nu din memorie.
Perioadele de stocare ca substituenți. Acolo unde o perioadă de stocare poate fi setată în zona de administrare, aceasta apare aici exact așa cum o citește rularea nocturnă: cifra pe care o vedeți provine din aceeași setare care guvernează ștergerea. Perioadele de stocare fixate în program sunt indicate ca cifre.
Baza de măsurare. Schema, codul și setările au fost măsurate la 11 octombrie 2026 pe sistemul de dezvoltare, care corespunde sistemului de producție în ceea ce privește codul și schema. Nu indicăm numărul de rânduri din sistemul de dezvoltare; acestea conțin date de test și nu spun nimic despre funcționarea reală.
Omise în mod intenționat. Această evidență nu menționează numele de host, adresele din rețeaua internă, porturile, numele de utilizator sau versiunile software ale serverelor noastre. Astfel de detalii ajută un atacator și nicio persoană vizată. Din același motiv, descriem punctele deschise privind securizarea propriilor noastre servere doar în termeni generali (secțiunea 8.1): numim riscul, nu calea către el. Furnizăm detaliile unei autorități de supraveghere, la cerere.
Natura juridică. Această evidență este documentația pe care o ținem conform art. 30 RGPD pentru autoritatea de supraveghere; este publicată voluntar. Nu face parte din niciun contract și nu constituie nicio declarație, garanție sau convenție privind calitatea față de Clienți sau terți. Ceea ce le datorăm Clienților este reglementat de Condițiile de utilizare, de Acordul de prelucrare a datelor și de anexele acestuia; în privința acestor obligații, acestea au prioritate față de prezenta evidență. Evidența descrie situația de la data acestei versiuni. Clasificări precum „punct deschis” sau „evaluare” reflectă propria noastră opinie și nu anticipează nicio evaluare juridică a unei autorități de supraveghere sau a unei instanțe; măsurile descrise ca „planificate” sunt intenții fără o dată asumată.
2. Entitatea juridică și de ce această evidență are două jumătăți
| Câmp | Mențiune |
|---|
| Entitatea juridică | LW IT Solutions Company Lukas Wójcik, întreprindere individuală înregistrată în registrul polonez al activităților economice (CEIDG); proprietar Lukas Wójcik |
| Adresă | al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia |
| Identificatori fiscali | NIP 7252266190, cod TVA PL7252266190 |
| Contact | contact@lukaswojcik.com; fereastra de asistență (semnul întrebării din bara de navigare); pagina de contact |
| Serviciu | formexposed: verificarea, monitorizarea și securizarea formularelor de contact de pe site-uri web (aplicația la formexposed.com, pagina de prezentare la form.exposed) |
| Reprezentant conform art. 27 RGPD | Nu se aplică. Entitatea juridică este stabilită în Uniune (Polonia). |
| Responsabil cu protecția datelor | Nedesemnat. Evaluarea conform art. 37 se află în secțiunea 9. |
| Autoritatea de supraveghere competentă | Prezes Urzędu Ochrony Danych Osobowych (UODO, autoritatea poloneză pentru protecția datelor), ul. Moniuszki 1A, 00-014 Warszawa |
| Găzduire | Propriile noastre servere din Polonia: un server web cu aplicația și baza de date și un server de scanare cu un model lingvistic local, în aceeași rețea internă. Niciun centru de date sau furnizor de cloud al unui terț. |
formexposed joacă roluri diferite față de grupuri diferite de persoane. Amestecarea lor produce o evidență care nu este corectă pentru niciunul dintre ele.
- Operator (Partea B, art. 30(1)). Suntem noi înșine operatorul pentru datele propriilor noștri Clienți și ale membrilor echipelor lor (cont, autentificare, facturare, asistență, jurnale), pentru vizitatorii propriului nostru site, pentru verificările fără cont (verificarea gratuită, instrumentul pentru antete, studiul, verificarea clienților potențiali) și pentru prevenirea abuzurilor.
- Persoană împuternicită (Partea A, art. 30(2)). Pentru datele cu caracter personal ale unor terți pe care un Client le aduce în serviciu sau care apar atunci când prestăm un serviciu pentru Client, acționăm în numele Clientului: copii ale e-mailurilor reale din formulare în verificarea livrării, abonații portalului pentru clienți al Clientului, destinatarii alertelor Clientului, persoanele vizibile întâmplător pe paginile verificate ale Clientului, datele de autentificare ale contului de test al Clientului și codul formularului pe care Clientul îl introduce. Temeiul este Acordul de prelucrare a datelor, care se încheie cu fiecare Client la înregistrare.
- Doar de partea Clientului. Unele funcții ale pluginului WordPress și ale extensiei TYPO3 prelucrează date exclusiv pe site-ul Clientului, fără ca datele să ajungă vreodată la noi (carantina, plasa de siguranță, problema aritmetică, setările de stocare, contoarele locale, înregistratorul). Acestea nu sunt prelucrări efectuate de noi și, prin urmare, nu apar în niciuna dintre părți. Le descriem totuși la sfârșitul Părții A, pentru ca limita să fie vizibilă.
Separarea este integrată în cod, nu doar în text: dintr-un e-mail real din formular, verificarea livrării scrie în baza de date doar momentul, atribuirea și rezultatul autentificării; capturile de ecran ale verificărilor în browser maschează câmpurile de introducere; datele de autentificare ale contului de test sunt criptate astfel încât serverul web nu le mai poate citi. Detaliile sunt prezentate în intrări.
Secțiunile 6-11 se aplică ambelor jumătăți: stocarea, deciziile automatizate, măsurile tehnice și organizatorice, responsabilul cu protecția datelor, punctele deschise și actualizarea acestei evidențe.
Domeniu de aplicare. Acest document este partea evidenței care privește serviciul formexposed. Prelucrările efectuate de aceeași entitate juridică pentru alte servicii sunt înregistrate în propriile lor evidențe; contabilitatea generală și administrarea afacerii din afara serviciului nu sunt acoperite de această parte.
3. Partea A – art. 30(2): prelucrare în numele Clienților
A.0 Părțile implicate
| Câmp | Mențiune |
|---|
| Persoana împuternicită | LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia; contact@lukaswojcik.com |
| Operatori | Clienții formexposed: întreprinderi și agenții care au domenii în contul lor și folosesc funcții în care apar date ale terților. În cazul agențiilor, clientul propriu al agenției poate fi, în plus, operatorul; agenția acționează atunci ca persoană împuternicită față de acel client, iar noi acționăm ca o altă persoană împuternicită. |
| Lista operatorilor | Parte a acestei evidențe, ținută în format electronic (art. 30(3) RGPD) în sistemul serviciului și nereprodusă în această versiune publică, deoarece conține date cu caracter personal ale Clienților și ar fi depășită la fiecare Client nou: proprietarul fiecărui spațiu de lucru, cu numele, adresa de e-mail și firma din contul de client (adresa și codul de TVA doar la Stripe) (users, workspaces, workspace_users), plus domeniile spațiului de lucru (domains). O furnizăm unei autorități de supraveghere ca extras, la cerere. |
| Reprezentanții și responsabilii cu protecția datelor ai operatorilor | În sistem nu există un câmp dedicat pentru aceasta. Dacă un Client a desemnat un reprezentant conform art. 27 RGPD sau un responsabil cu protecția datelor, ni-i poate comunica; păstrăm comunicarea împreună cu lista operatorilor. |
| Reprezentantul persoanei împuternicite | Nu se aplică (stabilită în Polonia). |
| Responsabil cu protecția datelor | Nedesemnat (secțiunea 9). |
| Instrucțiuni | Instrucțiunea rezultă din Acordul de prelucrare a datelor și din setările pe care le face Clientul: Clientul activează verificarea livrării, configurează destinațiile alertelor, salvează un cont de test și configurează un portal pentru clienți. Fără această acțiune, prelucrarea respectivă nu are loc. |
| Măsuri tehnice și organizatorice | Secțiunea 8 și pagina Măsuri tehnice și organizatorice se aplică fiecărei activități de prelucrare din Partea A. Măsurile speciale sunt indicate în intrarea relevantă. |
A.1 Verificarea livrării – copia de control a e-mailurilor din formulare
| Câmp | Mențiune |
|---|
| Scop | Verificarea faptului că e-mailul din formularul de contact al Clientului este trimis efectiv și a modului în care este autentificat (SPF, DKIM, DMARC, aliniere). După o trimitere de test activă acceptată, copia acesteia trebuie să ajungă în căsuța poștală de control într-un timp de așteptare reglabil (în prezent 3 ore); în caz contrar se declanșează alerta „E-mailul de test nu a fost primit”. Din antete se deduc, de asemenea, autenticitatea e-mailului din formular, serviciul de e-mail folosit și adresa de trimitere pentru verificarea în listele de blocare. |
| Condiție prealabilă | Plan plătit, domeniu verificat, activare de către Client. Clientul introduce propria adresă de control cu un identificator (de forma „delivery+identificator@…”) ca destinatar în copie ascunsă în notificarea formularului său. Fără o căsuță poștală de control configurată, funcția nu este disponibilă. |
| Categorii de persoane vizate | Vizitatorii site-ului Clientului care trimit formularul Clientului; persoanele ale căror date le scrie un vizitator în mesaj; personalul Clientului care apare ca destinatar în antete. |
| Categorii de date cu caracter personal | În căsuța poștală de control (la furnizorul de servicii de e-mail): copia completă a fiecărui e-mail din formular, inclusiv solicitările reale cu nume, adresă de e-mail, număr de telefon și text liber, până la ștergere. Citite de preluare: antetele și cel mult primii 8 KB din corpul mesajului. În baza de date: momentul primirii, atribuirea la domeniu și, după caz, la rularea de test (delivery_log); cel mai recent rezultat al autentificării per domeniu, cu rezultatul SPF, DKIM și DMARC, alinierea, domeniul expeditorului, domeniile de semnare și adresa serverului de e-mail expeditor (câmpul de autentificare al domeniului în domains). Conținutul, subiectul și adresa de expeditor a vizitatorului nu sunt scrise în baza de date. |
| Notă privind domeniul expeditorului | Dacă un formular introduce adresa vizitatorului ca expeditor (o configurare greșită pe care verificarea este concepută să o descopere), rezultatul autentificării conține domeniul acelei adrese, nu adresa însăși. Dacă un vizitator folosește un domeniu personal, și acesta poate fi o dată cu caracter personal. Este suprascris la următoarea primire. |
| Sursă | Formularul de pe site-ul Clientului, prin copia ascunsă introdusă de Client. |
| Temei juridic (stabilit de operator) | Stabilit de Client. Textul propus de noi pentru politica de confidențialitate a Clientului întemeiază copia pe art. 6(1)(f) RGPD (interesul legitim de a primi în mod fiabil solicitările). Clientul își informează vizitatorii cu privire la acest flux de date; Acordul de prelucrare a datelor îl obligă să facă acest lucru. |
| Destinatari | Furnizorul de servicii de e-mail care gestionează căsuța poștală de control (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). Copia ajunge direct acolo: ea sosește doar dacă înregistrările MX ale domeniului nostru indică această căsuță poștală (lista de verificare dinaintea lansării verifică acest lucru); printr-o redirecționare nu ajunge în căsuța poștală. Pe pagina domeniului, Clientul vede doar momentul, atribuirea și rezultatul autentificării. Dacă rezultatul autentificării se înrăutățește, alerta către Client și către canalele alese de acesta menționează domeniul expeditorului dacă acesta nu aparține site-ului (A.3, 4.1). |
| Țară terță | Depinde de furnizorul de servicii de e-mail; vezi secțiunea 4. Contractul cu furnizorul avut în vedere și temeiul transferului nu sunt încă documentate. |
| Stocare | După prelucrarea reușită, e-mailul este marcat pentru ștergere și eliminat din căsuța poștală în aceeași rulare, chiar dacă nu poate fi atribuit niciunui domeniu. Preluarea rulează odată cu rularea de stare, la fiecare cinci minute, cât timp monitorizarea este activată în zona de administrare (srv/cron_status.php, cfg/zustellung_lib.php). Dacă preluarea sau ștergerea eșuează, e-mailul rămâne în căsuța poștală până la următoarea rulare reușită. Aceeași preluare șterge atribuirile din delivery_log după 180 de zile. Rezultatul autentificării există atât timp cât domeniul. |
| Ce dovedește proba | Doar primirea, în căsuța poștală de control, a copiei atribuite rulării de test concrete. Nu dovedește nici primirea de către destinatarul efectiv, nici o înregistrare în CRM. Nu este oferită o confirmare nativă din HubSpot. |
| Măsuri tehnice și organizatorice | Secțiunea 8. În special: conținutul este evaluat doar în memorie; nu se stochează corpul, subiectul sau adresele complete ale expeditorilor; ștergerea are loc indiferent dacă atribuirea a reușit. |
Verificarea livrării este singura funcție prin care ajung la noi mesaje reale de la vizitatorii Clienților noștri. De aceea, ea este o prelucrare în numele Clientului și nu un serviciu pe propria noastră răspundere, și tot de aceea timpul petrecut în căsuța poștală este adevărata măsură a riscului: în mod normal câteva minute; dacă preluarea este perturbată, până la următoarea rulare. Copiile nu ar trebui să conțină categorii speciale de date cu caracter personal; nu putem împiedica acest lucru din punct de vedere tehnic, deoarece ce scrie un vizitator depinde de vizitator.
A.2 Portalul pentru clienți și raportul lunar către abonați
| Câmp | Mențiune |
|---|
| Scop | O agenție (planul Business) le arată clienților săi starea domeniilor lor sub propria marcă (portal la o adresă aleatorie, opțional cu parolă, opțional pe un subdomeniu propriu al agenției). Clientul poate comanda acolo un raport lunar prin e-mail. Raportul este trimis în numele agenției. |
| Categorii de persoane vizate | Clienții agenției și personalul acestora care comandă raportul; persoanele care deschid portalul. |
| Categorii de date cu caracter personal | Abonat: adresa de e-mail, limba, identificatorul de confirmare, momentul comenzii și adresa IP la momentul comenzii, momentul confirmării (double opt-in), momentul dezabonării, ultima lună trimisă (client_subscribers). Portal: numele, selecția domeniilor, identificatorul aleatoriu, parola doar ca hash, persoana care l-a creat, momentul, revocarea (client_portals). Vizitele în portal apar în jurnalul accesărilor paginilor (B.2). |
| Sursă | Introduse chiar de abonați în portal. |
| Temei juridic (stabilit de operator) | Consimțământul abonatului, obținut printr-o procedură double opt-in; operatorul este agenția. Nu scriem nimănui care nu s-a înscris și nu a confirmat el însuși. |
| Destinatari | Agenția (își vede abonații); furnizorul de servicii de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) pentru e-mailul de confirmare și raport. |
| Țară terță | Prin furnizorul de servicii de e-mail; vezi secțiunea 4. |
| Stocare | Rularea nocturnă de ștergere (cfg/fristen_lib.php, partea „abonați portal”): comenzile niciodată confirmate după 30 de zile; abonații dezabonați la trei ani după dezabonare, ca dovadă a consimțământului anterior. Abonații confirmați care nu s-au dezabonat rămân atât timp cât există spațiul de lucru al agenției. Un portal revocat este doar blocat, nu șters; abonații săi nu mai primesc rapoarte, dar datele lor rămân (secțiunea 10). Portalurile și abonații dispar imediat odată cu spațiul de lucru (fe_arbeitsbereich_daten_loeschen()). Rapoartele trimise rămân în căsuța de ieșire timp de 30 zile (B.25). |
| Măsuri tehnice și organizatorice | Secțiunea 8. În special: parola portalului doar ca hash, încercările de ghicire limitate (zece per portal și adresă IP, 50 per portal în 15 minute); dezabonare cu un singur clic în fiecare e-mail; portalul arată doar starea și cifrele-cheie, nu constatări individuale cu probe. |
A.3 Destinatarii alertelor, persoanele care confirmă și persoanele responsabile ale Clientului
| Câmp | Mențiune |
|---|
| Scop | Notificări privind defecțiunile și modificările către destinațiile pe care Clientul le configurează pentru un domeniu: e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Per destinație imediat sau colectate zilnic ori săptămânal, plus destinații doar pentru escaladări. Fiecare notificare de problemă devine un incident, pe care destinatarul îl poate confirma printr-un link. Pentru formularele monitorizate, Clientul poate indica o persoană responsabilă și un termen. |
| Categorii de persoane vizate | Personalul și furnizorii de servicii ai Clientului pe care Clientul îi introduce ca destinație a alertelor sau îi numește ca persoane responsabile; persoanele care confirmă un incident. Membrii echipei cu cont propriu apar și în Partea B. |
| Categorii de date cu caracter personal | Destinația alertei: canalul, adresa de destinație (adresă de e-mail, adresă de webhook sau de chat, ID de chat Telegram), evenimentele selectate, modul de livrare, secretul de semnare pentru webhookuri, ultima livrare și ultima eroare (alerts). Jurnalul de livrare: destinația, evenimentele, starea, eroarea, momentul (alert_log). Coada rezumatelor: liniile notificării și linkul până la livrare (alert_queue). Incident: titlul, liniile notificării, linkul, identificatorul de confirmare, momentul și numele sau adresa de e-mail a persoanei care confirmă, așa cum a fost introdusă în formular, altfel adresa membrului autentificat (alert_incidents). Încercările de livrare a escaladărilor per incident și destinație: numărul încercărilor (cel mult cinci), momentele ultimei și următoarei încercări și ale reușitei, trimiterea la e-mailul din căsuța de ieșire, eroarea (tabelul alert_escalation_deliveries). Atribuire: contul persoanei responsabile și termenul (în monitored_forms). |
| Conținutul notificărilor | Domeniul, evenimentul, o scurtă explicație și un link către pagina domeniului. Niciun conținut al mesajelor vizitatorilor. |
| Sursă | Introduse de Client; persoana care confirmă își introduce singură numele; ID-ul chatului Telegram este creat atunci când destinatarul apasă „Start” în bot (B.32). |
| Temei juridic (stabilit de operator) | Stabilit de Client; de regulă organizarea propriei activități a Clientului (art. 6(1)(b) sau (f) RGPD în raport cu personalul și furnizorii de servicii ai Clientului). |
| Destinatari | Operatorii canalelor alese; vezi 4.1. Alertele prin e-mail prin furnizorul de servicii de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Țară terță | În funcție de canalul ales; mai mulți furnizori au sediul în SUA, Telegram în afara UE, fără decizie privind caracterul adecvat. Vezi 4.1. |
| Stocare | Jurnalul de livrare după 90 zile (nocturn, fe_alert_log_aufraeumen() din srv/cron_status.php). Notificările din rezumate la 30 de zile după livrare (cfg/kanal_lib.php, la fiecare livrare a unui rezumat). Incidentele cât timp nu sunt rezolvate; cele rezolvate la 180 de zile după rezolvare (cfg/vorfall_lib.php, rularea de escaladare), împreună cu încercările lor de livrare a escaladărilor. Destinațiile alertelor și atribuirile până la ștergerea de către Client sau odată cu domeniul. |
| Măsuri tehnice și organizatorice | Secțiunea 8. În special: webhookuri semnate cu un secret separat per destinație; confirmarea doar după un clic (POST), astfel încât previzualizările linkurilor din programele de chat să nu declanșeze nimic; alertele din timpul unei ferestre de mentenanță sunt doar înregistrate în jurnal, nu trimise. |
A.4 Persoane vizibile întâmplător pe paginile verificate ale Clientului și în capturile de ecran
| Câmp | Mențiune |
|---|
| Scop | Verificarea domeniilor din contul Clientului (scanare, monitorizare, verificare activă) citește paginile publice ale Clientului și realizează capturi de ecran ale formularelor. Ceea ce afișează pagina însăși poate privi persoane care nu au nicio legătură cu verificarea. Aceste date apar întâmplător; ele nu sunt scopul verificării. |
| Categorii de persoane vizate | Persoanele al căror nume, fotografie sau date de contact apar pe pagina verificată (persoana de contact de lângă formular, fotografiile echipei de pe pagina principală, datele din informațiile legale). |
| Categorii de date cu caracter personal | Capturi de ecran: zona vizibilă a paginii principale, fiecare formular vizibil ca decupaj și imaginea paginii următoare după o trimitere de test activă; stocate ca fișiere în afara directorului web, cu doar trimiterea în baza de date (scan_screenshots). Structura formularului: adresa paginii, selectorul, numele câmpurilor, tipurile câmpurilor, etichetele câmpurilor, indicatorii de obligativitate și vizibilitate, etichetele butoanelor de trimitere (forms, câmpul „hartă a câmpurilor”); fără valorile câmpurilor. Scanerul citește începutul câmpurilor ascunse (până la 24 de caractere) și al atributelor data (până la 60 de caractere) doar în timpul verificării, pentru a recunoaște marcajele de timp și tokenurile; se stochează doar rezultatul. Constatări cu probe (findings), rezumat cu titlurile paginilor (scans). Dacă o adresă de e-mail apare în formular ca destinatar, se stochează doar domeniul acesteia, niciodată adresa. |
| Sursă | Paginile publice ale domeniului Clientului, preluate de scaner. |
| Temei juridic (stabilit de operator) | Stabilit de Client pentru conținutul propriului site. Pentru noi, prelucrarea face parte din verificarea comandată. |
| Destinatari | Clientul; în cazul agențiilor, clientul acestora prin portal sau printr-un raport white-label; oricine primește un link de raport (rapoarte la adrese aleatorii, nu în motoarele de căutare). Acolo unde tipul formularului este neclar, un model lingvistic local de pe propriul nostru server primește structura formularului cu titlul paginii, adresa paginii și textul vizibil al formularului (până la 400 de caractere) pentru clasificare; nu primește imagini. |
| Țară terță | Niciuna. |
| Stocare | Rezultatele verificărilor pentru un domeniu cel mult 13 luni; ultima verificare finalizată per domeniu rămâne (rularea nocturnă de ștergere, partea „rezultate vechi ale verificărilor”). Formularele, constatările, trimiterile la imagini și fișierele de imagine dispar odată cu rezultatul verificării. Odată cu domeniul, aceste date dispar imediat (lanțul de ștergere în B.15; excepții în secțiunea 6.4). |
| Limitele mascării | Capturile de ecran ale verificării complete nu maschează nimic: ele arată ce arată pagina oricărui vizitator. Câmpurile formularelor sunt goale la preluare, deoarece scanerul nu introduce nimic; valorile precompletate ar fi vizibile. În spatele unei autentificări nu se realizează capturi de ecran (A.5). Imaginile verificărilor în browser maschează câmpurile de introducere (A.6). |
| Măsuri tehnice și organizatorice | Secțiunea 8. În special: imaginile pot fi accesate doar prin raport, iar identificatorul imaginii altcuiva returnează „negăsit”; rapoarte cu noindex; fiecare verificare rulează în propriul container izolat. |
Aceleași date apar și în verificările fără cont (verificarea gratuită, studiul, verificarea clienților potențiali). Acolo nu există un Client în numele căruia să acționăm; de aceea, aceste cazuri apar în Partea B (B.5, B.7, B.8).
A.5 Datele de autentificare ale contului de test pentru scanarea în spatele autentificării
| Câmp | Mențiune |
|---|
| Scop | Citirea formularelor care apar doar după autentificare (zona clienților, zona membrilor). Scanerul se autentifică cu un cont de test pe care Clientul l-a creat pe propriul site și citește paginile indicate. În afară de formularul de autentificare nu trimite nimic, nu efectuează acolo niciun test activ, nu realizează capturi de ecran și nu accesează adrese de deconectare, ștergere sau reziliere. Dacă formularul de autentificare are CAPTCHA, se oprește; CAPTCHA-urile nu sunt ocolite. |
| Condiție prealabilă | Domeniu verificat, plan plătit, rol de proprietar sau administrator, confirmare expresă că este vorba de un cont de test. Cel mult cinci pagini, toate pe același domeniu. |
| Categorii de persoane vizate | Persoana pe numele căreia este deținut contul de test (ideal nimeni; Clientul ar trebui să folosească un cont funcțional); persoanele ale căror date apar pe paginile din spatele autentificării. |
| Categorii de date cu caracter personal | Numele de utilizator și parola contului de test, exclusiv criptate; un indiciu pentru numele de utilizator (primul caracter și lungimea); adresa de autentificare, lista paginilor, numele câmpurilor de autentificare, indicatorul de reușită, persoana care l-a creat, momentele, ultimul rezultat ca un cod scurt (domain_logins). Pentru o sarcină în curs, o copie a textului criptat (câmpul „pachet de autentificare” în scan_jobs). Din paginile din spatele autentificării: structura formularelor ca la A.4, fără capturi de ecran și fără cookie-uri. |
| Sursă | Introduse de Client în cont. |
| Temei juridic (stabilit de operator) | Stabilit de Client. Clientul garantează că are dreptul de a folosi contul de test. |
| Destinatari | Niciunul. Nici Clientul, nici asistența, nici interfața de programare nu pot citi datele de autentificare; interfața afișează doar indiciul pentru numele de utilizator. |
| Țară terță | Niciuna. |
| Protecția datelor de autentificare | Numele de utilizator și parola sunt criptate imediat la stocare cu cheia publică a serverului de scanare (X25519, HKDF-SHA256, AES-256-GCM; domeniul este legat ca date asociate, astfel încât un text criptat nu poate fi atașat unui alt domeniu). Doar serverul de scanare are cheia privată. Serverul web, baza de date și copiile de rezervă conțin doar text criptat; nici noi nu îl putem decripta acolo. Serverul de scanare decriptează doar pentru rulare, transmite datele de autentificare containerului de verificare izolat doar prin intrarea standard, șterge imediat copia din sarcină și nu o scrie în niciun rezultat, jurnal sau text de eroare. Pe drumul către site-ul Clientului, ele sunt protejate doar de criptarea acelui site; limitele acestui transport sunt descrise în secțiunea 10. |
| Stocare | Datele de autentificare stocate până la ștergerea de către Client. La ștergere, textul criptat este suprascris cu date aleatorii de aceeași lungime, iar rândul este șters; sarcinile în așteptare sunt eliminate (fe_login_loeschen()). Odată cu domeniul, rândul dispare printr-o cheie externă. Serverul de scanare elimină copiile din sarcini după rulare; orice rest (sarcină întreruptă, server de scanare căzut) este eliminat de rularea de stare cel târziu după o oră (fe_login_aufraeumen(), partea „login_jobs”). Copiile de rezervă ale bazei de date conțin textul criptat până la expirarea copiei de rezervă după 14 zile. |
| Măsuri tehnice și organizatorice | Secțiunea 8. În special: criptare asimetrică cu chei separate; listă de blocare pentru căile de deconectare și ștergere; fără capturi de ecran în spatele autentificării; funcție doar pentru planurile plătite și domeniile verificate; fiecare modificare în jurnalul de activitate (fără datele de autentificare). |
Nu am construit în mod intenționat nicio modalitate de a stoca date de autentificare pentru serverul Clientului, zona de administrare a CMS-ului sau conturile de găzduire. Contul de test este un cont de vizitator pe site-ul Clientului, nu un acces la sistemul Clientului.
A.6 Parcursuri configurate ale formularelor, verificări în browser și sondă independentă
| Câmp | Mențiune |
|---|
| Scop | Un formular monitorizat este parcurs într-un browser real (Chromium, WebKit sau ambele) până chiar înainte de trimitere: încărcarea paginii, efectuarea clicurilor prealabile (cel mult cinci, niciodată pe un câmp de introducere sau pe un buton de trimitere), completarea câmpurilor cu valori vizibil sintetice (cum ar fi o adresă sub terminația rezervată .invalid), avansarea prin formularele cu mai mulți pași. Verificarea în browser nu trimite nimic; trimiterea este blocată tehnic în browser. În plus, măsurători de timp și comparații vizuale ale formularului. |
| Categorii de persoane vizate | Ca la A.4 (persoanele vizibile pe pagina formularului); personalul Clientului introdus ca persoane responsabile (A.3). |
| Categorii de date cu caracter personal | Configurație: adresa formularului, selectorii, adresa de intrare, pașii de clic, alegerea browserului, eticheta, criticitatea, atribuirea, termenul (monitored_forms). Rezultate per rulare: starea, motivul tehnic al eșecului, mesajele de eroare curățate, măsurătorile de rețea și de timp, o imagine a formularului ca JPEG de cel mult 32 KB cu câmpurile de introducere mascate (form_browser_runs). Observații per verificare (form_observations), serii temporale (form_performance). Sarcini cu o listă de ținte (câmpurile „ținte” și „rezultat” în scan_jobs). |
| Acces de test | Dacă Clientul a salvat un cont de test (A.5), verificarea completă îl folosește și pentru parcursurile configurate ale formularelor. Conform codului măsurat, verificările independente în browser dintre două verificări complete funcționează fără cont de test. |
| Sondă independentă | Este prevăzut un al doilea punct de verificare într-o altă locație, care ar face o verificare încrucișată înaintea unei alerte. Ar primi domeniul, configurația curățată și identificatorul sarcinii, nicio dată introdusă de vizitatori și nicio dată de autentificare. În prezent nu este configurat (dezactivat implicit). Fără sondă nu există probe dintr-o a doua locație; o alertă se bazează atunci pe propria noastră măsurătoare. |
| Sursă | Configurate de Client; rezultatele provin din preluarea paginii Clientului. |
| Temei juridic (stabilit de operator) | Stabilit de Client pentru conținutul site-ului său și pentru responsabilitățile personalului său. |
| Destinatari | Clientul; dacă este configurată o sondă, operatorul acesteia (în prezent nimeni). |
| Țară terță | Niciuna. |
| Stocare | Rezultatele rulărilor în browser, sarcinile în browser finalizate și seriile temporale după 13 luni (rularea nocturnă de ștergere, părțile „browser_runs”, „browser_jobs”, „form_performance”). Configurațiile până la ștergerea domeniului (individual pot fi modificate sau dezactivate, nu șterse); odată cu domeniul dispar, împreună cu rulările, observațiile și seriile temporale, prin chei externe. |
| Ce dovedește măsurătoarea | Durate și stări din browserul nostru de verificare. Ele nu măsoară ce experimentează vizitatorii reali și nu dovedesc nici rate de finalizare, nici solicitări pierdute. |
| Măsuri tehnice și organizatorice | Secțiunea 8. În special: trimiterea împiedicată tehnic; doar adrese de pe același domeniu; imagini mascate; container de verificare izolat. |
A.7 „Fix it for me” – codul formularului introdus
| Câmp | Mențiune |
|---|
| Scop | Clientul introduce codul formularului său; un model lingvistic de pe propriul nostru hardware integrează modulul de protecție. Se returnează fișierul modificat, un patch, rezultatul unei verificări de sintaxă și o indicație dacă apelul de verificare a fost efectiv integrat. Fără cod introdus, serviciul livrează un modul gata făcut cu numele câmpurilor din ultima scanare. |
| Categorii de persoane vizate | Persoanele ale căror date se află întâmplător în codul introdus (cum ar fi o adresă de destinatar, nume în comentarii, date de autentificare pentru un server de e-mail). |
| Categorii de date cu caracter personal | Codul introdus, cel mult 30 000 de caractere. În baza de date doar o intrare în jurnalul de activitate (acțiunea „fix_ai” cu spațiul de lucru și momentul), care se socotește în limita zilnică de, în prezent, zece apeluri per spațiu de lucru. |
| Sursă | Introdus de Client. |
| Temei juridic | Executarea contractului cu Clientul (art. 6(1)(b) RGPD) pentru codul însuși; pentru datele terților conținute întâmplător în acesta, Clientul stabilește temeiul. |
| Destinatari | Niciunul. Modelul lingvistic rulează pe propriul nostru server de scanare din rețeaua internă; niciun serviciu extern de IA, nici măcar ca soluție de rezervă. |
| Țară terță | Niciuna. |
| Stocare | Codul nu este stocat. Pentru verificarea de sintaxă se creează un fișier temporar, care este șters imediat după aceea. Intrarea din jurnalul de activitate este ștearsă după 365 zile. |
| Notă pentru Client | Codul care conține parole, chei API sau date cu caracter personal ar trebui curățat înainte de a fi introdus. Nu verificăm conținutul. |
| Măsuri tehnice și organizatorice | Secțiunea 8. În special: doar proprietari și administratori în planurile plătite; codul introdus este transmis modelului marcat ca date și nu este executat niciodată; nicio încărcare pe serverele terților. |
A.8 Marca white-label și persoanele de contact ale agenției
| Câmp | Mențiune |
|---|
| Scop | Rapoartele, rapoartele scurte, jurnalele probatorii și portalul pentru clienți ale unei agenții (planul Business) apar sub marca acesteia, la cerere pe un subdomeniu propriu al agenției. |
| Categorii de persoane vizate | Persoanele de contact din cadrul agenției al căror nume sau date de contact apar în linia de contact. |
| Categorii de date cu caracter personal | Denumirea firmei, site-ul web, linia de contact, nota pentru client, culoarea de accent, aspectul, fișierul logo, comutatorul pentru mențiunea formexposed, domeniul propriu cu identificatorul de verificare și starea verificării (workspace_branding). |
| Sursă | Introduse de agenție. |
| Temei juridic | Executarea contractului cu agenția (art. 6(1)(b) RGPD). Acolo unde linia de contact numește personal al agenției, agenția stabilește temeiul. |
| Destinatari | Oricine căruia agenția îi dă un raport, un raport scurt sau un link de portal. |
| Țară terță | Niciuna. |
| Stocare | Până la modificarea de către agenție; marca și fișierul logo dispar odată cu spațiul de lucru (fe_arbeitsbereich_daten_loeschen()). Un domeniu propriu a cărui verificare DNS eșuează timp de șapte zile este dezactivat. Domeniul propriu este dezactivat implicit. |
| Măsuri tehnice și organizatorice | Secțiunea 8. |
A.9 Contoare, indicatori de stare și erori de câmp din plugin și extensie
| Câmp | Mențiune |
|---|
| Scop | O dată pe zi, pluginul WordPress și extensia TYPO3 raportează cifre despre formularele de pe site-ul conectat: trimiteri blocate per motiv, trimiteri, e-mailuri trimise și eșuate, indicatori de stare ai setărilor formularelor, solicitări stocate per sursă și perioadă de stocare. Opțional, dezactivat implicit: evenimente ale formularelor și categorii de erori de câmp per poziție a câmpului. Din aceste cifre rezultă „Protecția în cifre”, raportul lunar, alerta de inactivitate și notificările privind setările riscante. |
| Clasificare | Cifrele sunt concepute astfel încât să nu descrie nicio persoană. Le enumerăm în Partea A deoarece provin din evenimente de pe site-ul Clientului declanșate de vizitatorii Clientului; în opinia noastră, ele sunt date cu caracter personal cel mult în cazuri-limită (un site cu foarte puține trimiteri într-o anumită zi). Transmiterea însăși (chei, versiuni, host) se află în Partea B (B.20). |
| Categorii de persoane vizate | Vizitatorii site-ului Clientului care trimit un formular. |
| Categorii de date cu caracter personal | Cifre zilnice per host: blocate în total și per motiv, trimiteri, e-mailuri trimise și eșuate, categoria de eroare la trimiterea e-mailului (doar una din patru categorii, niciodată textul erorii, deoarece acesta poate conține adrese de destinatari), numărul de răspunsuri reCAPTCHA, solicitări șterse și eliberate (plugin_stats). Stare: versiunile dintr-o listă fixă de pluginuri pentru formulare, CAPTCHA și e-mail, indicatori ai setărilor ca numere, perioadele de stocare (plugin_health). Notificări de modificare: numele și versiunea unui plugin actualizat (plugin_changes). Opțional: contoare per formular și zi, cu categorii de erori per poziție a câmpului (form_metrics). Niciodată: date introduse, nume de câmpuri, parole, fișiere, adrese de e-mail, nume, adrese IP sau identificatori persistenți ai vizitatorilor. |
| Sursă | Pluginul de pe site-ul Clientului, printr-o interfață de programare, folosind secretul de conectare al site-ului. |
| Temei juridic (stabilit de operator) | Stabilit de Client; Clientul decide dacă activează contoarele opționale și cum își informează vizitatorii. |
| Destinatari | Clientul. Domeniile din linkurile din mesajele blocate intră în protecția colectivă (B.21). |
| Țară terță | Niciuna. |
| Stocare | Cifrele zilnice, notificările de modificare și contoarele formularelor după 13 luni (rularea nocturnă de ștergere, părțile „plugin_stats” și „form_metrics”). Indicatorii de stare sunt suprascriși la fiecare raportare. Toate datele pluginului pentru un host dispar de îndată ce niciun domeniu din sistem nu mai face trimitere la acel host (imediat la ștergerea ultimului domeniu; datele vechi nocturn, partea „orphan_hosts”). |
| Ce dovedesc cifrele | Ceea ce a numărat pluginul. Ele nu dovedesc nici rate de finalizare, nici solicitări pierdute. |
| Măsuri tehnice și organizatorice | Secțiunea 8. În special: acceptare doar cu perechea de chei legată de site; sunt acceptate doar chei și numere cunoscute, restul este eliminat; zilele din afara unei ferestre de 14 zile sunt respinse. |
A.10 Limita: ce rămâne doar pe site-ul Clientului
Următoarele funcții ale pluginului WordPress și ale extensiei TYPO3 prelucrează date exclusiv pe serverul Clientului. Acestea nu ajung la noi și nu avem acces la ele. Răspunde exclusiv operatorul site-ului; operatorul decide asupra activării, perioadelor de stocare și modului în care își informează vizitatorii. În acest scop, pluginul propune paragrafe pentru politica de confidențialitate a operatorului.
| Funcție | Ce se prelucrează local | Stocarea de partea Clientului |
|---|
| Carantină | Trimiterile oprite, cu motivul, care pot fi eliberate prin e-mail la adresa site-ului | 14 zile |
| Plasă de siguranță | Trimiterile al căror e-mail din formular a eșuat, pentru retrimitere (activată implicit) | 30 de zile |
| Problemă aritmetică în loc de reCAPTCHA | Exercițiu aritmetic în browserul vizitatorului, fără serviciu terț (dezactivat implicit) | – |
| Setări de stocare | Ștergerea solicitărilor stocate în pluginurile de formulare după perioada aleasă de operator (dezactivată implicit) | conform configurării |
| Limitarea ratei | un identificator de scurtă durată derivat din adresa IP, care nu ne este transmis | de scurtă durată |
| Contoare zilnice locale | Valorile contoarelor înainte de transmitere | cel mult 14 zile |
| Înregistrator pentru administratori | selectori tehnici și pași de navigare în memoria de sesiune a browserului unui administrator autentificat; datele introduse nu sunt citite. Se transmite doar configurația selectată (apoi A.6) | cel mult 15 minute |
| Ajutor pentru vizitatori | poate fi activat separat; nu stochează ciorne și nu retrimite automat | – |
| Observarea noilor reguli antispam | loviturile suplimentare sunt numărate local, fără activare automată | șapte zile |
A.11 Protecția formularelor (formconfirmed)
| Câmp | Mențiune |
|---|
| Scop | Evaluarea trimiterilor prin formularele de pe site-urile Clientului, pentru a recunoaște trimiterile automate: emiterea și verificarea sarcinilor (dovadă de lucru), tokenuri de verificare de unică folosință, timpul de completare, câmpul capcană, cererile repetate în număr mare; la cererea Clientului, evaluarea textului mesajului de către un model lingvistic. Doar pentru Clienții care activează protecția formularelor. |
| Categorii de persoane vizate | Vizitatorii site-urilor Clientului care deschid o pagină cu un formular protejat sau îl trimit. |
| Categorii de date cu caracter personal | Adresa IP (stocată doar trunchiată și hash-uită cu o cheie care se schimbă zilnic), adresa și domeniul paginii, momentele de timp și timpul de completare, câmp capcană completat da/nu, identificatorul browserului în jurnalul serverului web; doar dacă verificarea conținutului este activată, textul mesajului (doar în memoria de lucru). |
| Sursa | Browserul vizitatorului (sarcină, token de verificare); serverul Clientului (cerere de verificare, eventual text). |
| Destinatari | Clientul (scor, acțiune, motive). Niciun alt destinatar; nicio persoană împuternicită secundară pentru această prelucrare. |
| Țară terță | Niciuna. |
| Durată de stocare | Identificatorul hash-uit 1 oră; tokenurile de verificare utilizate cel mult 11 minute; rezultatele verificării fără adresă IP și fără text 30 de zile; cifrele zilnice 400 de zile; jurnalul serverului web 14 zile; textul nu este stocat. |
| MTO | Secțiunea 8; în plus, trunchiere și hash cu cheie zilnică, sarcini semnate, utilizare unică, model lingvistic pe hardware propriu, fără înregistrarea textului în jurnale. |
4. Partea A – destinatari, persoane împuternicite secundare și transferuri către țări terțe
Tabelul următor enumeră destinatarii pe care îi recrutăm noi înșine și care pot primi date din Partea A. Lista determinantă, actualizată permanent, este pagina Persoane împuternicite secundare; dacă aceasta diferă de acest tabel, este vorba de o constatare, nu de o problemă de formatare.
| Destinatar | Ce primește | Țară terță | Temei | Stare |
|---|
| Namecheap, Inc. (Private Email), Phoenix, Arizona, USA | Căsuța poștală de control a verificării livrării (A.1); trimiterea e-mailurilor de alertă (A.3), a confirmărilor și a rapoartelor către abonații portalului (A.2) | Locul prelucrării încă de verificat; vezi pagina „Persoane împuternicite secundare” | Acord de prelucrare a datelor; temeiul transferului încă de verificat | Deschis. Contractul relevant, locurile efective de prelucrare și temeiul transferului nu sunt încă documentate. Această evidență nu confirmă nici o certificare, nici un contract încheiat. |
| Namecheap, Inc. (registrar, DNS; redirecționarea e-mailurilor până la configurarea căsuței poștale) | Până la configurarea căsuței poștale, e-mailurile generale primite la adrese de pe domeniul nostru; nu și copiile din verificarea livrării, care sosesc doar cu înregistrări MX care indică direct căsuța poștală (A.1) | SUA | de verificat: certificare în cadrul EU-US Data Privacy Framework sau clauze contractuale standard | În uz; temei deschis. |
| Propriul nostru server de scanare cu un model lingvistic local | Structura formularelor pentru clasificare (A.4), codul introdus (A.7), accesul de test decriptat doar în timpul rulării (A.5) | – | Operat de noi, nu de un terț | În uz. |
| Sondă independentă într-o a doua locație | Domeniul, configurația curățată, identificatorul sarcinii (A.6) | în funcție de locație | de stabilit înainte de punerea în funcțiune | Neconfigurată. |
Găzduire: niciun terț. Aplicația, baza de date, capturile de ecran și copiile de rezervă sunt păstrate pe propriile noastre servere din Polonia. Dacă ne mutăm la un centru de date sau la un furnizor de cloud, acest paragraf trebuie rescris.
4.1 Canalele de alertă alese de Client
Pe lângă destinatarii pe care îi recrutăm, există canale pe care Clientul le alege pentru alertele sale (A.3). Serverul nostru declanșează transmiterea; Clientul stabilește destinația și furnizorul. Alegerea unui canal nu ne scutește de propriile obligații în calitate de persoană împuternicită. Rolul, contractul și garanțiile necesare pentru țările terțe trebuie stabilite pentru fiecare furnizor; pentru serviciile de chat acest lucru nu a fost încă finalizat (întrebare deschisă pentru verificarea juridică).
| Canal | Ce se trimite | Sediul furnizorului |
|---|
| E-mail | Domeniul, evenimentul, explicația, linkul; la adresa introdusă | prin Namecheap, Inc. (Private Email), Phoenix, Arizona, USA |
| Webhook către o adresă aleasă liber | Evenimentul ca JSON (domeniu, evenimente, linii, link, marcaj de timp), semnat cu secretul destinației | stabilit de Client |
| Slack, Discord, Microsoft Teams, Google Chat | aceeași notificare ca mesaj de chat la adresa de webhook introdusă | predominant SUA |
| Telegram | destinație aleasă de Client; trimitem mesajul prin botul nostru la ID-ul de chat conectat | în afara UE, fără decizie privind caracterul adecvat; temeiul transferului este o întrebare deschisă pentru verificarea juridică |
În niciun caz nu se trimite conținutul unui mesaj al unui vizitator. Notificările conțin domeniul, evenimentul și linkul.
5. Partea B – art. 30(1): prelucrare pe propria răspundere
Operator pentru tot ce se află în această parte: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia, contact@lukaswojcik.com. Nu este necesar un reprezentant (stabilit în Uniune). Nu este desemnat un responsabil cu protecția datelor (secțiunea 9). Măsuri tehnice și organizatorice: secțiunea 8 și pagina Măsuri tehnice și organizatorice. Modul în care persoanele vizate își exercită drepturile este descris pe pagina Acces, ștergere și celelalte drepturi ale dumneavoastră; titularii de cont își pot descărca singuri datele ca fișier (Setări).
Atunci când ne bazăm pe interese legitime (art. 6(1)(f) RGPD), numim interesul și motivul pentru care un mijloc mai puțin intruziv nu este suficient. Evaluarea comparativă reprezintă aprecierea noastră; aceasta face parte din verificarea juridică.
B.1 Vizitatorii site-ului nostru – jurnalele serverului web
| Câmp | Mențiune |
|---|
| Scop | Funcționarea și securitatea site-ului și a aplicației: livrare, depanare, detectarea atacurilor și a supraîncărcării. |
| Categorii de persoane vizate | Oricine deschide o pagină de pe formexposed.com sau form.exposed, inclusiv vizitatorii paginilor Clienților al căror browser încarcă imaginea insignei noastre (B.18), destinatarii care deschid un link de raport sau de confirmare și site-urile al căror plugin apelează interfața noastră. |
| Categorii de date cu caracter personal | Adresa IP completă, momentul, adresa solicitată, codul de stare, octeții transferați, pagina de proveniență (referrer), identificatorul browserului (user agent). |
| Unde sunt stocate | Jurnalele de acces ale proxy-ului din amonte și ale serverului web, ca fișiere pe serverul web, nu în baza de date. |
| Sursă | Browserul sau programul care face cererea. |
| Temei juridic | art. 6(1)(f) RGPD. Interes: funcționarea sigură și neîntreruptă. Evaluare comparativă: fără adresa completă, cererile repetate de la același expeditor nu pot fi corelate și atacurile nu pot fi respinse; o adresă trunchiată nu permite această distincție. Jurnalele nu sunt combinate cu alte date și sunt șterse după o perioadă scurtă. |
| Destinatari | Niciunul. |
| Țară terță | Niciuna. |
| Stocare | 14 zile: rotație zilnică cu 14 generații, apoi suprascriere (serviciul de rotație a jurnalelor al sistemului, nu rularea nocturnă de ștergere a aplicației). |
| Măsuri tehnice și organizatorice | Secțiunea 8. |
B.2 Jurnalul accesărilor paginilor din aplicație
| Câmp | Mențiune |
|---|
| Scop | Securitate și detectarea abuzurilor (cine solicită ce și cât de des), trasabilitatea accesărilor contului, statistici simple de utilizare fără un serviciu de analiză. |
| Categorii de persoane vizate | Toți vizitatorii site-ului și utilizatorii aplicației, la accesări reale de pagini (fără cereri în fundal, fără trimiteri de formulare). |
| Categorii de date cu caracter personal | Adresa IP completă, țara derivată din aceasta la scriere (bază de date geografică locală, fără interogarea unui terț), ID-ul contului pentru utilizatorii autentificați, adresa solicitată și pagina de proveniență (tokenurile de acces din acestea, cum ar fi cele ale linkurilor de raport sau de portal, mascate), identificatorul browserului și tipul dispozitivului, sistemul de operare și browserul derivate din acesta, limba, momentul (access_logs). În timpul „Vizualizare ca client” (B.14) nu se setează niciun ID de cont, astfel încât accesările paginilor de către asistență să nu apară în jurnalul Clientului. |
| Sursă | Cererea browserului. |
| Temei juridic | art. 6(1)(f) RGPD. Interes: prevenirea abuzurilor și trasabilitate. Evaluare comparativă: ca la B.1; perioada de stocare este mai lungă deoarece tiparele de abuz devin vizibile în decurs de săptămâni. Dacă adresa IP ar trebui trunchiată sau perioada de stocare scurtată este o întrebare deschisă pentru verificarea juridică. |
| Destinatari | Niciunul. Titularii de cont primesc propriile accesări ale paginilor în exportul de date. |
| Țară terță | Niciuna. |
| Stocare | 60 zile (nocturn, între 03:00 și 03:05, srv/cron_status.php, setarea „jurnalul accesărilor paginilor”). |
| Măsuri tehnice și organizatorice | Secțiunea 8. Adresa IP este preluată dintr-un antet redirecționat doar dacă cererea provine de la propriul nostru proxy din amonte și atunci doar intrarea adăugată de acel proxy; altfel, oricine și-ar putea declara originea după bunul plac. |
B.3 Cookie-uri și stocare în browser
| Câmp | Mențiune |
|---|
| Scop | Stocare necesară din punct de vedere tehnic: sesiune, protecție împotriva falsificării cererilor între site-uri (CSRF), numărarea limitelor pentru verificările fără cont, autentificare, menținerea autentificării la cerere, afișare luminoasă sau întunecată. |
| Categorii de persoane vizate | Vizitatorii și utilizatorii formexposed.com. |
| Categorii de date cu caracter personal | Cookie-ul de sesiune bpid (identificatorul sesiunii; expiră la închiderea browserului; HttpOnly, SameSite=Lax, Secure prin HTTPS). Cookie-ul bp_remember doar după alegerea opțiunii „Păstrează-mă conectat” (selector și verificator; 30 de zile). Stocarea locală bp_theme (luminos, întunecat sau sistem). În zona de administrare, în plus, setări locale de afișare ale operatorilor. Pentru limite se formează un hash din identificatorul sesiunii; identificatorul însuși nu este stocat. |
| Nesetate | Niciun cookie de analiză, publicitate sau urmărire. Programul de parteneriat (B.33) funcționează fără cookie. Imaginea insignei de pe paginile Clienților nu setează niciun cookie (B.18). reCAPTCHA poate seta cookie-uri de la Google la trimiterea unui formular protejat (B.23). |
| Temei juridic | Accesul la echipamentul terminal: strict necesar pentru serviciul solicitat de utilizator (§ 25(2) nr. 2 TDDDG, Legea germană privind protecția datelor în telecomunicații și serviciile digitale; art. 399(3) PKE, Legea poloneză privind comunicațiile electronice (Prawo komunikacji elektronicznej)). Prelucrarea: art. 6(1)(b) RGPD (cont) și (f) (securitate, limite). |
| Destinatari | Niciunul. |
| Țară terță | Niciuna. |
| Stocare | Sesiunea; 30 de zile pentru tokenul de memorare. Rularea nocturnă șterge tokenurile de memorare expirate din baza de date (remember_tokens); la deconectare, la schimbarea parolei și la revocarea unui dispozitiv, imediat. |
| Măsuri tehnice și organizatorice | Secțiunea 8. |
B.4 Verificarea gratuită fără cont – acceptare, limite și monitorizarea abuzurilor
| Câmp | Mențiune |
|---|
| Scop | Oricine poate verifica un domeniu fără cont. Pentru ca acest câmp de introducere să nu devină o armă împotriva site-urilor terților, se aplică limite eșalonate: o verificare anonimă per domeniu în șapte zile (după aceea, același raport), limite per adresă IP și per sesiune în 24 de ore, o limită zilnică pentru întregul sistem, blocarea domeniilor foarte noi, lista de blocare și opt-out, doar adrese publice. Tiparele suspecte sunt înregistrate și raportate operatorului. Limitele per adresă IP, per sesiune și pentru întregul sistem, numărate separat, se aplică și verificării din plugin fără cont (un plugin cu o pereche de chei legată numără per site în loc de per adresă) și opt-out-ului (B.30); instrumentul gratuit pentru antete (B.9) are propriile limite per adresă IP și zi și pentru întregul sistem. |
| Categorii de persoane vizate | Persoanele care declanșează o verificare, o cerere în instrumentul pentru antete sau un opt-out; serverele pe care este instalat un plugin. |
| Categorii de date cu caracter personal | Jurnalul fiecărei cereri: sursa (verificare, plugin, instrumentul pentru antete, opt-out), adresa IP completă, hash-ul identificatorului sesiunii, hostul verificat, țara din adresa IP, acceptată sau respinsă cu motivul, momentul (check_throttle). Anomalii: tipul (adresă IP, sesiune, țară, sistem), cheia (pentru tipul „IP”, adresa IP completă), tiparul, gravitatea, o scurtă descriere, momentele detectării și rezolvării, persoana care rezolvă (abuse_flags). Sarcina: hostul, modul, nivelul de încredere și un hash trunchiat al sesiunii ca identificator al solicitantului (scan_jobs). Raportul: identificatorul aleatoriu, hostul, limba, expirarea, prima vizualizare, numărul de vizualizări (reports). Vechimea domeniului, păstrată în cache, din interogarea registrului (domain_age_cache). |
| Sursă | Datele introduse de persoană; cererea acesteia; interogarea registrului (RDAP) pentru vechimea domeniului. |
| Temei juridic | Efectuarea verificării solicitate: art. 6(1)(b) RGPD (utilizarea verificării gratuite conform Condițiilor de utilizare); în subsidiar, (f). Limite și monitorizare: art. 6(1)(f). Interes: împiedicarea folosirii serviciului ca instrument împotriva site-urilor terților sau ca tun de spam. Evaluare comparativă: fără legătura cu adresa și sesiunea, limitele nu ar putea fi aplicate; perioada de șapte zile este la fel de scurtă ca cea mai lungă limită calculată pe baza ei. |
| Destinatari | Google (reCAPTCHA la trimitere, B.23). Pentru vechimea domeniului, scanerul interoghează serviciul de redirecționare RDAP rdap.org, care trimite mai departe către registrul competent; se transmite doar numele domeniului. La apariția unei anomalii, operatorul primește un semnal prin Telegram fără nicio variabilă (fără host, fără adresă). Raportul poate fi văzut de oricine are linkul său aleatoriu. |
| Țară terță | SUA prin reCAPTCHA (B.23). |
| Stocare | Jurnalul cererilor 7 zile (nocturn, srv/cron_status.php). Anomaliile rezolvate la 90 de zile după rezolvare; cele nerezolvate rămân până când cineva le rezolvă (secțiunea 10). Rapoartele anonime expiră după 30 zile; rularea nocturnă șterge apoi raportul, sarcina, rezultatul verificării, formularele, constatările și imaginile (fe_reports_aufraeumen()). Un administrator poate debloca manual intrările pentru o adresă; aceasta șterge jurnalul ei din ultimele 24 de ore. |
| Măsuri tehnice și organizatorice | Secțiunea 8. Oprire de urgență pentru toate verificările anonime în zona de administrare; contrapresiune care nu mai acceptă noi verificări gratuite atunci când există un volum restant. |
B.5 Verificarea de către crawler a site-urilor terților
| Câmp | Mențiune |
|---|
| Scop | Verificarea securității formularelor de contact publice: măsuri de protecție împotriva spamului și abuzurilor, caracteristici de protecție a datelor și de accesibilitate, scripturi terțe încorporate, comportamentul după respingerea în bannerul de cookie-uri, afișarea pe mobil. Se aplică verificărilor fără cont (B.4), domeniilor dintr-un cont care nu sunt încă verificate și ca bază pentru studiu (B.7) și verificarea clienților potențiali (B.8). Pentru domeniile verificate dintr-un cont acționăm în numele Clientului (A.4). |
| Comportamentul crawlerului | Identificator propriu cu trimitere la pagina crawlerului; citește robots.txt înainte de verificare și se oprește dacă o regulă disallow acoperă pagina principală (la fel dacă robots.txt nu poate fi accesat sau există o eroare de server); regulile disallow pentru subcăi individuale nu sunt respectate separat. Pulsul formularelor, preluarea dovezii, instrumentul pentru antete și căutarea fișierelor expuse nu citesc robots.txt. Cel mult opt pagini publice per verificare, plus până la trei pagini cu un clic pe „Respinge” în bannerul de cookie-uri, până la trei pagini în vizualizare de telefon, sondaje active pentru domeniile verificate și până la cinci pagini în spatele unei autentificări (A.5); paginile sunt încărcate una după alta, nu în paralel; doar adrese publice, fără rețele interne, redirecționările sunt reverificate; lista de blocare și opt-out-ul sunt verificate înainte de acceptare și a doua oară în scaner. Pasiv: fără dovada controlului, pentru Clienți nu se trimite nimic (excepție: verificările interne ale propriilor noastre domenii de test și demonstrație, B.6). |
| Categorii de persoane vizate | Operatorii site-urilor verificate (în măsura în care sunt persoane fizice, cum ar fi întreprinzătorii individuali); persoanele vizibile întâmplător pe paginile verificate. |
| Categorii de date cu caracter personal | Ca la A.4: adresele și titlurile paginilor, structura formularelor (numele, tipurile și etichetele câmpurilor, fără valorile câmpurilor), măsurile de protecție, scripturile terțe (adrese; ID-urile de cont ale pixelilor și ale instrumentelor de înregistrare sunt înlocuite înainte de stocare), comportamentul bannerului de cookie-uri, capturile de ecran (zona vizibilă a paginii principale, formularele). Dacă în formular apare o adresă de destinatar, doar domeniul acesteia (scans, forms, findings, scan_screenshots). |
| Sursă | Pagini accesibile public. |
| Temei juridic | art. 6(1)(f) RGPD. Interes: efectuarea verificării de securitate solicitate; atenționarea operatorilor de site-uri cu privire la punctele slabe care le pot afecta vizitatorii. Evaluare comparativă: se citește doar ceea ce vede orice vizitator, într-o măsură redusă și fără a trimite nimic; operatorul își poate exclude oricând domeniul permanent, fără dovezi. Informarea conform art. 14 RGPD se face prin pagina crawlerului, prin opt-out și prin Politica de confidențialitate; dacă aceasta este suficientă în sensul art. 14(5)(b) este o întrebare deschisă pentru verificarea juridică. |
| Destinatari | Cel care declanșează raportul și oricine căruia acesta îi dă linkul aleatoriu; modelul lingvistic local de pe propriul nostru server, acolo unde tipul formularului este neclar (structura formularului, titlul și adresa paginii, textul vizibil al formularului). Avertismentele privind vulnerabilitățile din versiunile pluginurilor nu apar niciodată în rapoartele anonime. |
| Țară terță | Niciuna. |
| Stocare | Anonim: 30 zile (B.4). Verificarea clienților potențiali: 90 de zile (B.8). Studiu: până la publicare (B.7). Domeniu într-un cont: cel mult 13 luni, ultima verificare rămâne; imediat odată cu domeniul. Verificările interne ale operatorului fără domeniu și fără raport (cum ar fi cele create din linia de comandă): nicio perioadă de stocare (secțiunea 10). Fișierele temporare de pe serverul de scanare sunt șterse după fiecare rulare. |
| Măsuri tehnice și organizatorice | Secțiunea 8. În special: container de verificare separat cu privilegii reduse, sistem de fișiere doar în citire, limită de memorie și rețea proprie; verificare dublă a țintei. |
B.6 Trimiteri de test active
| Câmp | Mențiune |
|---|
| Scop | Verificarea faptului că un formular de contact acceptă o trimitere fără protecție, că CAPTCHA, capcana (honeypot), tokenul, validarea adresei de e-mail și limitarea ratei funcționează pe partea serverului și că pot fi injectate antete. |
| Condiție prealabilă | Pentru Clienți, doar pentru domeniile pentru care a fost furnizată dovada controlului (înregistrare DNS, metaetichetă, fișier sau plugin conectat); în plus, operatorul folosește un instrument intern în linia de comandă pentru a crea verificări cu nivelul „verificat” pentru propriile noastre domenii de test și demonstrație. Doar cu comutatorul global activat, doar pentru un formular clasificat cu certitudine ca formular de contact general. Niciodată pentru comenzi, rezervări, înregistrări, newslettere, plăți, încărcări de fișiere, câmpuri obligatorii cu date cu caracter personal reale sau domenii ale autorităților publice, instituțiilor medicale sau de învățământ. |
| Categorii de persoane vizate | Personalul Clientului care primește e-mailurile din formulare. |
| Categorii de date cu caracter personal | Trimiterea de test nu conține date cu caracter personal: expeditorul „FormExposed Security Scanner”, propria noastră adresă de expeditor sau o adresă sub .invalid, un subiect marcat și un text în limba paginii, cu trimitere la pagina crawlerului și la opt-out și numărul verificării. Stocate de noi: răspunsul paginii, constatările, o imagine a paginii următoare (ca la A.4). |
| Amploare | Cel mult cinci trimiteri per verificare (setare, implicit 5); recurent, la frecvența de verificare a planului, zilnic în cel mai înalt plan. |
| Sursă | Instrucțiunea Clientului. |
| Temei juridic | Executarea contractului cu Clientul (art. 6(1)(b) RGPD); trimiterile ajung în propriul formular al Clientului. Pentru destinatarii de la Client: organizarea Clientului. |
| Destinatari | Clientul (e-mailul din formularul său). |
| Țară terță | Niciuna prin noi. |
| Stocare | Rezultatele ca la A.4. |
| Măsuri tehnice și organizatorice | Secțiunea 8. Injecția în antete este doar detectată, niciodată efectuată cu un destinatar real; validarea adresei de e-mail folosește doar un domeniu care nu poate exista. |
B.7 Studiul „Indicele de securitate a formularelor”
| Câmp | Mențiune |
|---|
| Scop | Statistici privind protecția formularelor de contact într-o țară sau un sector. Sunt publicate doar totaluri, fără numele site-urilor; segmente doar de la 20 de pagini cu formular în sus. |
| Categorii de persoane vizate | Operatorii site-urilor de pe listă; persoanele vizibile întâmplător. |
| Categorii de date cu caracter personal | Ca la B.5, doar pasiv. În plus, lista: hostul, segmentul, starea, sarcina (study_domains); studiul cu titlul, țara, totalurile rezultatelor (studies). |
| Sursă | O listă de site-uri publice întocmită de operator; paginile însele. |
| Temei juridic | art. 6(1)(f) RGPD. Interes: afirmații statistice despre starea securității formularelor. Evaluare comparativă: pasiv, cu debit limitat (puține sarcini per rulare), se aplică lista de blocare și opt-out-ul, publicare doar ca totaluri, datele brute sunt șterse. |
| Destinatari | Publicul, doar totaluri. |
| Țară terță | Niciuna. |
| Stocare | Datele brute (rezultatele verificărilor, formularele, constatările, imaginile, sarcinile) sunt șterse la publicare (fe_studie_veroeffentlichen()). Lista hosturilor cu segmentul rămâne ulterior; pentru aceasta și pentru studiile care nu sunt publicate niciodată nu există o perioadă de stocare (secțiunea 10). Operatorul decide ce liste sunt verificate și dacă studiile sunt publicate. |
| Măsuri tehnice și organizatorice | Secțiunea 8. |
B.8 Verificarea clienților potențiali (modul de prospectare pentru agenții)
| Câmp | Mențiune |
|---|
| Scop | O agenție (planul Business) verifică pasiv site-ul unui client potențial și primește un raport scurt sub marca sa și raportul pasiv. Nu contactăm pe nimeni; agenția transmite ea însăși linkul. |
| Categorii de persoane vizate | Operatorul site-ului verificat; persoanele vizibile întâmplător; personalul agenției care declanșează verificarea. |
| Categorii de date cu caracter personal | Ca la B.5, doar pasiv. În plus: spațiul de lucru, persoana care declanșează verificarea, hostul, identificatorul aleatoriu al raportului, momentul (prospect_checks). |
| Sursă | Datele introduse de agenție; pagini publice. |
| Temei juridic | art. 6(1)(f) RGPD (interesul nostru de a furniza serviciul și interesul agenției pentru o abordare bine fundamentată). Rolurile agenției și ale noastre și obligațiile agenției la transmiterea raportului sunt întrebări deschise pentru verificarea juridică: dacă agenția trimite raportul prin e-mail în mod nesolicitat sau dă un telefon, este vorba de marketing direct care necesită consimțământ conform art. 398 PKE și § 7(2) UWG (Legea germană împotriva concurenței neloiale), chiar și între profesioniști. Aceasta este responsabilitatea agenției; Condițiile de utilizare o obligă în mod corespunzător. |
| Destinatari | Agenția și oricine căruia aceasta îi dă linkul. |
| Țară terță | Niciuna. |
| Stocare | Raportul și rezultatul verificării expiră după 90 de zile și sunt apoi șterse de rularea nocturnă (fe_reports_aufraeumen()); intrarea verificării este ștearsă după 90 de zile în rularea zilnică de protecție colectivă de la ora 04:00 (srv/cron_status.php). Odată cu spațiul de lucru, imediat. |
| Măsuri tehnice și organizatorice | Secțiunea 8. Cotă lunară (setare, implicit 30); aceeași pagină în decurs de șapte zile returnează același raport; se aplică opt-out-ul. |
B.9 Instrumentul pentru antete fără cont
| Câmp | Mențiune |
|---|
| Scop | Notă gratuită (de la A+ la F) pentru antetele de securitate ale paginii principale a unui domeniu. Două cereri, fără browser, fără formular, fără trimitere. |
| Categorii de persoane vizate | Persoanele care folosesc instrumentul; operatorii domeniului verificat. |
| Categorii de date cu caracter personal | Jurnalul cererilor ca la B.4 (sursa „headers”, adresa IP, hash-ul sesiunii, hostul). Rezultat: hostul, nota, punctele, antetele evaluate (header_checks). |
| Temei juridic | art. 6(1)(f) RGPD, ca la B.4 și B.5. |
| Destinatari | Google (reCAPTCHA, B.23). |
| Țară terță | SUA prin reCAPTCHA. |
| Stocare | Jurnalul cererilor 7 zile; rezultatele după, în prezent, 90 de zile (rularea nocturnă de ștergere, partea „header_checks”, setarea „headers_keep_days”). Pentru domeniile dintr-un cont, nota este redeterminată zilnic și stocată la domeniu. |
| Măsuri tehnice și organizatorice | Secțiunea 8. Limite per adresă IP și zi; se aplică opt-out-ul. |
B.10 Conturile de client
| Câmp | Mențiune |
|---|
| Scop | Gestionarea conturilor de client, a spațiilor de lucru și a planurilor. |
| Categorii de persoane vizate | Clienții (profesioniști) și membrii echipelor lor cu cont propriu. |
| Categorii de date cu caracter personal | Adresa de e-mail și forma ei normalizată, parola doar ca hash, prenumele (obligatoriu), numele de familie și firma (dacă sunt furnizate); aplicația nu stochează adresa și codul de TVA, acestea sunt furnizate doar la Stripe (B.26); starea, limba, modul de afișare, moneda, planul și starea facturării, ID-ul de client și de abonament Stripe, sfârșitul perioadei de facturare, rezilierea la sfârșitul perioadei, identificatorii de confirmare și resetare cu expirarea lor, noua adresă de e-mail până la confirmare, momentul înregistrării, ultima autentificare și ultima adresă IP, momentul revocării tuturor sesiunilor, datele pentru al doilea factor (B.11), raportul lunar activat/dezactivat, momentul e-mailului de reamintire, deblocările prin coduri, codul de recomandare și recomandarea (users). Spațiile de lucru cu numele, momentele, starea (workspaces); calitatea de membru cu rolul și data aderării (workspace_users). |
| Sursă | Înregistrarea și setările făcute de persoană; starea facturării de la Stripe. |
| Temei juridic | art. 6(1)(b) RGPD (contract). Ultima adresă IP: (f) (securitatea contului). |
| Destinatari | Stripe (B.26); furnizorul de servicii de e-mail pentru e-mailurile contului (B.25). Membrii aceluiași spațiu de lucru văd numele, adresa de e-mail și rolul celorlalți membri. |
| Țară terță | Prin Stripe și furnizorul de servicii de e-mail. |
| Stocare | Până la ștergerea de către titularul contului. La ștergere, propriile spații de lucru ale titularului pe care nu le mai folosește nimeni altcineva dispar împreună cu toate domeniile și datele acestora; spațiile de lucru cu alți membri trec la un alt membru, mai întâi la administratori, iar dintre aceștia la cel mai vechi. Calitățile de membru, tokenurile de memorare, dispozitivele, cheile API, codurile Telegram deschise, feedbackul privind rapoartele (B.35) și rândul contului sunt șterse; un abonament plătit în curs este mai întâi încheiat imediat la Stripe, fără rambursare (www/ajax.php, fe_konto_reste_loeschen()). O reziliere în zona de facturare produce în schimb efecte la sfârșitul perioadei; după aceea, contul continuă în planul gratuit. Ce rămâne este descris în secțiunea 6.4. Conturile niciodată confirmate și în care nu s-a făcut niciodată autentificarea sunt șterse după 30 de zile, cu excepția cazului în care spațiului lor de lucru îi este asociat un alt membru (rularea nocturnă de ștergere, partea „pending_accounts”). Nu există ștergerea conturilor inactive. Dacă contractul pentru cont încetează în alt mod, de exemplu prin rezilierea de către noi, ștergem contul cel târziu la 30 de zile după încetarea contractului; în prezent, acest lucru se face manual (angajament asumat în Acordul de prelucrare a datelor). |
| Măsuri tehnice și organizatorice | Secțiunea 8. |
B.11 Autentificare, dispozitive, al doilea factor și jurnalul de activitate
| Câmp | Mențiune |
|---|
| Scop | Protecția conturilor: limitarea încercărilor de autentificare și a altor încercări de introducere a parolei, afișarea și revocarea dispozitivelor conectate, autentificarea cu doi factori, trasabilitatea modificărilor. |
| Categorii de persoane vizate | Titularii de cont și membrii echipelor; persoanele care încearcă o autentificare, o înregistrare sau parola unui portal pentru clienți. |
| Categorii de date cu caracter personal | Încercări de autentificare: adresa IP, adresa de e-mail introdusă, reușita, momentul (login_attempts). Dispozitive: hash-ul identificatorului sesiunii (niciodată identificatorul însuși), legătura cu tokenul de memorare, adresa IP, identificatorul browserului și browserul, sistemul de operare și tipul dispozitivului derivate din acesta, momentele autentificării, ultimei activități și revocării, iar pentru „Vizualizare ca client” identificatorul persoanei de la asistență (login_sessions). Tokenuri de memorare pentru „Păstrează-mă conectat”: selector, verificator, expirare (remember_tokens). Al doilea factor: secretul criptat, momentul activării, ultimul pas de timp utilizat, codurile de recuperare doar ca hash (în users). Jurnalul de activitate: contul, spațiul de lucru, acțiunea, ținta, detaliile, adresa IP, țara, momentul (audit_logs). Contoare de încercări pentru autentificare, al doilea factor, confirmarea parolei, resetarea parolei, înregistrare și parolele portalurilor pentru clienți: o cheie HMAC derivată din scop și ID-ul contului (pentru o adresă necunoscută sau pentru o resetare, adresa de e-mail cu litere mici), adresa IP, contul și adresa IP împreună sau ID-ul portalului (și împreună cu adresa IP), numărul de încercări, expirarea; adresele de e-mail și IP nu sunt stocate acolo în clar (tabelul auth_attempt_buckets). |
| Temei juridic | art. 6(1)(b) RGPD coroborat cu art. 32 (lista dispozitivelor, al doilea factor) și (f) (încercările de autentificare, jurnalul de activitate). Interes: protecția conturilor împotriva preluării, documentarea modificărilor (art. 5(2)). Evaluare comparativă: o adresă trunchiată nu răspunde la întrebarea „am fost eu?”; jurnalul de activitate trebuie să dureze mai mult decât un litigiu care apare abia după luni de zile. |
| Destinatari | Niciunul. Titularul contului își vede dispozitivele și primește încercările de autentificare, dispozitivele și activitățile în exportul de date; în timpul unei sesiuni „Vizualizare ca client”, acolo nu apar nici adresa IP, nici browserul persoanei de la asistență. |
| Țară terță | Niciuna. |
| Stocare | Încercările de autentificare 7 zile; după o autentificare reușită, încercările eșuate de la aceeași adresă sunt șterse imediat. Contoarele de încercări la sfârșitul ferestrei lor de timp (în prezent 15 minute, o oră pentru resetarea parolei și înregistrare); cele expirate sunt șterse la următorul acces și de rularea nocturnă. Dispozitivele la 90 de zile după ultima utilizare sau după revocare (rularea nocturnă de ștergere, partea „sessions”), imediat odată cu contul. Tokenurile de memorare expiră după 30 de zile. Jurnalul de activitate 365 zile (nocturn); la ștergerea unui cont, intrările acestuia rămân până la sfârșitul perioadei de stocare (secțiunea 6.4). |
| Măsuri tehnice și organizatorice | Secțiunea 8. |
B.12 Dovada încheierii contractului
| Câmp | Mențiune |
|---|
| Scop | Dovedirea versiunii Condițiilor de utilizare, a Acordului de prelucrare a datelor și a Politicii de confidențialitate pe care un Client le-a acceptat sau de care a luat cunoștință la înregistrare, precum și a faptului că Clientul folosește serviciul în scopul activității sale profesionale. |
| Categorii de persoane vizate | Clienții. |
| Categorii de date cu caracter personal | Per document: contul, documentul, versiunea (hash-ul textului afișat), ocazia, adresa IP, identificatorul browserului, momentul (legal_consents). Versiunea afișată însăși, cu textul complet, limba, titlul și adresa, o dată per versiune (legal_versions; nu conține date cu caracter personal). |
| Temei juridic | art. 6(1)(b) și (f) RGPD (dovada încheierii contractului, apărarea împotriva pretențiilor). |
| Destinatari | Niciunul. Titularul contului își primește înregistrările în exportul de date. |
| Țară terță | Niciuna. |
| Stocare | Atât timp cât există contul; după ștergerea contului, patru ani de la consimțământ, apoi ștergere nocturnă (srv/cron_status.php). Justificarea din cod: termenul de prescripție de trei ani de la sfârșitul anului, rotunjit în sus. Dacă dreptul polonez sugerează un alt termen face parte din verificarea juridică. |
| Măsuri tehnice și organizatorice | Secțiunea 8. Dacă lipsește oricare dintre cele trei documente, înregistrarea este închisă. |
B.13 Invitații în echipă
| Câmp | Mențiune |
|---|
| Scop | Invitarea altor persoane într-un spațiu de lucru. |
| Categorii de persoane vizate | Persoanele invitate. |
| Categorii de date cu caracter personal | Adresa de e-mail, rolul, identificatorul invitației, persoana care invită, expirarea, momentul acceptării (workspace_invites); e-mailul de invitație din căsuța de ieșire (B.25). |
| Sursă | Introduse de membrul care invită. |
| Temei juridic | art. 6(1)(b) RGPD în raport cu Clientul; față de persoana invitată, (f) (interesul Clientului de a-și implica echipa). |
| Destinatari | Furnizorul de servicii de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Țară terță | Prin furnizorul de servicii de e-mail. |
| Stocare | O invitație este valabilă 14 zile și doar atât timp cât persoana care invită este proprietar sau administrator al spațiului de lucru. Invitațiile neacceptate după expirare, cele acceptate la 30 de zile după acceptare (nocturn, srv/cron_status.php și partea „invites” din cfg/fristen_lib.php). Odată cu spațiul de lucru, imediat. |
| Măsuri tehnice și organizatorice | Secțiunea 8. |
B.14 „Vizualizare ca Client” de către suport
| Câmp | Mențiune |
|---|
| Scop | Un superadministrator vede aplicația așa cum o vede un Client, pentru a rezolva o solicitare de suport („mie nu îmi apare butonul”). |
| Categorii de persoane vizate | Clientul în cauză; superadministratorul. |
| Categorii de date cu caracter personal | Tot ce vede Clientul în aplicație. Se înregistrează: un rând separat de dispozitiv cu identificatorul superadministratorului (login_sessions), începutul și sfârșitul în jurnalul de activitate (audit_logs). |
| Temei juridic | art. 6(1)(b) RGPD (suportul ca parte a serviciului), alternativ (f). |
| Limite | Cel mult o oră, apoi deconectare completă. Încheierea vizualizării îl deconectează complet și pe superadministrator, inclusiv din sesiunea din care a pornit; acesta revine în zona de administrare doar printr-o nouă autentificare cu parolă și al doilea factor. Se încheie imediat dacă superadministratorul este retrogradat sau blocat. Este blocat tot ce modifică contul Clientului: parola, adresa de e-mail, al doilea factor, dispozitivele, abonamentul, exportul, ștergerea, transferul. Zona de administrare este închisă pe durata sesiunii. Clientul vede accesul în lista sa de dispozitive și în exportul de date ca acces de suport. |
| Destinatari | Niciunul. |
| Țară terță | Niciuna. |
| Durată de stocare | Rândul de dispozitiv 90 de zile, jurnalul de activitate 365 zile. |
| MTO | Secțiunea 8. |
B.15 Domenii, dovada controlului și monitorizare
| Câmp | Mențiune |
|---|
| Scop | Serviciul de bază pentru Clienți: păstrarea domeniilor în cont, furnizarea dovezii controlului, verificarea periodică și detectarea modificărilor. Aceasta include pulsul formularului (o interogare ușoară, fără browser, la fiecare 10–30 de minute, în funcție de plan), supravegherea zilnică a DNS-ului de e-mail și a certificatului, data de expirare a domeniului, listele de blocare, fișierele expuse, versiunile vizibile din exterior, inventarul de scripturi, modificările vizuale ale formularului, întreruperile furnizorilor de CAPTCHA și de e-mail, precum și supravegherea vulnerabilităților pluginurilor de formulare. |
| Categorii de persoane vizate | Clienții și membrii echipelor acestora; titularii domeniilor, în măsura în care sunt persoane fizice. |
| Categorii de date cu caracter personal | Domeniul cu hostul, identificatorul public, nota, eticheta clientului, tipul și identificatorul dovezii, frecvența verificărilor, monitorizarea activată/dezactivată, ferestrele de mentenanță, valoarea unei solicitări, identificatorii pentru insignă, verificarea livrării și deploy hook, cheia pluginului, stările și cele mai recente rezultate ale supravegherilor (DNS, certificat, autenticitatea e-mailului formularului, liste de blocare, fișiere expuse, antete, versiuni) (domains). Pulsul pentru fiecare pagină de formular (form_pulse). Vulnerabilitățile rezultate din versiunile pluginurilor (vuln_hits). Inventarul de scripturi cu adresa, hash-ul, dimensiunea, aprobarea, cu persoana care aprobă și motivul (script_inventory, script_changes). Verificările ca la A.4. Pentru fișierele expuse se stochează calea, gravitatea și tipul, niciodată conținutul. |
| Interogări către terți | Interogări DNS (SPF, DMARC, MX, înregistrarea de dovadă). Interogarea registrului prin RDAP conform directorului IANA: doar numele de domeniu. Liste de blocare DNS (SpamCop, PSBL, Mailspike, SURBL; Spamhaus doar cu date de acces stocate, în prezent nu): adresele IP ale serverului web și ale serverului de e-mail și numele de domeniu, fără date ale vizitatorilor. Google Web Risk doar dacă este configurat (în prezent nu): adresa paginii principale. Autoritatea de marcare temporală: doar o valoare hash (B.19). WPVulnerability: doar identificatorul unui plugin sau al unei teme ori versiunea WordPress; comparația cu versiunea instalată a pluginului o efectuăm noi înșine. Paginile de stare ale Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun și Brevo: nu se transmite nimic în afară de interogarea propriu-zisă. |
| Sursă | Clientul; interogări către pagina Clientului; directoare publice. |
| Temei juridic | art. 6(1)(b) RGPD. |
| Destinatari | Serviciile menționate nu primesc date cu caracter personal ale Clienților noștri, în măsura în care numele de domeniu și adresele de server ale unei întreprinderi nu sunt date cu caracter personal; în cazul comercianților individuali, numele de domeniu poate constitui date cu caracter personal. Membrii spațiului de lucru văd domeniul. |
| Țară terță | Interogările pot ajunge la servicii din țări terțe (de exemplu interogările registrelor, listele de blocare). Se transmite doar ceea ce este indicat pe rândul „Interogări către terți”. |
| Durată de stocare | Până la ștergerea domeniului. fe_domain_loeschen() șterge apoi imediat rezultatele verificărilor, formularele, constatările, imaginile, rapoartele, sarcinile, destinațiile alertelor și jurnalul alertelor, incidentele, codurile Telegram, livrările, pulsul, vulnerabilitățile și dovezile; prin cheile externe, formularele monitorizate, rulările în browser, contul de test și contoarele de formulare; datele de plugin ale hostului, dacă niciun alt domeniu nu face trimitere la acesta. Se șterg de asemenea inventarul de scripturi și modificările de scripturi ale domeniului; acestea nu au o durată de stocare proprie (secțiunea 6.4). Rezultatele verificărilor cel mult 13 luni, ultimul se păstrează. |
| MTO | Secțiunea 8. Supravegherea fișierelor expuse și a versiunilor doar pentru domeniile verificate, cel mult o interogare pe cale, doar primii 8 KB; sondarea nesolicitată a căilor unor terți ar fi un instrument de atac. |
B.16 Alerte, incidente și escaladare către titularul contului
| Câmp | Mențiune |
|---|
| Scop | Informarea Clientului cu privire la defecțiuni și modificări, respectarea ferestrelor de mentenanță, confirmarea și escaladarea incidentelor. Atunci când destinațiile sunt terți, acționăm în numele Clientului (A.3); atunci când este vorba chiar de titularul contului, prelucrarea este descrisă aici. |
| Categorii de persoane vizate | Titularii conturilor și membrii echipelor, în calitate de destinatari. |
| Categorii de date cu caracter personal | Ca la A.3. Notificările apar în limba titularului contului. |
| Temei juridic | art. 6(1)(b) RGPD. |
| Destinatari | Furnizorul de servicii de e-mail; serviciile de chat alese (4.1). |
| Țară terță | În funcție de canal (4.1). |
| Durată de stocare | Ca la A.3: jurnalul de livrare 90 zile, notificările de tip rezumat 30 de zile după livrare, incidentele până la rezolvare și apoi 180 de zile. Destinațiile alertelor împreună cu domeniul. |
| MTO | Secțiunea 8. |
B.17 Raport lunar către conturi
| Câmp | Mențiune |
|---|
| Scop | În data de 1 a fiecărei luni, începând cu ora 08:00 (recuperare până în data de 3), un e-mail per cont care acoperă toate domeniile acestuia: nivel, scor și evoluție, alerte, boți blocați, trimiterea de e-mailuri, valoare de comparație. |
| Categorii de persoane vizate | Titularii de conturi active cu raportul lunar activat. |
| Categorii de date cu caracter personal | Adresa de e-mail, limba, indicatorii-cheie ai domeniilor. |
| Temei juridic | art. 6(1)(b) RGPD (parte a serviciului). Dezabonarea este posibilă din setări; poate fi dezactivat central. |
| Destinatari | Furnizorul de servicii de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Țară terță | Prin intermediul furnizorului de servicii de e-mail. |
| Durată de stocare | Nicio stocare separată; e-mailul rămâne în coada de trimitere timp de 30 zile (B.25). |
| MTO | Secțiunea 8. |
B.18 Insignă și pagină publică de confirmare
| Câmp | Mențiune |
|---|
| Scop | Un Client poate integra pe site-ul său o imagine-insignă și o poate lega la o pagină publică de confirmare. Insigna afișează „Protejat” doar dacă domeniul este verificat, monitorizarea este în curs, iar ultima verificare finalizată are cel mult 45 de zile și s-a încheiat cu „Protejat” sau „Parțial protejat”; în caz contrar, afișează neutru „Verificare formular de contact”. Pagina de confirmare indică nivelul și data, fără constatări individuale. |
| Categorii de persoane vizate | Vizitatorii site-ului Clientului al căror browser încarcă imaginea; vizitatorii paginii de confirmare. |
| Categorii de date cu caracter personal | La încărcarea imaginii: adresa IP, ora, adresa solicitată, pagina de proveniență și identificatorul browserului în jurnalul serverului web (B.1). Adresa imaginii nu pornește nicio sesiune, nu setează niciun cookie și nu scrie în jurnalul de afișări ale paginilor. Pagina de confirmare este o pagină obișnuită (B.2, B.3). |
| Temei juridic | art. 6(1)(f) RGPD. Interes: livrarea imaginii și menținerea securității funcționării. Dacă, pentru transmiterea adresei IP a vizitatorului, Clientul și noi suntem operatori asociați în sensul jurisprudenței privind conținutul integrat al terților și dacă este necesar un acord în temeiul art. 26 reprezintă o întrebare deschisă pentru analiza juridică. Clientul primește un text propus pentru politica sa de confidențialitate. |
| Destinatari | Niciunul. |
| Țară terță | Niciuna. |
| Durată de stocare | 14 zile (jurnalul serverului web). Imaginea este păstrată în cache timp de o oră. La dezactivarea insignei, identificatorul își pierde valabilitatea. |
| MTO | Secțiunea 8. |
B.19 Jurnal de dovezi și marcă temporală
| Câmp | Mențiune |
|---|
| Scop | Un jurnal pentru fiecare domeniu și lună (planuri plătite): ce s-a verificat, cu ce rezultat, ce s-a raportat și ce s-a modificat, ca dovadă pentru respectarea principiului responsabilității, pentru asigurători sau pentru auditurile furnizorilor. Fiecare versiune primește un număr de verificare; o pagină publică confirmă domeniul, perioada și indicatorii-cheie, fără detalii. Începând cu 7 octombrie 2026, ora este confirmată de o autoritate de marcare temporală conform RFC 3161. |
| Categorii de persoane vizate | Clienții; indirect, persoanele care pot fi menționate în jurnal ca persoane care au aprobat sau au confirmat ceva. |
| Categorii de date cu caracter personal | Domeniul, luna, numărul de verificare, hash-ul conținutului (SHA-512), rezumatul și datele jurnalului, răspunsul de marcare temporală, autoritatea de marcare temporală și ora, încercările eșuate (proof_docs). |
| Temei juridic | art. 6(1)(b) RGPD. |
| Destinatari | Autoritatea de marcare temporală (implicit Certum, ca rezervă DigiCert) primește doar hash-ul jurnalului, nu conținutul acestuia. Public: indicatorii-cheie prin pagina de confirmare. Clientul și oricine căruia Clientul îi transmite jurnalul sau numărul de verificare. |
| Țară terță | Niciun transfer de date cu caracter personal: un hash nu permite nicio deducție privind conținutul. Autoritatea de rezervă are sediul în SUA. |
| Durată de stocare | Până la ștergerea domeniului (fe_domain_loeschen()). Marca temporală nu este o marcă temporală electronică calificată în sensul eIDAS. |
| MTO | Secțiunea 8. |
B.20 Plugin și extensie: verificare, conectare și transmitere
| Câmp | Mențiune |
|---|
| Scop | Pluginul WordPress și extensia TYPO3 pot solicita o verificare (chiar și fără cont), se pot conecta la un cont (instalarea este considerată dovadă a controlului, cu un singur clic în cont), pot debloca funcții de protecție, raportează zilnic cifre (A.9) și raportează imediat erorile de e-mail și modul de mentenanță. |
| Categorii de persoane vizate | Clienții; administratorii de site-uri care utilizează pluginul fără cont. |
| Categorii de date cu caracter personal | Pentru fiecare host: versiunea pluginului și a CMS-ului, numărul de verificări, identificatorul ultimului raport, hash-ul secretului de conectare, primul și ultimul contact (plugin_sites). Coduri de conectare de unică folosință, sub formă de hash, cu dată de expirare (plugin_connect_tokens). Codurile de implementare ale unei agenții, sub formă de hash, cu prefix, etichetă, utilizări, persoana care le-a creat (workspace_connect_codes). Jurnalul de interogări cu adresa IP a serverului apelant (B.4). Cheia pluginului este vizibilă public în secțiunea head a site-ului; este un hash al secretului, iar secretul însuși este stocat doar sub formă de hash și nu este returnat niciodată. |
| Temei juridic | art. 6(1)(b) RGPD (cont); fără cont (f) (verificare solicitată, prevenirea abuzurilor). |
| Destinatari | Niciunul. |
| Țară terță | Niciuna. |
| Durată de stocare | Datele unui host dispar de îndată ce niciun domeniu nu mai face trimitere la acesta; rândul unui plugin fără cont abia după 90 de zile fără contact (rularea nocturnă de ștergere, partea „orphan_hosts”). Codurile de unică folosință la o zi după expirare. Codurile de implementare împreună cu spațiul de lucru. |
| MTO | Secțiunea 8. Începând cu 27 septembrie 2026, serverul acceptă doar perechi de chei legate de site; secretele de conectare mai vechi, nelegate, au fost șterse. |
B.21 Protecție colectivă (swarm)
| Câmp | Mențiune |
|---|
| Scop | Apărare comună împotriva spamului: site-urile conectate raportează domeniile linkurilor din mesajele oprite de stratul lor de protecție. Un domeniu care apare pe cel puțin trei site-uri, cu cel puțin cinci apariții în decurs de șapte zile, este trecut pe o listă care este transmisă înapoi tuturor site-urilor conectate; stratul lor de protecție mută mesajele cu astfel de linkuri în carantină, niciodată în neant. |
| Categorii de persoane vizate | Titularii domeniilor de linkuri raportate, în măsura în care sunt persoane fizice (de exemplu administratorul unui site de spam care funcționează sub propriul nume). Nu expeditorii și destinatarii mesajelor: adresele, textele și numele nu sunt raportate. |
| Categorii de date cu caracter personal | Semnale: tipul, domeniul, hostul care raportează, ziua, aparițiile (swarm_signals). Lista: tipul, domeniul, numărul de site-uri și de apariții, momentele (swarm_list). Serviciile mari, domeniile Clienților noștri și excepțiile stabilite de administratorul site-ului nu sunt niciodată incluse pe listă. |
| Rețele IP | Partajarea rețelelor IP (/24, /48) a fost pregătită. Este dezactivată, iar pluginul nu raportează niciuna; va fi activată doar după o analiză juridică, deoarece adresele IP sunt date cu caracter personal. |
| Temei juridic | art. 6(1)(f) RGPD. Interes: protejarea formularelor tuturor Clienților împotriva valurilor de spam. Echilibrarea intereselor: doar domenii, praguri minime împotriva otrăvirii listei, nicio pierdere de mesaje, eliminare posibilă oricând. |
| Destinatari | Toate site-urile conectate (lista de domenii). |
| Țară terță | În funcție de locația site-urilor conectate; lista poate ajunge și la site-uri din afara SEE. Aceasta constituie date cu caracter personal doar în cazuri-limită (domenii ale persoanelor fizice). Temeiul transferului conform capitolului V din RGPD pentru aceste cazuri urmează să fie stabilit (întrebare deschisă pentru analiza juridică). |
| Durată de stocare | Semnalele 30 de zile (rularea zilnică swarm începând cu ora 04:00, cfg/swarm_lib.php). Lista este recalculată zilnic; ceea ce nu mai atinge pragul este eliminat. |
| MTO | Secțiunea 8. |
B.22 Chei API, interfață de programare și server MCP
| Câmp | Mențiune |
|---|
| Scop | Accesul instrumentelor proprii ale Clientului (REST API, Zapier, Make, server MCP pentru asistenți AI) la domeniile, verificările și incidentele Clientului. |
| Categorii de persoane vizate | Clienții care creează chei. |
| Categorii de date cu caracter personal | Cheia doar sub formă de hash, prefixul, eticheta, momentele creării, ultimei utilizări și revocării (api_keys). Apelurile pe minut (api_usage). |
| Temei juridic | art. 6(1)(b) RGPD. |
| Destinatari | Instrumentul pe care Clientul îl dotează cu cheia; Clientul îl stabilește. |
| Țară terță | În funcție de instrumentul Clientului. |
| Durată de stocare | Cheile până la revocare, iar la ștergerea contului imediat; cheile fără cont (date moștenite) în rularea nocturnă. Contoarele de apeluri după o zi (curățate ocazional la un apel). |
| MTO | Secțiunea 8. |
B.23 reCAPTCHA și protecția proprie a formularelor
| Câmp | Mențiune |
|---|
| Scop | Apărarea împotriva accesului automatizat la propriile noastre formulare: verificarea gratuită, instrumentul pentru antete, opt-out, autentificarea, înregistrarea, parola uitată și resetarea parolei, suportul și contactul. În plus, protecția noastră proprie, fără terți: capcană (câmp ascuns), verificare semnată a timpului și token CSRF. Începând cu 29 octombrie 2026, în plus, protecția noastră a formularelor formconfirmed (dovadă de lucru și token de verificare de unică folosință) la verificarea gratuită, înregistrare, autentificare și „Parolă uitată”. |
| Categorii de persoane vizate | Persoanele care trimit aceste formulare. |
| Categorii de date cu caracter personal | La Google: adresa IP, date despre browser și dispozitiv, date comportamentale, cookie-uri Google. La noi: evaluarea Google (scorul și acțiunea) doar în momentul verificării, fără stocare, nici măcar atunci când o trimitere este respinsă. La protecția proprie a formularelor: adresa IP (stocată doar trunchiată și hash-uită), pagina, momentele de timp, câmp capcană completat da/nu; niciun conținut. |
| Momentul încărcării | Scriptul Google se încarcă doar la trimiterea unui formular protejat, nu la deschiderea paginii. Protecția proprie a formularelor își preia sarcina la deschiderea paginii și efectuează calculul de îndată ce formularul este utilizat. Pe sistemul de dezvoltare, reCAPTCHA este dezactivat. |
| Temei juridic | art. 6(1)(f) RGPD. Interes: protecția împotriva boților, în special pentru verificarea gratuită, care altfel ar putea fi folosită împotriva site-urilor unor terți. Dacă accesul la echipamentul terminal necesită consimțământ în temeiul § 25 TDDDG sau al art. 399 PKE, chiar dacă scriptul se încarcă doar la trimitere, reprezintă o întrebare deschisă pentru analiza juridică. Protecția proprie a formularelor nu setează cookie-uri, nu stochează nimic în browser și nu creează amprente; ea urmează să înlocuiască definitiv reCAPTCHA. |
| Destinatari | Google Ireland Limited; Google LLC. Pentru protecția proprie a formularelor, niciunul. |
| Țară terță | SUA (doar reCAPTCHA). Temei: certificare în cadrul EU-US Data Privacy Framework (Cadrul UE-SUA privind confidențialitatea datelor) sau clauze contractuale standard; urmează să fie documentat în detaliu. |
| Durată de stocare | reCAPTCHA: nicio stocare la noi; la Google, conform propriilor sale reguli. Protecția proprie a formularelor: identificatorul hash-uit 1 oră, tokenurile de verificare utilizate cel mult 11 minute, rezultatele verificării fără adresă IP 30 de zile. |
| Indisponibilitate | Dacă Google nu răspunde în trei secunde sau oferă un răspuns inutilizabil, trimiterea este respinsă; la fel în cazul unui token gol și al unui răspuns pentru o altă acțiune decât cea a formularului. Verificarea este omisă doar atunci când reCAPTCHA este dezactivat. La protecția proprie a formularelor, o trimitere fără token de verificare valid este respinsă; dacă serviciul nu a fost accesibil pentru sarcină, trimiterea este acceptată. |
| MTO | Secțiunea 8. |
B.24 Suport și formular de contact
| Câmp | Mențiune |
|---|
| Scop | Primirea și soluționarea solicitărilor prin fereastra de suport și prin pagina de contact. Ambele folosesc aceeași rută și același tabel. |
| Categorii de persoane vizate | Persoanele care trimit solicitări, autentificate sau nu. |
| Categorii de date cu caracter personal | Contul (dacă persoana este autentificată; se aplică atunci adresa contului, nu cea introdusă), adresa de e-mail, motivul dintr-o listă fixă, textul de până la 4.000 de caractere, starea, adresa IP completă, țara, identificatorul browserului, pagina de proveniență (doar căi proprii), limba, momentele primirii și ale răspunsului (support_requests); înregistrare în jurnalul de activitate (fără text); confirmare de primire către solicitant în coada de trimitere (B.25), cu textul de până la 2.000 de caractere doar pentru expeditorii autentificați, fără text pentru solicitările trimise fără autentificare. |
| Temei juridic | art. 6(1)(b) RGPD atunci când solicitarea privește un contract; în rest (f). Adresa IP completă: (f) (limită de trei solicitări pe oră și adresă, prevenirea abuzurilor). |
| Destinatari | Furnizorul de servicii de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) pentru confirmare și răspuns. Telegram primește un semnal fix, fără nicio variabilă („a sosit o nouă solicitare de suport”), și deci nicio dată cu caracter personal. |
| Țară terță | Prin intermediul furnizorului de servicii de e-mail. |
| Durată de stocare | 24 luni (rularea nocturnă de ștergere, partea „support”); manual, mai devreme. La ștergerea unui cont, solicitările rămân până la sfârșitul duratei de stocare (secțiunea 6.4). |
| MTO | Secțiunea 8. reCAPTCHA, protecția proprie a formularelor, limitarea ratei. |
B.25 Trimiterea e-mailurilor (coada de trimitere)
| Câmp | Mențiune |
|---|
| Scop | E-mailuri tranzacționale: confirmarea înregistrării și a adreselor de e-mail noi, resetarea parolei, invitații, alerte, rapoarte lunare, confirmări și rapoarte ale portalului, confirmări de primire și răspunsuri de suport, mementouri privind perioada de probă și configurarea, notificări operaționale către administratorii serviciului. Fără publicitate, fără e-mailuri către persoane care nu s-au înscris singure sau nu au fost introduse ca destinatari de către Client. |
| Categorii de persoane vizate | Destinatarii acestor e-mailuri. |
| Categorii de date cu caracter personal | Adresa destinatarului, subiectul, conținutul complet, adresa de răspuns, scopul, ruta de trimitere, starea, eroarea, încercările, momentele (mail_outbox). Conținutul poate include linkuri de confirmare și de resetare cu identificatori valabili. |
| Temei juridic | art. 6(1)(b) RGPD; pentru notificările operaționale (f). |
| Destinatari | Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (trimitere); titularul contului își vede e-mailurile trimise în exportul de date (fără conținut). |
| Țară terță | În funcție de locul de prelucrare al furnizorului de servicii de e-mail; contractul și temeiul transferului urmează încă să fie documentate (secțiunea 4). |
| Durată de stocare | 30 zile (nocturn, srv/cron_status.php). Această perioadă este, în mod deliberat, cea mai scurtă dintre jurnale: un jurnal de trimitere de lungă durată ar fi o colecție de chei valabile. Rularea de stare verifică la fiecare cinci minute dacă trebuie efectuată o nouă încercare. |
| Stare | Trimiterea e-mailurilor trebuie configurată înainte de lansare. Până când furnizorul de servicii de e-mail, cu sediul și temeiul său, este stabilit, textele juridice afișează un marcaj. |
| MTO | Secțiunea 8. E-mailurile eșuate sunt retrimise la intervale tot mai mari și abandonate după un număr maxim de încercări. |
B.26 Plăți și facturare
| Câmp | Mențiune |
|---|
| Scop | Încheierea și gestionarea abonamentelor (lunar sau anual, în avans), perioadă de probă de 14 zile fără card, cu un memento cu trei zile înainte de încheiere, plata pe bază de factură pentru abonamentele anuale (dezactivată implicit), deblocări fără plată prin coduri de la furnizori de găzduire și parteneri, facturare, păstrare în scopuri fiscale. |
| Categorii de persoane vizate | Clienții. |
| Categorii de date cu caracter personal | La Stripe: adresa de e-mail, numele, adresa de facturare, codul de TVA, datele de plată, facturile; ca metadate, ID-ul contului din sistemul nostru și planul. La noi: ID-ul de client și ID-ul de abonament Stripe, planul, starea, sfârșitul perioadei, rezilierea la sfârșitul perioadei (users); evenimentele Stripe primite, doar cu identificator, tip, stare și momente, fără conținut (stripe_events); valorificările codurilor de la furnizori de găzduire, cu contul, campania și data expirării (bundle_redemptions). Datele cardurilor nu ajung niciodată la noi. |
| Sursă | Clientul, în pagina de plată Stripe; evenimente de la Stripe. |
| Temei juridic | art. 6(1)(b) RGPD; pentru păstrarea în scopuri fiscale (c). |
| Destinatari | Stripe Payments Europe Limited (Irlanda); Stripe, Inc. (SUA). Pentru anumite părți ale procesării plăților, Stripe acționează pe propria răspundere; repartizarea exactă a rolurilor face parte din analiza juridică. |
| Țară terță | SUA, prin Stripe, Inc.; temei: Data Privacy Framework sau clauze contractuale standard conform condițiilor Stripe. |
| Durată de stocare | Câmpurile de facturare împreună cu contul; un abonament în curs este încheiat înainte de ștergerea contului. Facturile și documentele de facturare, conform legislației fiscale poloneze, timp de cinci ani de la sfârșitul anului în care a expirat termenul de plată a impozitului; acestea sunt păstrate la Stripe și pot fi accesate în portalul pentru clienți Stripe. Evenimentele Stripe și valorificările codurilor nu au o durată de stocare (secțiunea 6.4). |
| MTO | Secțiunea 8. Evenimentele Stripe sunt acceptate doar cu o semnătură validă; fiecare eveniment este procesat o singură dată. |
B.27 Copii de rezervă
| Câmp | Mențiune |
|---|
| Scop | Recuperarea după o eroare: ștergere eronată, migrare deteriorată. |
| Categorii de persoane vizate | Toate persoanele ale căror date se află în baza de date. |
| Categorii de date cu caracter personal | Dump complet, comprimat, al bazei de date a aplicației. Capturile de ecran și fișierele de logo sunt păstrate în afara bazei de date și nu fac parte din această copie de rezervă. Datele de acces ale conturilor de test sunt conținute în ea doar sub formă de text cifrat (A.5). |
| Procedură | În fiecare noapte, la ora 03:00, după rularea de ștergere, astfel încât copia de rezervă să nu preia ceea ce tocmai a fost șters conform duratelor de stocare. Dump-ul este păstrat doar după ce conținutul său a fost verificat (codul de ieșire, numărul de tabele, ultima linie). Duminica, un test de restaurare încarcă cea mai recentă copie de rezervă într-o bază de date temporară și o compară tabel cu tabel. Dacă ceva eșuează, se emite un semnal și se trimite un e-mail administratorilor serviciului. |
| Temei juridic | art. 6(1)(f) RGPD coroborat cu art. 32(1)(c). |
| Destinatari | Niciunul. |
| Țară terță | Niciuna. |
| Durată de stocare | 14 zile; dump-urile mai vechi sunt eliminate doar după o nouă copie de rezervă reușită (cfg/backup_lib.php). Ștergerile efectuate în acest interval ajung în copia de rezervă abia la expirarea acesteia; dacă datele sunt restaurate dintr-o copie de rezervă, cererile de ștergere sunt aplicate din nou ulterior. |
| Locație | Copiile de rezervă sunt în prezent păstrate în aceeași locație ca baza de date și nu sunt criptate separat; este planificată o copie criptată într-o a doua locație (secțiunile 8.1 și 10). |
| MTO | Secțiunea 8. |
B.28 Jurnal de erori și alertă de erori
| Câmp | Mențiune |
|---|
| Scop | Identificarea și remedierea erorilor înainte ca un Client să le raporteze. Tipurile noi de erori și valurile de erori sunt raportate administratorilor serviciului, plus o prezentare generală zilnică începând cu ora 08:00. |
| Categorii de persoane vizate | Utilizatorii a căror solicitare provoacă o eroare; indirect, persoanele ale căror date apar într-un mesaj de eroare. |
| Categorii de date cu caracter personal | Nivelul, sursa, mesajul, contextul ca JSON, ID-ul contului din sesiune, momentul (error_logs). Tipuri de erori: amprenta, modelul (din care au fost eliminate adresele de e-mail, adresele, numerele și identificatorii), un exemplu nemodificat de mesaj de până la 2.000 de caractere, prima și ultima apariție, numărul (error_kinds). |
| Temei juridic | art. 6(1)(f) RGPD (securitatea funcționării, art. 32). |
| Destinatari | Administratorii serviciului, prin e-mail, prin intermediul furnizorului de servicii de e-mail: pentru un tip nou de eroare, sursa și textul brut al mesajului de până la 400 de caractere (necurățat), plus e-mailul cu prezentarea generală zilnică; pentru un val de erori se trimite doar semnalul Telegram. Telegram primește doar propoziții fixe, fără variabile („A apărut un nou tip de eroare”, „Multe erori într-un timp scurt”). |
| Țară terță | Prin intermediul furnizorului de servicii de e-mail. |
| Durată de stocare | Jurnalul de erori 90 zile (nocturn). Tipurile de erori fără durată de stocare (secțiunea 10). Alerta de erori este activată în sistemul de producție și dezactivată în sistemul de dezvoltare. |
| MTO | Secțiunea 8. |
B.29 Semnale operaționale și monitorizarea stării
| Câmp | Mențiune |
|---|
| Scop | Detectarea întreruperilor: la fiecare cinci minute, o verificare a componentelor (pagina principală, baza de date, spațiul pe disc, semnalul de activitate al scannerului, restanța din coadă), pagină de stare, semnal la o defecțiune și la revenirea la normal, semnal de activitate (heartbeat) către un serviciu extern de monitorizare, astfel încât să fie observată chiar și o întrerupere completă; restanța din fața scannerului. |
| Categorii de persoane vizate | De regulă, niciuna. |
| Categorii de date cu caracter personal | Niciuna. Rânduri zilnice pentru fiecare componentă, cu numărul de verificări și ultima eroare (system_status_logs), semnalul de activitate al scannerului (scanner_heartbeat), indicatori-cheie zilnici fără legătură cu persoane (daily_stats). Semnalele către Telegram sunt propoziții fixe, fără variabile; semnalul de activitate este o interogare fără conținut. |
| Temei juridic | Nu se aplică, deoarece nu există date cu caracter personal; ca măsură de precauție, art. 6(1)(f). |
| Destinatari | Telegram (propoziții fixe); serviciul extern de monitorizare (doar interogarea); administratorii serviciului, prin e-mail. |
| Țară terță | Telegram, în afara UE; nu se transmit date cu caracter personal. |
| Durată de stocare | Rândurile de stare 400 de zile (nocturn). |
| MTO | Secțiunea 8. |
B.30 Opt-out – excluderea unui domeniu
| Câmp | Mențiune |
|---|
| Scop | Oricine poate exclude definitiv orice domeniu de la verificări, fără dovadă; blocarea produce efecte imediat pentru toate căile de verificare (verificarea gratuită, pluginul fără cont, studiul, verificarea potențialilor clienți, instrumentul pentru antete) și, de asemenea, pentru domeniile Clienților plătitori cu dovada controlului; monitorizarea lor în curs se încheie la următoarea verificare programată. Se aplică domeniului și variantei sale www, nu și altor subdomenii. Este ridicată doar de noi, la cerere și pe baza unei dovezi. Pentru ca abuzurile (de exemplu, un concurent care blochează domeniile altora) să poată fi detectate și anulate, blocarea este înregistrată. |
| Categorii de persoane vizate | Persoanele care exclud un domeniu. |
| Categorii de date cu caracter personal | Domeniul, motivul opțional de până la 250 de caractere, sursa, adresa IP, țara, identificatorul browserului, momentul; la ridicare, momentul, persoana care ridică blocarea și motivul (blocklist). Jurnalul de interogări ca la B.4. |
| Temei juridic | Pentru excludere, art. 6(1)(f) RGPD. Interes: punerea în aplicare, definitiv și pe toate căile de verificare, a dorinței ca un domeniu să nu fie verificat. Atunci când persoana care exclude domeniul este ea însăși persoană vizată, excluderea pune totodată în aplicare opoziția acesteia în temeiul art. 21 (art. 6(1)(c)). Pentru adresă, țară și identificatorul browserului, (f) (detectarea abuzurilor). |
| Destinatari | Google (reCAPTCHA, B.23). |
| Țară terță | SUA, prin reCAPTCHA. |
| Durată de stocare | Adresa IP, țara și identificatorul browserului după 12 luni (rularea nocturnă de ștergere, partea „optout_ip”). Excluderea în sine rămâne permanent, pentru a-și produce efectele. |
| MTO | Secțiunea 8. Numeroase blocări dintr-o singură țară într-un timp scurt generează o anomalie (B.4). |
B.31 Memento după înregistrare
| Câmp | Mențiune |
|---|
| Scop | Un singur e-mail, la două până la 14 zile după înregistrare, către conturile confirmate fără domeniu confirmat: „Adăugați site-ul” sau „Confirmați domeniul”. Fără ofertă, fără preț, fără upgrade; cu mențiunea că nu va fi trimis din nou. În zilele lucrătoare, între 09:00 și 18:00, cel mult 50 per rulare. |
| Categorii de persoane vizate | Titularii de conturi noi. |
| Categorii de date cu caracter personal | Adresa de e-mail, limba, momentul trimiterii (câmpul „memento trimis” în users), domeniul și starea confirmării. |
| Temei juridic | art. 6(1)(b) RGPD (indicație privind configurarea propriului cont). Dacă e-mailul este considerat o comunicare privind relația contractuală sau o informare comercială care ar necesita consimțământ (art. 10 UŚUDE – ustawa o świadczeniu usług drogą elektroniczną (Legea poloneză privind prestarea serviciilor pe cale electronică); art. 398 PKE; § 7 UWG) reprezintă o întrebare deschisă pentru analiza juridică; administratorul îl poate dezactiva central. |
| Destinatari | Furnizorul de servicii de e-mail (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Țară terță | Prin intermediul furnizorului de servicii de e-mail. |
| Durată de stocare | Momentul trimiterii se păstrează cât timp există contul; e-mailul 30 zile în coada de trimitere. |
| MTO | Secțiunea 8. Momentul este înregistrat înainte de trimitere, astfel încât o întrerupere să nu declanșeze un al doilea e-mail. |
B.32 Bot Telegram pentru alertele Clienților
| Câmp | Mențiune |
|---|
| Scop | Un chat Telegram este conectat ca destinație de alertă: Clientul primește un link către botul nostru cu un cod de unică folosință; când destinatarul apasă „Start”, serverul nostru citește codul din mesajele noi trimise botului și stochează ID-ul chatului. Pentru aceasta nu este necesar niciun endpoint deschis la noi (webhook). |
| Categorii de persoane vizate | Clienții și persoanele al căror chat Telegram este conectat. |
| Categorii de date cu caracter personal | Codul de unică folosință, domeniul, contul care l-a creat, evenimentele, modul de livrare, ID-ul chatului, momentele (telegram_links); ID-ul chatului ca destinație (alerts). Telegram furnizează împreună cu mesajul și alte date de profil; doar codul și ID-ul chatului sunt evaluate și stocate. |
| Temei juridic | art. 6(1)(b) RGPD; pentru terți în calitate de destinatari, A.3. |
| Destinatari | Telegram. |
| Țară terță | În afara UE, fără decizie privind caracterul adecvat; alegerea o face Clientul (4.1). Temeiul și informarea sunt întrebări deschise pentru analiza juridică. |
| Durată de stocare | Un cod este valabil 30 de minute; rândurile de conectare sunt șterse după o zi, la crearea unui cod nou, iar codurile deschise odată cu contul și domeniul. ID-ul chatului ca destinație până la ștergerea destinației de alertă sau a domeniului. |
| MTO | Secțiunea 8. |
B.33 Programul de parteneriat și coduri de deblocare
| Câmp | Mențiune |
|---|
| Scop | Un cont poate recomanda Clienți noi prin intermediul unui cod de recomandare și primește un comision din facturile plătite ale acestora pentru un număr limitat de luni. Codul este transmis în adresă până la înregistrare; nu se setează niciun cookie. Furnizorii de găzduire și partenerii pot emite coduri care deblochează un plan pentru o perioadă, fără plată; cu o săptămână înainte de încheiere, Clientul primește un memento. |
| Stare | Programul de parteneriat este dezactivat implicit până la intrarea în vigoare a Condițiilor pentru parteneri. |
| Categorii de persoane vizate | Partenerii și Clienții recomandați. |
| Categorii de date cu caracter personal | Codul de recomandare, partenerul care a făcut recomandarea și momentul recomandării (în users); comisionul, cu partenerul, Clientul, ID-ul facturii Stripe, suma, moneda, comisionul, starea, momentele (partner_commissions). Deblocarea, cu planul, sfârșitul, sursa, mementoul (în users); campaniile și valorificările (bundle_campaigns, bundle_redemptions). |
| Temei juridic | art. 6(1)(b) RGPD (acordul de parteneriat); pentru Client (f) (decontarea comisionului, fără transmiterea datelor Clientului către partener dincolo de valoarea comisionului); evidențe fiscale (c). |
| Destinatari | Partenerul își vede comisioanele. |
| Țară terță | Niciuna. |
| Durată de stocare | Recomandarea și deblocarea împreună cu contul. Comisioanele și valorificările nu au o durată de stocare în cod; în calitate de documente contabile, comisioanele fac obiectul păstrării în scopuri fiscale (secțiunea 6.4). |
| MTO | Secțiunea 8. |
B.34 Punct de raportare a vulnerabilităților
| Câmp | Mențiune |
|---|
| Scop | Primirea rapoartelor privind vulnerabilitățile din formexposed, conform regulilor de pe pagina Securitate și din /.well-known/security.txt. |
| Categorii de persoane vizate | Persoanele care raportează; persoanele ale căror date sunt conținute într-un raport ca dovadă. |
| Categorii de date cu caracter personal | Adresa de e-mail, numele, conținutul raportului și atașamentele, așa cum le trimite persoana care raportează. Raportul ajunge la noi prin e-mail, la adresa indicată acolo; aplicația nu îl stochează. |
| Temei juridic | art. 6(1)(f) RGPD (securitatea serviciului, art. 32); atunci când un raport conține ca dovadă date cu caracter personal ale unor terți, de asemenea (f), în scopul remedierii vulnerabilității. |
| Destinatari | Furnizorul de servicii de e-mail și, până la configurarea căsuței poștale, redirecționarea domeniului la Namecheap (secțiunea 4). |
| Țară terță | Prin intermediul furnizorului de servicii de e-mail și, până la trecerea la căsuța poștală, prin redirecționare. |
| Durată de stocare | Nu a fost stabilită și nu este aplicată tehnic nicio durată de stocare (secțiunea 10). Administratorul trebuie încă să stabilească perioada; o abordare evidentă ar fi ștergerea dovezilor privind terți odată cu remedierea vulnerabilității și tratarea corespondenței la fel ca solicitările de suport. |
| MTO | Secțiunea 8. |
B.35 Feedback privind un raport
| Câmp | Mențiune |
|---|
| Scop | Primirea feedbackului de sub un raport („Este ceva greșit în acest raport?”) pentru a identifica erori în detectarea formularelor. Superadministratorul îl clasifică (nou, confirmat, remediat, respins) și poate descărca datele de verificare ale raportului ca un caz de test (formulare cu câmpuri, motive și constatări, fără capturi de ecran și fără textele trimise activ). |
| Categorii de persoane vizate | Persoanele care vizualizează un raport, autentificate sau nu. |
| Categorii de date cu caracter personal | Categoria și verificarea din liste fixe, adresa paginii de până la 500 de caractere, textul de până la 1.000 de caractere, limba, momentul, identificatorul raportului, verificarea, hostul; identificatorul contului, dacă persoana este autentificată; HMAC-SHA256 al adresei IP cu o cheie secretă pentru limită; starea, persoana care l-a tratat, momentul tratării (report_feedback). Jurnalul de activitate: modificările de stare și descărcările unui caz de test. Nicio adresă de e-mail, nicio adresă IP în text clar. |
| Temei juridic | art. 6(1)(f) RGPD (identificarea și remedierea erorilor de detectare; limită împotriva abuzurilor). |
| Destinatari | Niciunul. |
| Țară terță | Niciuna. |
| Durată de stocare | 24 luni (rularea nocturnă de ștergere, partea „report_feedback”); suma de control a adresei IP este ștearsă după 2 zile (partea „report_feedback_ip”); imediat la ștergerea unui cont. Cazurile de test descărcate nu conțin date despre persoana care a raportat. |
| MTO | Secțiunea 8. Protecția proprie a formularelor (capcană, timp semnat, CSRF), cel mult 5 rapoarte pe oră și 20 pe zi per sumă de control, 10 per raport; poate fi citit doar de superadministratori. |
6. Stocare – ce acoperă rularea nocturnă de ștergere și ce nu
Există o ștergere automată și aceasta are un loc precis. O rulare de stare (srv/cron_status.php) este pornită la fiecare cinci minute prin crontab-ul serverului web, atât pe sistemul de producție, cât și pe sistemul de dezvoltare. Aceasta verifică componentele, preia e-mailul de verificare a livrării, programează verificările și trimite alertele. O dată pe zi, în intervalul 03:00–03:04, șterge datele conform duratelor de stocare și apoi creează copia de rezervă. Începând cu 27 septembrie 2026, apelează în plus rularea pentru durate de stocare din cfg/fristen_lib.php (fe_fristen_lauf()), ale cărei părți rulează independent una de alta: dacă una eșuează, celelalte continuă, iar eroarea este înregistrată în jurnalul de erori.
Dovada că rularea funcționează: starea copiilor de rezervă ale sistemului de dezvoltare indică o copie de rezervă reușită la ora 03:00, pe 11 octombrie 2026; copia de rezervă este creată în același bloc, imediat după ștergere. Rularea scrie un jurnal pentru fiecare tabel șters doar în ieșirea standard, pe care crontab-ul o elimină; nu există o evidență permanentă a ceea ce a fost șters și când (secțiunea 10).
Duratele de stocare care apar ca substituenți sunt stabilite în zona de administrare, în setările privind duratele de stocare. Rularea citește aceleași setări; prin urmare, textele indică întotdeauna perioada după care datele sunt efectiv șterse.
6.1 Acoperite de rularea zilnică
| Date | Durată de stocare și declanșator | Locul în cod |
|---|
Jurnalul de afișări ale paginilor (access_logs) | 60 zile | srv/cron_status.php |
Jurnalul de activitate (audit_logs) | 365 zile | srv/cron_status.php |
Jurnalul de erori (error_logs) | 90 zile | srv/cron_status.php |
Coada de trimitere (mail_outbox) | 30 zile | srv/cron_status.php |
Tokenurile de memorare „Păstrează-mă autentificat” (remember_tokens) | după expirare (30 de zile) | srv/cron_status.php |
Invitațiile neacceptate (workspace_invites) | după expirare (14 zile) | srv/cron_status.php |
Încercările de autentificare (login_attempts); contoarele de încercări (auth_attempt_buckets) | 7 zile; contoarele la expirarea intervalului lor de timp (în prezent 15 minute, o oră pentru resetarea parolei și înregistrare), de asemenea la următorul acces | srv/cron_status.php |
Jurnalul de interogări pentru verificările fără cont (check_throttle) | 7 zile | srv/cron_status.php |
Codurile de unică folosință pentru conectarea pluginului (plugin_connect_tokens) | la 1 zi după expirare | srv/cron_status.php |
Anomaliile soluționate (abuse_flags) | 90 de zile după soluționare | srv/cron_status.php |
| Rapoartele expirate, împreună cu rezultatul verificării, formularele, constatările, imaginile și sarcina (doar fără un domeniu într-un cont) | anonime 30 zile, potențiali clienți 90 de zile | fe_reports_aufraeumen() |
Jurnalul de livrare a alertelor (alert_log) | 90 zile | fe_alert_log_aufraeumen() |
Rândurile de stare (system_status_logs) | 400 de zile | srv/cron_status.php |
Evidențele consimțămintelor conturilor șterse (legal_consents) | după ștergerea contului și după ce consimțământul are o vechime de 4 ani | srv/cron_status.php |
| Date orfane ale domeniilor șterse: rezultatele verificărilor, sarcinile, datele alertelor, incidentele, codurile Telegram, livrările, pulsul, vulnerabilitățile, dovezile, inventarul de scripturi și modificările de scripturi | imediat, la următoarea rulare | fe_fristen_lauf(), părțile „orphan_scans”, „orphan_rows” |
| Datele de plugin ale hosturilor fără domeniu; rândul pluginului fără cont | imediat; rândul după 90 de zile fără contact | partea „orphan_hosts” |
Rezultatele instrumentului pentru antete (header_checks) | în prezent 90 de zile | partea „header_checks” |
| Rezultatele verificărilor pentru un domeniu, cu formulare, constatări, imagini, rapoarte, sarcini | 13 luni; ultima verificare finalizată per domeniu se păstrează | partea „old_scans” |
Rulările în browser, sarcinile de browser finalizate, seriile temporale (form_browser_runs, scan_jobs, form_performance) | 13 luni | părțile „browser_runs”, „browser_jobs”, „form_performance” |
Contoarele de formulare (form_metrics), cifrele zilnice ale pluginului și notificările de modificare (plugin_stats, plugin_changes) | 13 luni | părțile „form_metrics”, „plugin_stats” |
Dispozitivele autentificate (login_sessions) | 90 de zile după ultima utilizare sau revocare | partea „sessions” |
| Invitațiile acceptate | 30 de zile după acceptare | partea „invites” |
Solicitările de suport (support_requests) | 24 luni | partea „support” |
Feedbackul privind rapoartele (report_feedback) | 24 luni; suma de control a adresei IP 2 zile | părțile „report_feedback” și „report_feedback_ip” |
Versiunile PDF ale rapoartelor din cache (var/pdf) | 7 zile | partea „pdf_cache” |
Adresa IP, țara și identificatorul browserului în opt-out (blocklist) | 12 luni; excluderea se păstrează | partea „optout_ip” |
Abonații portalului (client_subscribers) | neconfirmați 30 de zile; dezabonați 3 ani | partea „subscribers” |
| Conturile niciodată confirmate, împreună cu spațiul de lucru | 30 de zile fără autentificare, cu excepția cazului în care este asociat un alt membru | partea „pending_accounts” |
| Cheile API fără cont (date moștenite) | imediat | partea „api_keys” |
6.2 În afara intervalului de la ora 03:00
| Date | Durată de stocare și declanșator | Locul în cod |
|---|
| Copiile din căsuța poștală de control a verificării livrării | după procesare, la fiecare cinci minute | fe_zustellung_abholen() |
Asocierile verificării livrării (delivery_log) | 180 de zile, la fiecare preluare | fe_zustellung_abholen() |
Textul cifrat al contului de test în sarcini (scan_jobs) | după rulare, cel târziu după o oră | serverul de scanare; fe_login_aufraeumen() |
Incidentele (alert_incidents), cu încercările lor de livrare pentru escaladare | cât timp nu sunt soluționate; 180 de zile după soluționare | fe_vorfaelle_aufraeumen() în cfg/vorfall_lib.php |
Notificările de tip rezumat trimise (alert_queue) | 30 de zile după livrare | cfg/kanal_lib.php |
Semnalele swarm (swarm_signals) | 30 de zile, zilnic începând cu ora 04:00 | cfg/swarm_lib.php |
Verificările potențialilor clienți (prospect_checks) | 90 de zile, zilnic începând cu ora 04:00 | srv/cron_status.php |
Codurile de conectare Telegram (telegram_links) | 1 zi, la crearea unui cod nou | cfg/kanal_lib.php |
Contoarele de apeluri API (api_usage) | 1 zi, ocazional la un apel | cfg/agentur_lib.php |
Întreruperile soluționate ale furnizorilor (provider_incidents), cache-ul de vulnerabilități (vuln_cache) | 90, respectiv 30 de zile; fără date cu caracter personal | cfg/anbieter_lib.php, cfg/luecken_lib.php |
| Datele brute ale studiilor | la publicare | fe_studie_veroeffentlichen() |
| Copiile de rezervă | 14 zile, după o nouă copie de rezervă reușită | cfg/backup_lib.php |
| Jurnalele serverului web | 14 zile | rotația jurnalelor de sistem |
6.3 La ștergerea de către Client
- Ștergerea unui domeniu (
fe_domain_loeschen()): rezultatele verificărilor cu formulare, constatări și fișiere de imagine, rapoartele, sarcinile, destinațiile alertelor, jurnalul de livrare, coada de rezumate, incidentele, codurile Telegram, livrările, pulsul, vulnerabilitățile, jurnalele de dovezi, domeniul din portalurile pentru clienți cu selecție fixă; prin cheile externe, formularele monitorizate cu rulările în browser, observațiile și seriile temporale, contul de test, contoarele de formulare; datele de plugin ale hostului, dacă niciun alt domeniu nu face trimitere la acesta. Inventarul de scripturi și modificările de scripturi ale domeniului sunt șterse de asemenea odată cu acesta; ele nu au o durată de stocare proprie (secțiunile 6.4 și 10). Datele rămase fără domeniu asociat din perioada anterioară datei de 27 septembrie 2026 sunt eliminate de rularea nocturnă (părțile „orphan_scans”, „orphan_rows”).
- Ștergerea unui spațiu de lucru (
fe_arbeitsbereich_daten_loeschen()): în plus, marca, inclusiv logoul, portalurile pentru clienți, inclusiv abonații, codurile de implementare, verificările potențialilor clienți; plus invitațiile și calitățile de membru.
- Ștergerea unui cont: încheierea imediată la Stripe a unui abonament plătit în curs, fără rambursare; transferarea sau ștergerea spațiilor de lucru proprii ale titularului; ștergerea calităților de membru, a tokenurilor de memorare, a dispozitivelor, a cheilor API cu contoarele aferente, a codurilor Telegram deschise și a rândului contului.
- Ștergerea unui cont de test (
fe_login_loeschen()): suprascrierea textului cifrat, ștergerea rândului, eliminarea sarcinilor în așteptare.
6.4 Ce nu acoperă rularea
Această listă este cea mai importantă. Ea indică datele pentru care nu există o durată de stocare automată sau care supraviețuiesc unei ștergeri.
| Date | Ce se aplică | Evaluare |
|---|
Datele contului, inclusiv ultima adresă IP (users) | până la ștergerea de către titularul contului; conturile inactive nu sunt șterse | date contractuale; lipsește o regulă pentru conturile inactive permanent, fără abonament |
| Jurnalul de activitate, afișările de pagini, jurnalul de erori al unui cont șters | rămân, cu ID-ul contului și adresa IP, până la sfârșitul duratei lor de stocare | intenționat (dovada acțiunilor chiar și după încetare); ID-ul nu mai indică un cont |
| Solicitările de suport ale unui cont șters | rămân până la 24 luni, cu vechiul ID al contului | intenționat; ID-ul nu este eliminat |
| Evidențele consimțămintelor unui cont șters | până când consimțământul are o vechime de 4 ani (calculată de la consimțământ, nu de la ștergerea contului) | intenționat (secțiunea B.12) |
Anomaliile nesoluționate, cu adresa IP (abuse_flags) | până când cineva le soluționează | punct deschis (secțiunea 10) |
Tipurile de erori cu exemplu de mesaj nemodificat (error_kinds) | nicio durată de stocare | punct deschis (secțiunea 10) |
Inventarul de scripturi și modificările de scripturi (script_inventory, script_changes) | nicio durată de stocare proprie; păstrate cât timp există domeniul și șterse odată cu acesta | punct deschis (secțiunea 10) |
| Abonații portalurilor pentru clienți revocate | până la ștergerea spațiului de lucru | punct deschis (secțiunea 10) |
| Cheile API și codurile de implementare revocate | până la ștergerea contului sau a spațiului de lucru | doar hash-uri, prefix și etichetă; minor |
Lista hosturilor din studii (study_domains), studiile niciodată publicate | nicio durată de stocare | punct deschis (secțiunea 10) |
| Verificările interne fără domeniu și fără raport (rezultatele verificărilor, formulare, constatări, capturi de ecran) | nicio durată de stocare; nu sunt acoperite de nicio cale de ștergere | punct deschis (secțiunea 10) |
| Comisioanele, valorificările codurilor, evenimentele Stripe | nicio durată de stocare | relevanță contabilă; perioada urmează să fie stabilită conform legislației fiscale |
Vechimea domeniului din cache (domain_age_cache) | nicio durată de stocare | doar numele de domeniu și data înregistrării |
| Rezultatul autentificării e-mailului formularului, cu domeniul expeditorului | împreună cu domeniul; suprascris la fiecare primire | a se vedea A.1 |
| Excluderile din opt-out | permanent | intenționat; fără caracter permanent, nicio excludere nu produce efecte |
| E-mailurile din căsuța poștală a punctului de raportare și din căsuța poștală generală | nicio durată de stocare tehnică | punct deschis (secțiunea 10) |
6.5 În afara bazei de date
- Capturile de ecran sunt păstrate ca fișiere în afara directorului web și sunt șterse odată cu rezultatul verificării lor (toate căile de ștergere de mai sus șterg și fișierele).
- Fișierele de logo ale mărcii sunt șterse la înlocuire și odată cu spațiul de lucru.
- Pe serverul de scanare, pentru fiecare sarcină este creat un director temporar cu rezultatul și imaginile; acesta este șters după fiecare rulare, chiar și după o eroare.
- Copiile de rezervă sunt păstrate pe serverul web (B.27).
- Jurnalele serverului web cu adresa IP completă sunt păstrate 14 zile (B.1).
7. Decizii automatizate, creare de profiluri și evaluare
formexposed evaluează site-uri web, nu persoane. În evaluarea noastră, serviciul nu ia nicio decizie care produce efecte juridice care privesc o persoană sau care o afectează în mod similar într-o măsură semnificativă (art. 22(1) RGPD). Există însă evaluări automatizate și blocări automate. Le enumerăm pentru ca încadrarea să poată fi verificată.
| Mecanism | Ce face | Pe cine afectează |
|---|
| Scorul și verdictul unei verificări | Suma ponderată a straturilor de protecție lipsă (CAPTCHA, capcană, token, verificarea timpului, CAPTCHA ineficient, configurație expusă cunoscută), de la 0 la 100; din aceasta rezultă „Expus”, „Parțial protejat” sau „Protejat”. Verdictul site-ului urmează cel mai slab formular de contact recunoscut ca atare de reguli (nu de modelul lingvistic); fără formular de contact nu există verdict. Ponderile pot fi stabilite în zona de administrare. | Administratorii site-urilor; în cazul comercianților individuali, indirect o persoană. Verdictul nu are consecințe juridice; este o constatare însoțită de dovezi și instrucțiuni. |
| Clasificarea tipului de formular | Mai întâi regulile, un model lingvistic local doar dacă regulile returnează „necunoscut”. Decide dacă este permisă o trimitere activă de test (doar pentru un formular de contact recunoscut în mod fiabil de reguli). Formularele clasificate de modelul lingvistic nu sunt niciodată trimise și nu contează pentru scor și verdict. | Clientul și destinatarii e-mailurilor din formularul său; efect protector: în caz de îndoială, nu se trimite nimic. |
| Insigna | Afișează „Protejat” doar în condiții fixe (B.18), în rest este neutră. | Clientul; niciun efect asupra vizitatorilor. |
| Limite și blocări pentru verificarea gratuită, instrumentul pentru antete și opt-out | Resping solicitările dacă sunt atinse limitele per adresă, sesiune, domeniu sau sistem, dacă domeniul este prea nou sau are o vechime necunoscută ori dacă se află pe lista de blocare. | Solicitanții; efect: un serviciu gratuit este refuzat timp de câteva ore până la câteva zile. Un administrator poate debloca o adresă; solicitările trimise prin pagina de contact ajung la un om. |
| Anomalii | Tiparele (multe domenii de la o singură adresă, rafale de solicitări, multe respingeri, multe opt-out-uri dintr-o singură țară, limita zilnică atinsă) sunt înregistrate și raportate. Ele nu blochează prin ele însele; blocările rezultă din limite. | Solicitanții. |
| Blocarea autentificării | După, în prezent, opt autentificări eșuate de la o singură adresă în decurs de 15 minute, autentificările de la acea adresă sunt respinse temporar. În plus, toate încercările de autentificare, inclusiv cele reușite, sunt contorizate per cont și adresă IP (în prezent opt), per cont pentru toate adresele (considerabil mai multe, împotriva ghicirii distribuite) și per adresă IP (în prezent 80) în decurs de 15 minute, la fel și codurile pentru al doilea factor (zece per cont în decurs de 15 minute); peste aceste valori, încercările sunt respinse. Astfel, încercările eșuate de la o altă adresă nu mai blochează accesul titularului la cont. Confirmările parolei (cinci per cont în decurs de 15 minute), e-mailurile de resetare (trei per adresă pe oră, cu un răspuns neschimbat), înregistrările (zece per adresă IP pe oră) și încercările de introducere a parolei unui portal pentru clienți (zece per portal și adresă IP, 50 per portal în decurs de 15 minute) sunt limitate în același mod. | Persoanele care se autentifică, se înregistrează sau deschid un portal pentru clienți; efect limitat în timp, resetarea parolei rămâne posibilă. |
| Pragul reCAPTCHA | Respinge trimiterile sub un anumit scor Google; prag per punct de utilizare (în prezent 0,7 pentru verificare și opt-out). Sunt respinse și răspunsurile pentru o altă acțiune, precum și trimiterile pentru care Google nu răspunde în trei secunde. | Persoanele care trimit formularele noastre; efect: o nouă încercare sau calea prin pagina de contact. |
| Protecție colectivă (swarm) | Trece automat un domeniu de link pe o listă atunci când sunt atinse pragurile minime; straturile de protecție ale site-urilor conectate mută mesajele cu astfel de linkuri în carantină. | Expeditorii de mesaje către paginile Clienților. Efect: mesajul este reținut, nu șters, și poate fi eliberat de administratorul site-ului. Decizia privind mesajul este luată de pluginul administratorului, pe site-ul acestuia, nu de noi. |
| Valori de comparație | „Mai bine protejat decât X % dintre site-urile verificate”, doar pe baza totalurilor de cel puțin 20 de hosturi. | Administratorii site-urilor; niciun efect. |
Cel mai apropiat caz de art. 22 este stratul de protecție al pluginului de pe paginile Clienților, care reține automat trimiterile. Este vorba de o prelucrare efectuată de administratorul site-ului pe serverul acestuia (A.10). Acesta nu șterge nimic, ci mută mesajele în carantină, iar administratorul poate elibera orice mesaj. Nu are loc nicio creare de profiluri ale vizitatorilor, nici acolo, nici la noi; nu există un identificator al vizitatorului care să lege un mesaj de altul.
8. Măsuri tehnice și organizatorice (art. 32) – descriere generală
Această secțiune reprezintă descrierea generală în temeiul art. 30(1)(g) și (2)(d) RGPD. Versiunea detaliată se află pe pagina Măsuri tehnice și organizatorice. Fiecare măsură de mai jos este documentată în cod sau în configurație. Măsurile care nu au fost încă implementate se află în aceeași secțiune (8.1), astfel încât descrierea să fie completă.
| Domeniu | Măsură în vigoare |
|---|
| Criptarea transportului | HTTPS pentru site, aplicație și interfețe; HSTS; cookie-urile de sesiune și de memorare doar prin HTTPS, HttpOnly, SameSite=Lax. |
| Controlul accesului (autentificare) | Parolele doar sub formă de hash, cele noi cu cel puțin zece caractere și cel mult 72 de octeți; blocarea autentificării după încercări eșuate repetate și limite de încercări per cont și adresă IP împreună, per cont și per adresă IP, astfel încât încercările eșuate de la o altă adresă să nu blocheze accesul titularului; limite de încercări și pentru confirmările parolei, resetarea parolei (cu același răspuns și același timp de răspuns), înregistrări și parolele portalurilor; autentificare cu doi factori (TOTP) cu secret criptat, protecție împotriva reutilizării codurilor și coduri de recuperare stocate ca hash; identificator de sesiune nou la fiecare autentificare, identificatorii care nu au fost emiși de server nu sunt acceptați; „Păstrează-mă autentificat” nu este disponibil pentru superadministratori, fiecare token este valabil o singură dată; modificarea adresei de e-mail invalidează un link de resetare deschis; dispozitivele pot fi revocate individual sau toate deodată; lista de dispozitive conține doar hash-ul identificatorului de sesiune. |
| Controlul accesului (autorizare) | Roluri per spațiu de lucru (proprietar, administrator, cititor); permisiunile sunt verificate în raport cu obiectul, niciodată în raport cu un identificator din formular; contul de test, „Fix it for me” și verificările active doar pentru proprietari și administratori; „Vizualizare ca Client” limitată în timp și blocată pentru acțiunile care modifică contul, încheierea acesteia deconectează complet, revenirea în zona de administrare doar cu parolă și al doilea factor; invitațiile sunt valabile doar cât timp persoana care invită este proprietar sau administrator; adresele webhookurilor și ale canalelor de chat sunt afișate cititorilor doar scurtate la host; numele de host al unui domeniu verificat nu poate fi modificat. |
| Securitatea aplicației | Tokenuri CSRF; instrucțiuni de bază de date pregătite (prepared statements); protecția proprie a formularelor (capcană, verificare semnată a timpului); reCAPTCHA pe formularele publice; limitarea ratei pentru suport, verificări și interfețe; un singur apel „Fix it for me” per spațiu de lucru la un moment dat, astfel încât cota să fie respectată și în cazul solicitărilor simultane; Content Security Policy cu protecție împotriva încadrării, care permite rularea doar a scripturilor care poartă autorizarea (nonce) a răspunsului respectiv; adresa IP din antetele redirecționate doar de la propriul nostru proxy și doar din intrarea adăugată de acesta; tokenurile de acces mascate în jurnalul de afișări ale paginilor. |
| Secrete | Cheile API, codurile de implementare, secretele de conectare ale pluginului, codurile de unică folosință și parolele portalurilor doar sub formă de hash; datele de acces ale conturilor de test criptate asimetric, cheia privată doar pe serverul de scanare; webhookuri semnate; evenimentele Stripe doar cu o semnătură validă. |
| Reducerea la minimum a datelor | Verificarea livrării nu stochează conținut și nici adrese complete ale expeditorilor; adresele destinatarilor din formulare doar ca domeniu; ID-urile de cont din adresele scripturilor sunt înlocuite; cifrele pluginului doar din liste fixe; textele erorilor de trimitere a e-mailurilor doar ca o categorie; semnalele Telegram fără variabile; imaginile verificării în browser cu datele introduse mascate; nicio captură de ecran în spatele unei autentificări. |
| Izolarea scannerului | Fiecare verificare în propriul container: toate capabilitățile Linux eliminate, nicio escaladare a privilegiilor, sistem de fișiere doar în citire, limită de memorie și de procese, rețea proprie; verificarea țintei în raport cu rețelele private și locale înainte de acceptare și în scanner, inclusiv după redirecționări; service workerii blocați, conexiunile WebSocket închise. Interogările efectuate de serverul web (dovada controlului, instrumentul pentru antete, căutarea de fișiere, pulsul, RDAP, certificatele, webhookurile și alertele de chat) doar pe porturile web uzuale și doar către exact adresa verificată, webhookurile și alertele de chat doar prin HTTPS. |
| Stocare | Capturile de ecran în afara directorului web, accesibile doar prin raport; rapoartele la adrese aleatorii, cu noindex; directorul copiilor de rezervă poate fi citit doar de serviciu. |
| Disponibilitate și recuperare | Copie de rezervă nocturnă cu verificarea conținutului, test de restaurare săptămânal, alertă în caz de eșec; verificarea componentelor la fiecare cinci minute, cu semnal și e-mail; semnal de activitate extern; oprire de urgență pentru verificările anonime; contrapresiune atunci când există o restanță. |
| Trasabilitate | Jurnal de activitate pentru autentificări, modificări, ștergeri, accese de suport și aprobări; jurnal de erori cu alertă. |
| Ștergere | Duratele de stocare într-un singur loc în cod, pe baza acelorași setări ca textele (secțiunea 6); lanțuri de ștergere pentru domeniu, spațiu de lucru și cont, cu excepțiile din secțiunea 6.4. |
| Drepturile persoanelor vizate | Exportul cu un singur clic al tuturor datelor contului ca fișier, pe baza unei liste permise de câmpuri, fără secrete. |
| Organizare | Zona de administrare doar pentru conturile cu drepturi de superadministrator, blocată pe durata „Vizualizare ca Client”; sistemele de dezvoltare și de producție separate, sistemul de dezvoltare în spatele unei bariere de acces suplimentare; transferul textelor juridice după aprobare, printr-un instrument care refuză ciornele și substituenții. |
8.1 Măsuri încă neimplementate
- Nicio criptare a bazei de date în repaus (măsurat la 11 octombrie 2026). Excepție fac datele de acces ale conturilor de test și secretul pentru al doilea factor, care sunt criptate la nivel de câmp.
- Conexiunile interne nu sunt criptate în totalitate. Conexiunile din rețeaua noastră internă nu sunt criptate în totalitate. Datele de acces ale conturilor de test circulă acolo doar sub formă de text cifrat.
- Nicio copie de rezervă într-o a doua locație. Copiile de rezervă sunt în prezent păstrate în aceeași locație ca baza de date și nu sunt criptate separat; este planificată o copie criptată într-o a doua locație. Până atunci, ele protejează împotriva unei comenzi de ștergere greșite, nu împotriva pierderii locației.
- Consolidarea securității administrării serverelor nu este finalizată. Securitatea accesului administrativ la serverele noastre nu atinge încă standardul pe care îl urmărim pentru funcționare; consolidarea continuă. Nu publicăm detalii, deoarece acestea ar ajuta un atacator; le punem la dispoziția unei autorități de supraveghere, la cerere.
- Niciun jurnal funcțional al accesărilor în citire în zona de administrare. Acțiunile de scriere sunt înregistrate în jurnalul de activitate; cine a vizualizat doar o anumită solicitare de suport sau un anumit raport poate fi stabilit doar din jurnalul de afișări ale paginilor (60 zile).
- Niciun jurnal permanent al ștergerilor. Ceea ce a șters rularea nocturnă nu este înregistrat (secțiunea 6).
- Niciun al doilea punct de verificare independent. Sonda dintr-o a doua locație nu este configurată (A.6).
9. Responsabilul cu protecția datelor – evaluare în temeiul art. 37 RGPD
Rezultat: În evaluarea noastră, nu există obligația de a desemna un responsabil. Evaluarea face parte din analiza juridică și va fi repetată de îndată ce se modifică oricare dintre circumstanțele enumerate mai jos.
art. 37(1) impune desemnarea în trei cazuri.
- Litera (a) (autoritate sau organism public) nu se aplică.
- Litera (b) (activități principale care necesită o monitorizare periodică și sistematică a persoanelor vizate pe scară largă): activitatea noastră principală este verificarea periodică și sistematică a site-urilor și a formularelor, nu observarea persoanelor. Nu creăm profiluri ale vizitatorilor, nu folosim urmărire și nu legăm niciun mesaj de altul. Verificarea livrării (A.1) trece mesaje reale ale vizitatorilor prin căsuța noastră poștală, dar evaluează doar antetele și primii 8 KB pentru asociere și nu stochează conținut; ea observă rutele de livrare, nu persoane. Conturile Clienților și jurnalele sunt accesorii activității comerciale.
- Litera (c) (prelucrarea pe scară largă a categoriilor speciale prevăzute la art. 9 sau a datelor referitoare la infracțiuni prevăzute la art. 10, ca activitate principală): nu este îndeplinită. Categoriile speciale pot apărea incidental în copiile e-mailurilor din formulare (A.1), pe paginile din spatele unei autentificări (A.5) sau în codul lipit (A.7); colectarea incidentală nu reprezintă o activitate principală.
art. 37(4) permite dreptului național să adauge alte cazuri. Solicităm unui avocat să confirme dacă legislația poloneză ne obligă să desemnăm un responsabil.
Factori declanșatori pentru o nouă evaluare: activarea protecției colective (swarm) cu rețele IP; o funcție care recunoaște vizitatorii în mai multe mesaje sau pe mai multe site-uri; stocarea conținutului din verificarea livrării; un Client ale cărui formulare privesc în principal categorii speciale (sănătate, candidaturi pentru locuri de muncă), cu verificarea livrării activată pe scară largă; primul angajat cu acces la datele clienților. O desemnare voluntară rămâne posibilă; în acest caz, art. 37–39 se aplică integral.
Separat: dacă pentru anumite activități de prelucrare este necesară o evaluare a impactului asupra protecției datelor în temeiul art. 35 este analizat pe pagina Evaluarea impactului asupra protecției datelor. Evaluarea pragului de acolo concluzionează că o EIPD este necesară pentru protecția colectivă (B.21) și pentru studiile la scara avută în vedere (B.7) și este efectuată de noi, iar pentru verificarea livrării (A.1) este necesară în configurația tipică, ca obligație a Clientului, pe care îl sprijinim în acest sens.
10. Puncte deschise și măsuri planificate
Punctele următoare sunt documentate în cod, în schemă sau în configurație, nu presupuse. Ele descriu situația la data acestei versiuni; încadrarea ne aparține și nu anticipează nicio evaluare juridică. Sunt ordonate în funcție de importanța lor pentru persoanele vizate, nu în funcție de cât de ușor pot fi remediate. Măsurile planificate și prioritatea lor sunt prezentate în Evaluarea impactului asupra protecției datelor.
| Punct deschis | Ce este documentat | Semnificație |
|---|
| Furnizor de servicii de e-mail fără contract documentat | Pentru Namecheap, Inc. (Private Email), Phoenix, Arizona, USA, contractul, locurile de prelucrare și temeiul transferului nu sunt documentate. E-mailurile contului, alertele și căsuța poștală de control cu mesaje reale ale vizitatorilor trec prin acest furnizor. | Dispozițiile relevante sunt art. 28(2) și (4) și capitolul V din RGPD. Încheierea și documentarea sunt planificate înainte de lansare. |
| Temeiurile pentru serviciile de chat și reCAPTCHA sunt deschise | Alerte către Telegram (fără decizie privind caracterul adecvat), Slack, Discord, Microsoft Teams și Google Chat; reCAPTCHA fără solicitarea consimțământului. | Întrebări deschise pentru analiza juridică; până atunci, informarea și temeiul nu sunt definitive. |
| Căsuța poștală de control poate reține mesaje în timpul perturbărilor | Ștergerea are loc după procesarea reușită; dacă preluarea eșuează, copiile rămân până la următoarea rulare reușită. Nu există niciun avertisment atunci când se acumulează o restanță în căsuța poștală pe o perioadă mai lungă. | Copiile conțin solicitări reale ale vizitatorilor. |
| Nicio copie de rezervă într-o a doua locație, nicio criptare a bazei de date în repaus | Secțiunea 8.1. Este planificată o copie criptată a copiei de rezervă într-o a doua locație. | Un singur eveniment în locație ar afecta simultan datele și copia de rezervă; un suport de stocare furat ar putea fi citit. |
| Anomalii nesoluționate fără durată de stocare | Anomaliile cu adresa IP completă drept cheie sunt șterse doar la 90 de zile după soluționare; ceea ce nu este niciodată soluționat rămâne. | Privește principiul limitărilor legate de stocare (art. 5(1)(e)); ștergerea depinde de soluționarea manuală. Este planificată o durată de stocare fixă (măsuri ale Evaluării impactului asupra protecției datelor). |
| Tipuri de erori cu exemplu de mesaj fără durată de stocare | Exemplul de mesaj este stocat nemodificat, până la 2.000 de caractere; modelul curățat elimină adresele și numerele, exemplul nu. | Mesajele de eroare pot conține adrese de e-mail, nume de host sau adrese IP. |
| Inventarul de scripturi fără durată de stocare proprie | Inventarul de scripturi și modificările de scripturi sunt șterse odată cu domeniul (FE_DOMAIN_TABELLEN), inclusiv la ștergerea spațiului de lucru sau a contului și în rularea nocturnă pentru datele orfane; ele nu au o durată de stocare proprie. Conțin adrese de scripturi, adrese de pagini și, pentru aprobări, persoana care aprobă și un motiv sub formă de text liber. | Privește principiul limitărilor legate de stocare (art. 5(1)(e)); jurnalul modificărilor cu aprobările continuă să crească cât timp există domeniul. |
| Abonații portalurilor revocate | Un portal revocat este blocat, nu șters; abonații săi rămân până la ștergerea spațiului de lucru. | Scopul (trimiterea raportului) a încetat odată cu revocarea. |
| Liste ale studiilor fără durată de stocare | După publicare, hosturile și segmentele rămân; studiile niciodată publicate își păstrează și datele brute. | Promisiunea „datele brute sunt șterse” se aplică doar studiilor publicate. |
| Verificări interne fără cale de ștergere | Verificările cu nivelul de încredere „intern” care nu au nici domeniu, nici raport (studiile și verificările create de administrator din linia de comandă) nu sunt acoperite de nicio cale de ștergere; odată cu ele rămân formularele, constatările și capturile de ecran ale unor site-uri terțe. | Privește principiul limitărilor legate de stocare (art. 5(1)(e)); afectează persoane care nu știu nimic despre verificare. Evaluat ca risc ridicat în Evaluarea impactului asupra protecției datelor. |
| Dovada controlului nu este reînnoită | Dovada controlului este verificată o singură dată; nu există în cod nicio cale prin care un domeniu să o piardă din nou. | Trimiterile active de test, căutarea de fișiere și scanarea din spatele autentificării continuă după o schimbare a proprietarului sau a mandatului. |
| Scanarea din spatele autentificării: transportul către pagina Clientului | Ca adresă de autentificare este permis http alături de https, iar erorile de certificat de pe pagina Clientului nu opresc autentificarea. | Datele de acces ale contului de test ar putea fi interceptate pe drumul către pagina Clientului. |
| Ștergerea depinde de un interval de timp | Blocul zilnic rulează doar dacă o rulare de stare pornește între 03:00 și 03:04. Dacă această unică rulare eșuează (baza de date inaccesibilă, server repornit), ștergerea și copia de rezervă din acea zi nu au loc; nu există recuperare. Ceea ce a fost șters nu este înregistrat permanent. | Duratele de stocare se prelungesc atunci, fără nicio semnalare, cu o zi. Un interval ratat nu declanșează nicio alertă; este raportată doar o copie de rezervă care rulează și eșuează. Lista de configurare din zona de administrare indică data ultimei copii de rezervă reușite. |
| Unele ștergeri depind de monitorizare | Golirea căsuței poștale de control a verificării livrării, ștergerea incidentelor, a notificărilor de tip rezumat trimise, a semnalelor swarm și a verificărilor potențialilor clienți, precum și eliminarea copiilor rămase ale conturilor de test din sarcini rulează în partea de planificare a rulării de stare, care funcționează doar cât timp monitorizarea este activată în zona de administrare; asocierile verificării livrării sunt șterse doar cât timp este configurată o căsuță poștală de control. | Dacă monitorizarea este dezactivată central sau căsuța poștală este eliminată, aceste durate de stocare încetează să se aplice fără ca cineva să observe. |
| Punctul de raportare și căsuțele poștale fără durată de stocare | Rapoartele privind vulnerabilitățile și alte e-mailuri primite sunt păstrate în afara aplicației; nu a fost stabilită nicio durată de stocare. | Rapoartele pot conține dovezi privind terți. |
| Valorile câmpurilor ascunse sunt citite în timpul verificării | Scannerul citește valoarea câmpurilor ascunse ale formularelor de până la 24 de caractere și atributele de date de până la 60 de caractere pentru a recunoaște marcajele de timp și tokenurile. În harta câmpurilor și în constatări ajung doar numele câmpului, tipul, eticheta și rezultatul recunoașterii, nu și valoarea. | Nicio lacună de stocare; valoarea este păstrată doar în memoria de lucru a containerului de scanare pe durata verificării. O valoare precompletată (de exemplu un număr de client) este citită în acest proces, dar nu este stocată. |
| Domeniul expeditorului derivat din rezultatul autentificării | A.1. | În cazul domeniilor personale ale vizitatorilor, date cu caracter personal provenite dintr-un mesaj real. |
| Consolidarea securității administrării serverelor nu este finalizată; conexiunile interne nu sunt criptate în totalitate | Secțiunea 8.1. Consolidarea continuă; nu publicăm detalii. | Un incident de securitate la nivel de server ar afecta simultan aplicația, baza de date și copiile de rezervă. |
| Măsurare pe sistemul de dezvoltare | Schema, codul și setările au fost măsurate pe sistemul de dezvoltare. | Codul și schema corespund sistemului de producție; setările pot diferi și trebuie verificate din nou acolo înainte de lansare. |
11. Actualizarea acestei evidențe
art. 30 impune ca evidența să fie păstrată în scris și pusă la dispoziția autorității de supraveghere, la cerere. Pentru aceasta este nevoie de o persoană responsabilă și de un interval la care evidența este verificată în raport cu sistemul, nu în raport cu versiunea sa anterioară.
- Responsabilitate: Lukas Wójcik, proprietar. Evidența este revizuită anual și ori de câte ori se modifică o activitate de prelucrare.
- Evenimente care impun o actualizare: o persoană împuternicită secundară nouă sau modificată, în special alegerea furnizorului de servicii de e-mail; un tabel nou sau un câmp nou cu date cu caracter personal; o modificare a duratelor de stocare sau a lanțurilor de ștergere din
cfg/fristen_lib.php sau srv/cron_status.php; un canal de alertă nou sau o interogare nouă către un terț; activarea unei funcții dezactivate implicit (protecția colectivă cu rețele IP, sonda, domeniile proprii, programul de parteneriat, plata pe bază de factură, Spamhaus sau Google Web Risk); mutarea pe alte servere.
- Procedură: fiecare afirmație de aici provine din cod, din schemă sau din măsurători. O revizuire care doar citește textul nu a revizuit nimic: schema și lanțurile de ștergere sunt măsurate din nou, substituenții rămân substituenți, punctele deschise sunt închise sau reportate cu motivare.
- Relația cu alte documente: această evidență nu înlocuiește Politica de confidențialitate, Acordul de prelucrare a datelor, Măsurile tehnice și organizatorice sau lista Persoanelor împuternicite secundare. Acolo unde acestea diferă de prezenta evidență, diferența reprezintă o constatare.
- Modificările aduse acestui document sunt enumerate pe pagina Modificări ale documentelor contractuale.
English 
Deutsch 
Polski 
Български 
Čeština 
Dansk 
Ελληνικά 
Español 
Eesti 
Suomi 
Français 
Gaeilge 
Hrvatski 
Magyar 
Italiano 
Lietuvių 
Latviešu 
Malti 
Nederlands 
Português 
Română 
Slovenčina 
Slovenščina 
Svenska 
العربية 
हिन्दी 
Bahasa Indonesia 
日本語 
한국어 
Русский 
简体中文 
Norsk (bokmål) 
Português (Brasil) 
Türkçe 
Українська 
Español (México) 
Tiếng Việt 
ไทย 
Íslenska 
עברית 
Bahasa Melayu 
Srpski (latinica)