Datu atklāšana: izsekojiet ierakstam visā tā dzīves ciklā

Lietotņu inventārs pasaka, kādi rīki pastāv. Datu inventāram jāizskaidro arī tas, ko šie rīki satur, kāpēc, kas tam var piekļūt un kur ceļo kopijas. Inženieru komandai tas nozīmē skatīties tālāk par datubāzu shēmām uz darbības ceļiem, kas rada, pārveido, izpauž, glabā un dzēš informāciju.

Sāciet, izsekojot vienam reprezentatīvam ierakstam. Klienta kontaktinformācija var ienākt caur veidlapu, parādīties CRM, kļūt par atbalsta pieteikumu, nonākt analītikas plūsmā un beigās eksportētā izklājlapā. Tās dzīves ciklā var būt arī žurnāli, dokumenti, rezerves kopijas un piegādātāja sistēmas. Katrs atzarojums maina to, kas jums jāaizsargā un ko jūs varat ticami apgalvot par apstrādi.

Noderīgais rezultāts nav skenera ziņojums. Tā ir uzturēta datu, apstrādes darbību, tehnisko atkarību un atbildīgo īpašnieku karte, ko pamato pierādījumi par to, kā darbplūsma faktiski darbojas.

Ko atklāšana atbalsta saskaņā ar VDAR

VDAR nenosaka konkrētu atklāšanas produktu vai skenēšanas metodi. Atklāšana atbalsta informāciju un pierādījumus, kas nepieciešami VDAR pienākumu izpildei:

Šiem pienākumiem ir nosacījumi un izņēmumi. Dzēšana nav beznosacījuma, un ne katrs personas datu aizsardzības pārkāpums prasa paziņošanu uzraudzības iestādei. Pārziņiem bez nepamatotas kavēšanās un, ja iespējams, 72 stundu laikā pēc tam, kad tiem kļuvis zināms par pārkāpumu, jāpaziņo kompetentajai uzraudzības iestādei, ja vien nav maz ticams, ka pārkāpums radīs risku personu tiesībām un brīvībām. Apstrādātāji bez nepamatotas kavēšanās paziņo pārzinim.

Ja piemērojams 30. pants, sasaistiet atklāšanu ar nepieciešamo apstrādes darbību reģistru. Aktīvu inventārs nav šis reģistrs: viena darbība var aptvert vairākas lietotnes, savukārt viena lietotne var atbalstīt vairākus mērķus. Pārziņa un apstrādātāja reģistriem ir arī atšķirīgs obligātais saturs.

Nosakiet robežu, neslēpjot tās malas

Izvēlieties pirmo biznesa darbplūsmu, nevis mēģiniet aptvert visas sistēmas vienlaikus. Klientu reģistrācija, personāla atlase vai atbalsts var būt pārvaldāms sākumpunkts. Definējiet ierosinātāju, beigu stāvokli, iesaistītās komandas, sistēmas un piegādātājus.

Pēc tam saskaņojiet apstiprināto lietotņu sarakstu ar darbības pierādījumiem. Noderīgi ievaddati ir identitātes pakalpojumu sniedzēja ieraksti, mākoņa inventāri, iepirkumu un izdevumu ieraksti, integrāciju konfigurācijas un intervijas ar cilvēkiem, kas veic darbu. Katram avotam ir ierobežojumi: vienotā pierakstīšanās neatklās katru personīgo kontu, un iepirkumu reģistrs neatklās izklājlapu, kas nosūtīta konsultantam.

Apzināti meklējiet vietas, kas atrodas ārpus galvenās lietotņu arhitektūras:

• Brīva teksta laukus, augšupielādētus pielikumus, e-pasta arhīvus un tērzēšanas sarunas.
• Kopīgas mapes, lejupielādes galiekārtās, plānotus eksportus un pagaidu migrācijas failus.
• Datu noliktavas, produkta analītiku, žurnālus un uzraudzības platformas.
• Ražošanas datu kopijas izstrādes, testēšanas un problēmu novēršanas vidēs.
• Transkripcijas pakalpojumus un MI rīkus, kas saņem uzvednes, dokumentus vai ierakstus.
• Rezerves kopijas, replikas, arhivētus kontus un ekspluatācijā vairs neizmantotus pakalpojumus.

Neapstiprināti rīki ir viens no atklāšanas rezultātiem, nevis visa tēma. Arī apstiprinātās sistēmās var būt negaidīti dati. Skaidri dokumentējiet izņēmumus, ieskaitot nepieejamas piegādātāju vides un repozitorijus, kas gaida autorizāciju. „Nav pārbaudīts” nedrīkst klusi kļūt par „nesatur personas datus”.

Izsekojiet ierakstam un dokumentējiet katru nodošanu

Izmantojiet reālistisku ieraksta veidu, vēlams sintētisku piemēru, lai kopā ar procesa izpildītājiem izietu tam cauri. Lūdziet viņiem parādīt ikdienas soļus, izņēmumus un apiešanas risinājumus. Darbplūsmas diagramma apraksta paredzēto uzvedību; demonstrācija bieži atklāj papildu kopijas.

