Pereiti prie turinio
Legiscope
Meniu
Duomenų apsauga

PDAV šablonas: užpildytas pavyzdys ir sprendimo forma

PDAV darbo lapas su hipotetine rizikos analize. Praktinė rengimo eiga, sprendimų pavyzdžiai ir patikros klausimai.

PDAV šablonas padeda aprašyti numatomą duomenų tvarkymą, patikrinti jo būtinumą ir priimti sprendimą dėl poveikio žmonėms. Formos užpildymas nėra savaiminis leidimas pradėti projektą. Vertinimas turi pakeisti sprendimą, jeigu nustatoma, kad pasirinktas būdas neproporcingas arba rizika lieka didelė.

Pirmiausia patikrinkite PDAV atlikimo sąlygas ir Lietuvoje taikomo VDAI sąrašo atranką. Toliau pateiktas pavyzdys yra hipotetinis: organizacija svarsto darbuotojų prašymų prioritetų sistemą, kuri pagal pateiktus požymius automatiškai siūlytų aptarnavimo eilę.

Pirmoji dalis: tvarkymo aprašymas

Klausimas Pildymo pavyzdys
Koks tikslas? Greičiau paskirstyti darbuotojų pagalbos prašymus pagal skubumą
Kokie žmonės? Organizacijos darbuotojai, pateikiantys pagalbos užklausas
Kokie duomenys? Darbo kontaktai, prašymo tema, pageidaujama data; laisvas tekstas gali atskleisti papildomų duomenų
Kokios sistemos? Prašymų portalas, užduočių sistema ir ribotas ataskaitų rinkinys
Kas priima sprendimą? Koordinatorius, galintis pakeisti sistemos siūlomą prioritetą
Kokios alternatyvos? Rankinis priskyrimas, mažesnis požymių rinkinys, taisyklės be profiliavimo

Pavyzdyje sąmoningai neįrašomas tariamai teisingas teisinis pagrindas. Jį turi nustatyti organizacija pagal konkretų tikslą, savo pareigas ir faktinį sprendimo poveikį. Teisinio pagrindo matrica padeda nepaslėpti šio sprendimo po bendru teiginiu „vidaus administravimas“.

Antroji dalis: būtinybė ir proporcingumas

Kiekvienam laukui paaiškinkite, kokį sprendimą jis leidžia priimti. Jeigu skubumui nustatyti pakanka kategorijos, nereikia reikalauti diagnozės laisvame tekste. Patikrinkite, ar darbuotojas gali pateikti prašymą kitu būdu ir ar pasirinktas modelis nepagrįstai blogina tam tikrų grupių padėtį.

Aprašykite informavimą, duomenų tikslinimą, prieigos apribojimą ir saugojimą. Vertinime turi būti ne pažadas „teisės užtikrinamos“, o konkretus kanalas ir procedūros savininkas. Duomenų kiekio mažinimo auditas leidžia dokumentuoti, kokių laukų atsisakyta projektavimo metu.

Trečioji dalis: rizikos žmonėms

Scenarijus Galima pasekmė asmeniui Pradinio vertinimo pagrindas Priemonė
Laisvame tekste pateikiami jautrūs duomenys Pernelyg plati prieiga prie privačios informacijos Lauką mato daug koordinatorių Riboti matomumą, pateikti aiškias įvedimo instrukcijas
Netikslus požymis lemia žemą prioritetą Vėluoja reikalinga pagalba Automatinis pasiūlymas retai peržiūrimas Žmogaus patikra ir galimybė taisyti duomenis
Ataskaitos panaudojamos darbo našumui vertinti Netikėtas stebėjimas ir nepalankios išvados Eksportas leidžia susieti individualią istoriją Atskirti tikslus, riboti eksportą ir ataskaitas

Riziką vertinkite pagal galimos žalos rimtumą ir tikimybę, nurodydami argumentus. Skaitinis balas be paaiškinimo nėra stiprus įrodymas. Priemonės turi būti įgyvendinamos prieš sprendimo priėmimą, o jų poveikis vertinamas pakartotinai.