Katram posmam nosakiet, kas ienāk, kas mainās, kas iziet un kas paliek. Fiksējiet pietiekamu detalizāciju, lai atbildētu uz šiem jautājumiem:

Dokumentējiet ne tikai galamērķus, bet arī nosūtīšanas mehānismus: API, tīmekļa āķis (webhook), manuāls CSV, koplietošanas saite vai e-pasta pielikums rada atšķirīgas kontroles un pierādījumu vajadzības. Atzīmējiet, vai saņēmēja sistēma pārveido identifikatorus, apkopo ierakstus vai rada jaunu atvasinātu informāciju.

Izmantojiet stabilus darbību un sistēmu identifikatorus, lai komandas varētu atjaunināt saistības, nepārbūvējot karti. Uzturiet inventāru aprakstošu: tam jāidentificē kategorijas un noteikumi, nevis jākļūst par vēl vienu nevajadzīgu personas ierakstu krātuvi.

Validējiet tehniskos konstatējumus, pirms uz tiem paļaujaties

Skenēšanas un klasifikācijas rīki var identificēt iespējamus personas vai sensitīvus datus atbalstītajos repozitorijos. Uzskatiet šos konstatējumus par norādēm. Lauks ar nosaukumu customer_email sniedz noderīgu mājienu; tas nenosaka katru mērķi, saņēmēju vai glabāšanas noteikumu.

Validācijā jāapvieno tehniska pārbaude ar īpašnieka apstiprinājumu. Pārbaudiet reprezentatīvus laukus, konfigurāciju, piekļuves politikas un integrāciju uzvedību. Kur piemēroti, izmantojiet metadatus vai rediģētus paraugus, nevis eksportējiet veselas datu kopas.

Nošķiriet tiešos identifikatorus no informācijas, kas paliek personas dati konteksta vai sasaistes dēļ. Klienta ID, pseidonimizēta notikumu plūsma vai ierīces identifikators joprojām var attiekties uz identificējamu personu. Tikai vārdu noņemšana nenodrošina anonimizāciju. Savukārt skaitļa atbilstība šablonam nepierāda, ka lauks satur personas identifikatoru.

Līdztekus konstatējumiem uzturiet pārklājuma ierakstu:

• Iekļautos repozitorijus un vides, pārbaudes datumus un izmantotās atļaujas.
• Atklāšanas metodes, klasifikatora noteikumus un izlases pieeju.
• Šifrētu saturu, neatbalstītus formātus, nepieejamas krātuves un citus ierobežojumus.
• Apstiprinātos konstatējumus, neatrisinātos rezultātus un par validāciju atbildīgo pārskatītāju.

Ierobežojiet piekļuvi sensitīviem konstatējumiem un nevāciet nevajadzīgus personas datus tikai tāpēc, lai pierādītu to esamību. Atklāšanas piekļuves datiem jābūt tikai nepieciešamajām atļaujām. Ja nepieciešama paaugstināta piekļuve, autorizējiet to, ierobežojiet tās ilgumu un saglabājiet atbilstošus piekļuves pierādījumus.

Pārvērtiet atrašanās vietas apstrādes lēmumos

Tehniskā atklāšana identificē, kur informācija atrodas. Tā nevar noteikt, vai mērķis ir pamatots, kurš 6. panta tiesiskais pamats ir piemērojams vai vai saskaņā ar 35. pantu ir nepieciešams novērtējums par ietekmi uz datu aizsardzību.

Grupējiet konstatējumus biznesa darbībās kopā ar attiecīgajiem procesu īpašniekiem un privātuma pārskatītājiem. E-pasta adresei, ko izmanto konta administrēšanai, un tai pašai adresei, ko izmanto mārketingam, var būt nepieciešams atšķirīgs pamatojums, glabāšanas noteikumi un paziņojuma saturs. Dokumentējiet lēmumus, nevis piešķiriet vienu tiesisko pamatu visai lietotnei.

Novērtējiet attiecības ar piegādātājiem atsevišķi no ģeogrāfijas. 28. panta apstrādātāja līgums un V nodaļas starptautiskās nosūtīšanas novērtējums atbild uz dažādiem jautājumiem. ES mitināšanas reģions vien neatrisina jautājumus par attālināto piekļuvi, apakšapstrādātājiem vai tālāku nosūtīšanu. Fiksējiet saņēmēju un piekļuves kārtību, pirms lemjat, kuri līgumiskie un nosūtīšanas pasākumi ir attiecināmi.

Ja mērķi, īpašumtiesības vai juridiskais pamatojums paliek neskaidri, izveidojiet pārskatīšanas uzdevumu. Neslēpiet nenoteiktību aiz apstiprināta inventāra ieraksta.

Piemērs: klienta kontaktinformācija atbalsta procesā