BDAR 35 ir 36 straipsniai nustato pagrindinius PDAV ir išankstinės konsultacijos reikalavimus. EDAV PDAV gairės padeda vertinti didelio pavojaus požymius. VDAI atrankos sąrašas tikrinamas papildomai.

Ketvirtoji dalis: priemonių įrodymas

Prie kiekvienos priemonės pridėkite vykdytoją, įgyvendinimo datą ir patikros būdą. Prieigos ribojimui tinka vaidmenų bandymas; trynimui – kontrolinio įrašo pašalinimo patikra; žmogaus peržiūrai – scenarijus, kuriame koordinatorius pakeičia klaidingą siūlymą. Vien tiekėjo aprašymas neįrodo, kad priemonė įjungta jūsų aplinkoje.

Jei priemonė sumažina tik vieną rizikos aspektą, tai aiškiai pažymėkite. Šifravimas padeda dėl neteisėto atskleidimo, bet neištaiso klaidingo prioriteto ar perteklinio lauko. Automatizuotų sprendimų patikra padeda įvertinti, ar papildomai aktualus BDAR 22 straipsnis.

Penktoji dalis: sprendimas ir peržiūra

Sprendimo formoje įrašykite projekto versiją, atliktus pakeitimus, likusią riziką, DAP nuomonę, konsultacijų rezultatą ir sprendimą priimantį valdytojo atstovą. Jei nuo DAP nuomonės nukrypstama, išsaugokite argumentus. DAP konsultuoja ir stebi, tačiau valdytojo atsakomybė už projektą jam neperkeliama.

Kai vertinimas rodo didelį pavojų, kurio numatytomis priemonėmis nepavyksta sumažinti, taikomos išankstinės konsultacijos sąlygos. Projekto savininko noras laikytis paleidimo datos nėra rizikos mažinimo priemonė. Peržiūros įvykiais laikykite naujus duomenis, kitą algoritmą, platesnę žmonių grupę ir paskirties pokytį.

Kaip atskirti organizacijos riziką nuo rizikos žmogui

PDAV centre yra žmonių teisės ir laisvės. Organizacijos finansinis nuostolis ar projekto vėlavimas gali būti svarbus bendram rizikų valdymui, bet jis nepakeičia vertinimo, ką patirs darbuotojas, klientas ar pacientas. Pavyzdžiui, klaidingas prioritetas gali lemti negautą pagalbą, neteisingą vertinimą ar diskriminaciją. Šias pasekmes reikia aprašyti tiesiogiai.

Tame pačiame scenarijuje gali būti keli poveikio keliai. Neteisinga darbuotojo žyma gali būti matoma kolegoms, perduodama vadovui ir panaudojama kitam sprendimui. Vertinant vien pirminio prašymo aptarnavimą būtų praleistas vėlesnis poveikis. Todėl tikrinkite ne tik rinkimą, bet ir peržiūrą, ataskaitas, eksportus, saugojimą ir duomenų panaudojimą pasibaigus pradinei užduočiai.

Vertinimo skalė su paaiškinimu

Galite naudoti kelis aiškiai apibrėžtus tikimybės ir rimtumo lygius. Aprašykite, kuo jie skiriasi jūsų situacijoje: ar pasekmė lengvai ištaisoma, ar gali ilgai paveikti žmogaus galimybes; ar scenarijui būtinos išskirtinės sąlygos, ar jis įmanomas įprastomis prieigos teisėmis. Skaičiai turi padėti palyginti scenarijus, o ne apsimesti tiksliu žalos matavimu.

Prie pradinio ir likusio vertinimo pateikite argumentus bei įrodymą. Jei teigiate, kad tikimybę sumažina vaidmenų atskyrimas, parodykite, kurios teisės panaikintos ir kas tai patikrino. Jei priemonė dar suplanuota, jos negalima traktuoti kaip jau veikiančios. Atskirai pažymėkite nepatikrintas prielaidas ir jų savininkus.

Nenaudokite vien bendro vidutinio balo, kuris paslėptų vieną labai rimtą scenarijų. Kiekviena didelį poveikį galinti turėti rizika turi turėti atskirą sprendimą. Žmonių grupės taip pat gali skirtis: ta pati klaida gali būti gerokai reikšmingesnė pažeidžiamam asmeniui arba žmogui, neturinčiam realaus alternatyvaus kanalo.

Hipotetinio projekto pakeitimas po vertinimo

Grįžkime prie darbuotojų pagalbos prašymų sistemos. Projekto komanda iš pradžių norėjo reikalauti išsamaus paaiškinimo ir automatiškai teikti vadovams individualias mėnesio ataskaitas. Vertinimas parodė, kad laisvas tekstas dažnai atskleistų sveikatos ar šeimos aplinkybes, o individuali ataskaita nebūtina pagalbos paskirstymui.

Komanda pakeičia formą: pateikia ribotas užklausų kategorijas, leidžia papildomą informaciją siųsti tik reikiamam specialistui ir parengia bendrą statistinę ataskaitą be nereikalingos individualios istorijos. Koordinatorius mato siūlomą prioritetą, jo paaiškinimą ir gali jį pakeisti. Darbuotojui pateikiamas kanalas pranešti apie klaidą ir gauti žmogaus peržiūrą.

PDAV užfiksuojama, kokie pradiniai sprendimai atmesti ir kodėl. Tai naudinga vėliau, kai kitas vadovas pasiūlo vėl įjungti individualias ataskaitas. Ankstesnis vertinimas leidžia suprasti, kad tai reikšmingas paskirties bei poveikio pokytis, kuriam reikia pakartotinės analizės, o ne paprastas techninio nustatymo pakeitimas.

DAP, naudotojų ir kitų specialistų dalyvavimas

Jeigu organizacijoje paskirtas DAP, kreipkitės į jį tinkamu projekto etapu ir išsaugokite jo konsultacijos turinį. Pateikite realų veikimo aprašą, duomenų srautus ir rizikos prielaidas. Prašymas paskutinę dieną „patvirtinti BDAR“ neleidžia prasmingai įvertinti alternatyvų ar pasiūlyti projektavimo pakeitimų.

Pagal aplinkybes įtraukite žmonių ar jų atstovų nuomonę, kaip numato BDAR 35 straipsnio 9 dalis. Tai gali padėti pastebėti sunkiai suprantamą formą, nesąžiningą prielaidą ar nerealią alternatyvą. Dokumentuokite, kaip nuomonė surinkta ir į ką atsižvelgta, saugodami konsultuojamų žmonių duomenis. Jei nuomonės neprašoma, užrašykite konkrečią priežastį.

IT specialistas patvirtina techninių priemonių veikimą, proceso savininkas – būtinybę, o atitinkami teisės specialistai padeda vertinti specialias normas. Vieno dalyvio parašas neturėtų slėpti nepatikrintų kitų sričių klausimų. Sprendimo formoje aiškiai nurodykite, kokią dalį kiekvienas asmuo peržiūrėjo.

Paleidimo sąlygos ir vėlesnė kontrolė

Prie galutinio sprendimo pridėkite sąlygų sąrašą: kokios priemonės turi veikti prieš pradžią, kokie stebėjimai bus atliekami ir koks pokytis sustabdytų naudojimą. Pavyzdžiui, reikšmingas klaidingų prioritetų skaičius gali inicijuoti peržiūrą. Rodiklio pasirinkimą ir ribą pagrįskite projektu, neperimdami atsitiktinio skaičiaus kaip teisinio standarto.

Paleidus sistemą palyginkite numatytą ir faktinį naudojimą. Ar darbuotojai nepateikia kitokių duomenų, negu tikėjotės? Ar koordinatoriai iš tikrųjų peržiūri automatinius siūlymus? Ar atsirado naujas eksportas? Toks grįžtamasis patikrinimas padeda nustatyti, kada pradinis PDAV nebeatitinka realybės ir turi būti atnaujintas.

Versijos, priedai ir prieiga prie vertinimo

Vertinimo byla turi leisti atkurti, kokia projekto versija nagrinėta. Pridėkite duomenų srautų schemą, formos laukų sąrašą, tiekėjo atsakymus ir priemonių patikros įrodymus. Jei dokumentas remiasi nuoroda į nuolat keičiamą techninį aprašą, išsaugokite reikalingą versiją arba patikimą jos identifikatorių. Taip vėliau bus įmanoma palyginti vertinimą su faktiniu paleidimu.