Šis piemērs ir ilustratīvs. Pieņemsim, ka SaaS pakalpojumu sniedzējs vāc uzņēmuma kontaktinformāciju caur reģistrācijas veidlapu, izmanto CRM un atbalsta platformu, veic produkta analītiku un uztur atjaunojamas rezerves kopijas. Atbalsta komanda arī gatavo iknedēļas eksportus darba slodzes analīzei.

Atklāšanas komanda izseko sintētiskai kontaktpersonai cauri reģistrācijai un atbalsta pieprasījumam. Tā salīdzina integrāciju iestatījumus ar faktiskajiem darbības soļiem un atrod šādus atzarojumus:

Konstatējums par kopīgo mapi maina novēršanas plānu. Kontaktpersonas dzēšana no CRM neatrisinātu šo eksportu. Atbalsta īpašniekam jāidentificē esošie faili, jānoskaidro, kas tos saņēma, un jāievieš atbilstoša tīrīšana un eksporta izmaiņas.

Konstatējumam par rezerves kopijām nepieciešama cita apstrāde. Komanda dokumentē glabāšanas grafiku un rezerves kopiju datu ierobežoto izmantošanu, pēc tam pārbauda atjaunošanas darbplūsmu, lai veca atjaunošana klusi neatjaunotu ierakstus, kuriem jāpaliek dzēstiem. Jebkuram glabāšanas izņēmumam nepieciešams pamatojums; tehniska neērtība vien nav vispārējs atbrīvojums.

Rezultāti ir validēta dzīves cikla karte, attiecīgos gadījumos atjaunināti darbību ieraksti, identificēti pierādījumu trūkumi un piešķirti novēršanas uzdevumi. Otrs sintētiskais tests pārbauda, vai mainītā darbplūsma darbojas, kā paredzēts.

Padariet karti noderīgu reālā darbā

Izmantojiet atklāšanas rezultātus, lai prioritizētu pārmērīgu piekļuvi, nekonsekventu glabāšanu, trūkstošus piegādātāju pārskatus un neprecīzus paziņojumus. Piešķiriet katram konstatējumam īpašnieku, smagumu vai prioritāti, termiņu un pieņemšanas pierādījumus. „Samazināt piekļuvi” ir nepilnīgi; „noņemt plašo atbalsta grupu no eksporta mapes un pārbaudīt faktiskās atļaujas” ir izpildāmi.

Datu subjekta piekļuves pieprasījuma gadījumā karte identificē iespējamās sistēmas, identifikatorus, saņēmējus un meklēšanas īpašniekus. Tā neaizstāj pašu meklēšanu vai trešo personu tiesību izvērtēšanu. Atbildes parasti jāsniedz viena mēneša laikā, ievērojot VDAR termiņa pagarināšanas nosacījumus. Darbības darbplūsmai turpiniet ar datu subjektu piekļuves pieprasījumu apstrādi.

Pārkāpuma gadījumā karte palīdz reaģētājiem atrast skartās krātuves un pakārtotās kopijas. Apstipriniet iedarbību, izmantojot incidenta pierādījumus; inventārs nepierāda, kam uzbrucējs piekļuva. Dokumentējiet nenoteiktības un pamatojumu paziņošanas vai nepaziņošanas lēmumiem.

Paturiet atklāšanu izmaiņu pārvaldības ietvaros

Praktisks ieteikums ir apvienot periodisku saskaņošanu ar notikumu ierosinātiem atjauninājumiem. Ierosiniet pārskatīšanu, kad komandas ievieš funkciju, piegādātāju, integrāciju, eksportu, jaunu datu kategoriju vai glabāšanas izmaiņas. Ekspluatācijas izbeigšanai jāierosina pārbaudes attiecībā uz atlikušajiem kontiem, arhīviem un kopijām.

Ieceliet procesa īpašnieku un tehniskās kontaktpersonas un uzturiet validācijas datumus redzamus. Pārskatīšanas biežumam jāatspoguļo izmaiņu temps un risks, nevis jāpieņem, ka katram repozitorijam nepieciešami identiski skenēšanas intervāli. Salīdziniet deklarēto arhitektūru ar darbības pierādījumiem, lai pamanītu nedokumentētas izmaiņas.

Secani var saglabāt pārskatīšanas kontekstu: modelējiet attiecīgās sistēmas un pakalpojumu sniedzējus kā mērķobjektus, savienojiet pierādījumus ar prasībām un lēmumiem un pārvērtiet trūkumus uzdevumos ar īpašniekiem. Uzturiet apstiprinājumus un atsauces uz avotiem piesaistītas darbam un pārskatiet jebkurus MI ģenerētus ieteikumus, pirms uz tiem paļaujaties. Atklāšanas rīki nosaka tehniskos konstatējumus; atbilstības darbvieta saglabā to nozīmi un tiem sekojošos lēmumus.

Sāciet šonedēļ ar vienu reprezentatīvu ierakstu. Izejiet ar to cauri faktiskajai darbplūsmai, dokumentējiet katru nodošanu un kopiju un piešķiriet pirmo neatrisināto atzarojumu kādam, kas to var validēt.