Prieigą prie PDAV priedų ribokite pagal poreikį. Rizikos aprašyme gali būti jautrių saugumo detalių, o konsultacijų medžiagoje – žmonių duomenų. Vieša santrauka, jei ji rengiama, ir vidinė išsami byla gali turėti skirtingą apimtį. Sprendimas dalintis informacija turi išlaikyti skaidrumą ir kartu neatskleisti nepagrįstai jautrios medžiagos.

Užbaigimo patikroje peržiūrėkite, ar neliko tuščių kritinių laukų, prieštaraujančių duomenų ar neįgyvendintų priemonių, kurios vertinime jau laikomos veikiančiomis. Neaiškus atsakymas „tiekėjas užtikrina“ turi būti pakeistas konkrečiu paaiškinimu arba aiškiai įvardyta likusia nepatikrinta aplinkybe. Tik tuomet sprendimą pasirašantis asmuo matys realų projekto pasirengimą.

L
Autorius
Legiscope
Legiscope

Pritaikykite šias gaires praktiškai

Sužinokite, kaip „Legiscope“ susieja privatumo registrus, šaltinius ir peržiūrimą darbą.

Užsisakyti pritaikytą demonstraciją
Skaityti toliau

Susiję straipsniai

01Duomenų apsauga

Apklausų duomenų apsauga: anonimiškumas ir rezultatų skelbimas

Apklausos duomenų apsaugos patikra prieš siunčiant kvietimą

2026 m. rugsėjo 8 d.
02Duomenų apsauga

Asmens duomenų šifravimas: raktai, prieiga ir atkūrimas

Asmens duomenų šifravimo planas turi parodyti, ką šifruojate, nuo kokios grėsmės saugote ir kas gali duomenis iššifruoti. Įrašas „viskas šifruojama“ neatsako, ar administratorius gali skaityti…

2026 m. rugsėjo 8 d.
03Duomenų apsauga

Asmens kodas Lietuvoje: rinkimo, paieškos ir viešinimo patikra

Asmens kodas Lietuvoje: rinkimo, paieškos ir viešinimo patikra

2026 m. rugsėjo 8 d.
04Duomenų apsauga

Asociacijų duomenų apsauga: nariai, savanoriai ir renginiai

Asociacijos narių sąrašas, savanorių grafikas ir renginio registracija dažnai keliauja per tų pačių žmonių rankas. Dėl to lengva manyti, kad visus kontaktus galima naudoti bet kuriai asociacijos…

2026 m. rugsėjo 8 d.
05Duomenų apsauga

Atsakymas VDAI į paklausimą: paaiškinimų ir priedų byla

Atsakymas VDAI į paklausimą: paaiškinimų ir priedų byla

2026 m. rugsėjo 8 d.
06Duomenų apsauga

Automatizuoti sprendimai: BDAR 22 straipsnio patikra

BDAR 22 straipsnio patikra prasideda nuo konkretaus sprendimo apie žmogų, o ne nuo programos pavadinimo. Reikia nustatyti, ar sprendimas pagrįstas vien automatizuotu tvarkymu ir ar sukelia teisinį…

2026 m. rugsėjo 8 d.
07Duomenų apsauga

BDAR 14 straipsnis: informavimas gavus duomenis iš kitur

Kai organizacija gauna žmogaus duomenis iš partnerio, viešo šaltinio ar kitos įmonės, reikia atskirai įvertinti informavimo pareigą. Duomenų tiekėjo pažadas, kad sąrašas surinktas teisėtai, dar…

2026 m. rugsėjo 8 d.
08Duomenų apsauga

BDAR 6 straipsnis: teisinio pagrindo pasirinkimo matrica

Teisinis pagrindas parenkamas konkrečiam duomenų tvarkymo tikslui. Vienam klientui priklausantys duomenys gali būti reikalingi užsakymui pristatyti, sąskaitai saugoti ir pasirenkamam naujienlaiškiui…

2026 m. rugsėjo 8 d.