Pranešimas apie asmens duomenų saugumo pažeidimą yra sprendimas pagal BDAR 33 ir 34 straipsnius, o ne kiekvieno IT sutrikimo automatinis persiuntimas VDAI. Valdytojas turi nustatyti, ar incidentas paveikė asmens duomenų konfidencialumą, vientisumą arba prieinamumą, įvertinti riziką žmonėms ir pagal tai spręsti dėl pranešimo institucijai bei atskiro pranešimo žmonėms. Kai institucijai pranešti reikia, tai daroma nepagrįstai nedelsiant ir, jei įmanoma, per 72 valandas nuo sužinojimo; vėlesnio pranešimo priežastys paaiškinamos. Šiame straipsnyje nagrinėjamas sprendimas ir pranešimo turinys. Kasdienį veiksmų paskirstymą aptaria pažeidimų valdymo procedūra.
1. Ar įvyko asmens duomenų saugumo pažeidimas?
BDAR 4 straipsnio 12 punktas apima saugumo pažeidimą, dėl kurio asmens duomenys netyčia ar neteisėtai sunaikinami, prarandami, pakeičiami, atskleidžiami be leidimo arba prie jų be leidimo gaunama prieiga. Tai gali būti klaidingam adresatui išsiųstas klientų sąrašas, neteisėtai pakeista paciento byla, prarastas nešifruotas nešiojamasis kompiuteris ar ištrinta duomenų bazė be veikiančios kopijos. Ne kiekvienas neveikiantis serveris automatiškai reiškia asmens duomenų pažeidimą: nustatykite, ar jame buvo asmens duomenų ir kaip juos paveikė įvykis.
Skirkite techninį incidentą nuo teisinio sprendimo. IT komanda gali pranešti apie kenkėjišką programą, bet duomenų valdytojas turi surinkti faktus apie paveiktus įrašus, prieigos galimybę ir atkūrimą. Vien pavadinimas „ransomware“ neatsako, ar duomenys buvo atskleisti, kiek laiko jie buvo neprieinami ar kokia žala tikėtina. Trumpa faktų lentelė padeda vėliau paaiškinti, kodėl pranešta arba nepranešta.
2. Kada prasideda 72 valandų skaičiavimas?
Pagal 33 straipsnio 1 dalį terminas prasideda tada, kai valdytojas sužino apie asmens duomenų saugumo pažeidimą. Tai nėra galutinės ekspertizės ar visų aukų skaičiaus patvirtinimo diena. Europos duomenų apsaugos valdybos gairės leidžia trumpą, operatyvų patikrinimą, ar įvykis tikrai yra asmens duomenų pažeidimas, bet ne neribotą laukimą. Užrašykite pirmo signalo, jo perdavimo atsakingiems asmenims ir pagrįsto sužinojimo momentą. Taip išvengsite termino skaičiavimo „nuo tada, kai vadovas perskaitė galutinę ataskaitą“.
Teisinė formuluotė yra nepagrįstai nedelsiant ir, jei įmanoma, ne vėliau kaip per 72 valandas. 72 valandos nėra siūlomas tikslas ar leidimas laukti iki paskutinės minutės. Jei pranešimas siunčiamas vėliau, jame reikia nurodyti vėlavimo priežastis. VDAI pranešimo puslapyje pateikia praktinį kanalą, tačiau jo santrauką skaitykite kartu su pilnu 33 straipsniu, kuriame yra rizikos išimtis ir galimybė informaciją teikti etapais.
3. Institucijos pranešimo slenkstis: rizika, o ne vien incidentas
Valdytojas praneša kompetentingai priežiūros institucijai, išskyrus atvejį, kai mažai tikėtina, kad pažeidimas keltų pavojų fizinių asmenų teisėms ir laisvėms. Šis „mažai tikėtina“ kriterijus nėra tas pats, kas „maža įmonė“ ar „mažai įrašų“. Vertinkite duomenų jautrumą, identifikavimo galimybę, poveikį, gavėjo patikimumą, apsaugos priemones ir pažeidžiamus asmenis. Sprendimą pagrįskite turimais faktais; nauji faktai gali pakeisti pirminį vertinimą.
Pavyzdys: darbuotojas neteisingai išsiuntė užšifruotą failą, kurio raktas nebuvo perduotas, patikimam vienam gavėjui. Jei apsauga veikė ir nėra kito prieigos būdo, rizika gali būti mažai tikėtina. Kitoks atvejis – viešai prieinama klientų sąskaitų duomenų bazė su adresais ir mokėjimo informacija. Net jei nėra įrodymo, kad kažkas ją parsisiuntė, reikia vertinti realų prieigos laikotarpį ir galimą žalą. Niekada nespręskite vien iš failo dydžio.
4. Pranešimas žmonėms yra atskiras, aukštesnis slenkstis
BDAR 34 straipsnis numato pranešimą duomenų subjektams nepagrįstai nedelsiant, kai pažeidimas gali sukelti didelį pavojų jų teisėms ir laisvėms. Taigi gali būti atvejis, kai reikia informuoti VDAI, bet nereikia atskiro pranešimo kiekvienam žmogui. Gali būti ir atvejis, kai pranešimo žmonėms poreikis paaiškėja po pirminės institucijos žinutės. Sprendimą priimkite pagal galimą poveikį, ne pagal norą išvengti reputacijos žalos.
34 straipsnio 3 dalyje numatytos išimtys: prieš įvykį taikytos priemonės padarė duomenis nesuprantamus neįgaliotiems asmenims, vėlesnės priemonės užtikrino, kad didelis pavojus greičiausiai nekils, arba individualus pranešimas pareikalautų neproporcingų pastangų; pastaruoju atveju reikia viešo ar panašiai veiksmingo informavimo. Vien teiginio „duomenys buvo užšifruoti“ neužtenka, jei raktas taip pat nutekėjo. VDAI gali reikalauti informuoti žmones, jei vertina pavojų kitaip.
Pranešimo žmogui paskirtis yra leisti jam apsisaugoti. Aiškiai parašykite, kas įvyko, kokie jo duomenys galėjo būti paveikti, su kuo susisiekti, kokios pasekmės ir kokių priemonių imtasi ar rekomenduojama imtis. Jei nutekėjo prisijungimo duomenys, pateikite konkrečias paskyros apsaugos rekomendacijas. Neslėpkite esminės informacijos po vienu sakiniu „galimas techninis nesklandumas“.
5. Ką nurodyti VDAI pranešime
33 straipsnio 3 dalyje nurodyti minimalūs elementai: pažeidimo pobūdis, kiek įmanoma duomenų subjektų ir įrašų kategorijos bei apytiksliai skaičiai, duomenų apsaugos pareigūno ar kito kontaktinio asmens duomenys, tikėtinos pasekmės ir priemonės, kurių imtasi ar siūloma imtis. Nežinomą skaičių žymėkite kaip apytikrį, nurodykite jo gavimo būdą. Atskirai pažymėkite, kas dar tiriama. Įprastam pranešimui nereikia laukti, kol visi laukai taps galutiniai.
Jei informacijos negalima pateikti vienu metu, 33 straipsnio 4 dalis leidžia ją teikti etapais be tolesnio nepagrįsto delsimo. Pirmas pranešimas neturėtų būti beprasmis „tiriame incidentą“: pateikite žinomą faktinį minimumą, kas kontaktinis asmuo ir kada tikimasi papildymo. Vėliau taisykite skaičius ir paaiškinkite, kas paaiškėjo. Teisiškai svarbus ne gražus PDF, o laiku perduota naudinga informacija ir sprendimo pėdsakas.
Lietuvos valdytojas turėtų patikrinti kompetentingą instituciją, ypač jei yra tarpvalstybinis tvarkymas arba specialus sektoriaus reguliavimas. VDAI yra įprasta Lietuvos BDAR priežiūros institucija; aktualų kanalą ir formą tikrinkite jos svetainėje. Kibernetinio saugumo subjektui gali egzistuoti ir atskiras pranešimas NKSC pagal Lietuvos kibernetinio saugumo taisykles. Vienas pranešimas automatiškai neatstoja kito; NIS2 Lietuvos taikymo vadovas padeda pradėti atskirą patikrą.
6. Tvarkytojas, valdytojas ir sutarties pranešimo grandinė
Pagal 33 straipsnio 2 dalį tvarkytojas, sužinojęs apie pažeidimą, praneša valdytojui nepagrįstai nedelsdamas. Valdytojas atsako už savo 33 ir 34 straipsnių sprendimus, nors techninius faktus gali pateikti tvarkytojas. 28 straipsnio sutartyje ar kitame privalomame teisiniame akte numatykite kontaktus, veiksmus ir pagalbą vykdant pareigas; teisės aktas taip pat gali būti tinkamas santykio pagrindas, jei atitinka straipsnį. Praktinis sutartinis pranešimo laikas gali būti trumpesnis nei valdytojo 72 valandų išorinis terminas, bet nėra vienodo BDAR nustatyto valandų skaičiaus visiems tvarkytojams.
Įvykus tiekėjo incidentui paklauskite: kurie jūsų duomenys paliesti, nuo kada tiekėjas tai žino, ar prieiga buvo sustabdyta, kokia informacija dar renkama? Tiekėjo sakinys „incidentas izoliuotas“ neatsako į rizikos klausimą. Užfiksuokite, kada pranešimas pasiekė valdytoją ir kada buvo pakankamai faktų suprasti asmens duomenų pažeidimą. Jei keli valdytojai naudojasi tuo pačiu tiekėju, kiekvieno padėtis gali skirtis.
7. Visi asmens duomenų pažeidimai dokumentuojami
33 straipsnio 5 dalis reikalauja dokumentuoti visus asmens duomenų saugumo pažeidimus, įskaitant tuos, apie kuriuos institucijai nepranešta. Įrašas turi apimti faktus, pasekmes ir priemones, kurių imtasi. Tai leidžia priežiūros institucijai patikrinti, ar pranešimo sprendimas buvo pagrįstas. Tačiau tai nereiškia, kad kiekviena nesėkminga prisijungimo užklausa yra atskiras BDAR pažeidimas. Pirmiausia nustatykite, ar iš tiesų paveikti asmens duomenys.
Registruokite ir sprendimo laiką: pirminė klasifikacija, papildomų faktų gavimas, rizikos pervertinimas, pranešimo pateikimas ir atsakymas žmonėms. Vienas įvykis gali keistis: pradžioje manoma, kad paveikta tuščia testinė aplinka, vėliau paaiškėja, kad joje buvo tikrų klientų duomenų. Atnaujinkite įrašą ir pranešimo vertinimą, neperrašydami istorijos taip, lyg nauja aplinkybė buvo žinoma nuo pradžių. Tai ypač svarbu, kai reikia paaiškinti delsą.
8. Du skirtingi pavyzdžiai
Pirmas: darbuotojas netyčia įtraukia matomus gavėjų adresus į laišką, kuriame pateikiama jautri paslaugos informacija. Pirmiausia atšaukite ar apribokite prieigą, jei įmanoma, ir nustatykite, kas gavo laišką, kokie duomenys atskleisti bei ar jie gali būti panaudoti žalingai. Jei pavojus asmenų teisėms nėra mažai tikėtinas, institucijai praneškite be nepagrįsto delsimo ir, jei įmanoma, per 72 valandas nuo sužinojimo. Jei pavojus didelis, atskirai informuokite žmones. Nesiremkit vien gavėjo pažadu ištrinti laišką, jei duomenys galėjo būti nukopijuoti.
Antras: organizacija praranda užšifruotą įrenginį, kurio raktas saugomas atskirai, prieigos slaptažodžiai atšaukti, o duomenys atkuriami iš veikiančios kopijos. Pažeidimas gali būti registruojamas kaip praradimas, bet faktai gali leisti pagrįsti, kad rizika žmogui mažai tikėtina ir VDAI pranešimo nereikia. Patikrinkite šifravimo būklę, rakto apsaugą ir ar buvo kitų duomenų kopijų. Jei įrenginys nebuvo užšifruotas arba jame buvo unikalūs sveikatos įrašai, išvada gali būti priešinga.
9. Po pranešimo: ištaisymas ir mokymasis
Išsiųstas pranešimas nereiškia, kad pareiga baigėsi. Užbaikite rizikos mažinimo veiksmus, atkurkite duomenis, patikrinkite prieigas ir informuokite žmones, jei jų informavimo slenkstis vėliau pasiekiamas. Nustatykite techninę priežastį ir proceso spragą: ar įvykį lėmė neteisinga gavėjų atranka, per plačios teisės, nesaugi tiekėjo konfigūracija, neveikianti atsarginė kopija? Priemonę susiekite su konkrečia spraga ir vėliau patikrinkite, ar ji veikia. Pritaikytoji duomenų apsauga padeda tokius sprendimus perkelti į sistemos projektavimą.
Jei incidentas palietė kelias tvarkymo veiklas, peržiūrėkite veiklos įrašus ir tiekėjų ryšius: galbūt inventoriuje nebuvo naujo duomenų srauto. Nesiųskite žmonėms abstraktaus pažado „daugiau nepasikartos“. Pasakykite, kas iš tiesų pakeista ir kokių veiksmų jie patys gali imtis. Vidinis atvejo uždarymas turi turėti atsakingą asmenį ir datą.
Rizikos vertinimą pagrįskite pasekmėmis žmogui
Rizika nėra vien techninės spragos sunkumo balas. Klauskite, ką konkretus duomenų praradimas, atskleidimas ar neprieinamumas gali padaryti žmogui: tapatybės vagystė, finansinis nuostolis, diskriminacija, grėsmė saugumui, profesinės paslapties praradimas ar negalėjimas gauti svarbios paslaugos. Vertinkite tikimybę ir galimą pasekmių rimtumą. Paprastas vardų sąrašas gali būti jautrus, jei jis atskleidžia apsilankymą pagalbos centre. Kita vertus, didelė užšifruotų techninių įrašų kopija gali kelti menką riziką, jei raktai apsaugoti ir duomenys atkurti.
Rizikos sprendimą užrašykite taip, kad jį galėtų suprasti ne vien jį priėmęs specialistas: kokie žmonės paveikti, ką apie juos galima sužinoti, kas turėjo prieigą, kiek laiko ir kokios priemonės sumažino poveikį. Jei neaišku, ar duomenys buvo parsisiųsti, nenuslėpkite nežinomybės. Pradinį vertinimą pažymėkite kaip preliminarų ir peržiūrėkite gavę žurnalus ar tiekėjo atsakymą. Nėra būtina išrasti tikslaus procentinio rizikos balo, kurio faktai nepagrindžia.
Tyrimo įrodymai ir pranešimo faktai
Saugokite techninius žurnalus, siuntimo informaciją, prieigos taisykles ir taisymo veiksmų laiką taip, kad incidento tyrimas nesunaikintų įrodymų. Kartu ribokite prieigą prie pačios incidento bylos: joje gali būti slaptažodžių pėdsakų, klientų duomenų ar saugumo spragų aprašų. VDAI pranešimui reikalinga aiški santrauka, bet vidinei komandai gali reikėti išsamesnių įrodymų. Šios dvi versijos neturi prieštarauti viena kitai; tiesiog jų tikslai skiriasi.
Jei pirminis pranešimas pateiktas su apytikriu paveiktų asmenų skaičiumi, vėliau išsaugokite, kodėl jis pasikeitė. Kai kurios kopijos gali būti senesnės, o kai kurie prisijungimai – tik testiniai. Skaičiaus pataisymas nėra savaime blogas, jei VDAI gaus papildymą be delsimo ir bylos istorija liks atsekama. Prieš siunčiant peržiūrėkite, ar pranešime nėra perteklinių kitų žmonių asmens duomenų.
Kelių teisinių režimų incidentas
Tarkime, ligoninės paslaugų sistema neveikia dėl atakos ir kartu galėjo būti nukopijuoti pacientų įrašai. Kibernetinio saugumo komanda vertina paslaugos sutrikimą bei galimą pranešimą NKSC, o duomenų apsaugos komanda – asmens duomenų pažeidimą ir pranešimą VDAI bei pacientams. Gali sutapti faktai, bet skiriasi teisės normos, slenksčiai ir gavėjai. Paskirkite vieną faktų koordinatorių, tačiau atskirai išsaugokite kiekvieno pranešimo sprendimą ir pateikimo įrodymą.
Negalima daryti išvados, kad kiekviena organizacija automatiškai turi NKSC pareigą vien todėl, kad patyrė kibernetinį incidentą. Lietuvos Kibernetinio saugumo įstatymo taikymas siejamas su nustatytais subjektais ir incidentų kategorijomis. Jei subjektas įtrauktas į registrą, naudokite aktualias NKSC oficialias gaires. Jei nėra, gerąją praktiką vis tiek galima taikyti, bet jos nevadinkite privalomu pranešimu.
Patikrinkite kontaktus ir prieinamumą prieš įvykį
Pranešimo terminai mažai naudingi, jei vienintelis atsakingas žmogus atostogauja ir niekas neturi jo prisijungimo. Turėkite du pasiekiamus vidinius kontaktus, tiekėjo avarinį kanalą ir nuorodą į aktualią VDAI formą. Kartą per pasirinktą vidaus ciklą suvaidinkite trumpą scenarijų: kas gauna signalą, kas nustato sužinojimo laiką, kas renka faktus, kas tvirtina rizikos sprendimą ir kas turi teisę siųsti pranešimą? Tai organizacinė rekomendacija, o ne BDAR nustatytas privalomas mokymų dažnis.
Bandymo rezultatas gali būti paprastas: nepavyko prisijungti prie žurnalų, tiekėjo telefono numeris pasenęs, pranešimo formos savininkas neaiškus. Pataisykite šiuos dalykus ir vėl išbandykite. Tokia peržiūra taip pat patikrina, ar organizacija gali tęsti darbą, kai pagrindinė sistema neveikia. Pažeidimo valdymas priklauso nuo realių žmonių ir kanalų, ne nuo vienoje programoje pažymėtos varnelės.
Pranešimo kalba ir paveiktų žmonių veiksmai
Kai reikia pranešti žmonėms, pranešimas turi atitikti realią jų padėtį. Jei nutekėjo pašto adresai ir užsakymų istorija, nurodykite galimą sukčiavimo ar apsimetimo riziką bei kaip atpažinti įtartinus laiškus. Jei prarasti prisijungimo duomenys, paaiškinkite, kaip pakeisti slaptažodį ir kur kreiptis. Jei paveikti sveikatos duomenys, žmonėms gali rūpėti konfidencialumas ir saugus kontaktas su įstaiga. Neatskleiskite jų individualių duomenų viešame pranešime vien todėl, kad tai lengviau nei individualus kanalas.
Prieš siųsdami pasitikrinkite, ar tekstas nėra tik teisinė formulė. Ar žmogus supras, kas įvyko, ką organizacija jau padarė, kas dar neaišku ir ką jis pats gali padaryti? Jei faktai pasikeičia, suplanuokite, kaip bus pateiktas pataisymas. Sąžininga pradinė žinutė su aiškiai įvardyta nežinomybe geriau padeda žmonėms nei kategoriškas saugumo pažadas, kurio tyrimas dar nepatvirtino.
Dažniausi klausimai
Ar apie kiekvieną IT incidentą reikia pranešti VDAI?
Ne. Pirmiausia nustatykite, ar tai asmens duomenų saugumo pažeidimas. Jei taip, jį dokumentuokite. VDAI pranešimas reikalingas, nebent mažai tikėtina, kad pažeidimas sukels pavojų asmenų teisėms ir laisvėms.
Ar 72 valandos yra absoliuti riba?
33 straipsnis reikalauja pranešti nepagrįstai nedelsiant ir, jei įmanoma, per 72 valandas nuo sužinojimo. Vėlesnis pranešimas turi paaiškinti vėlavimo priežastis. Neatidėliokite vien todėl, kad dar neaiškus galutinis paveiktų asmenų skaičius; informaciją galima papildyti etapais.
Kada informuoti asmenis?
Kai pažeidimas gali sukelti didelį pavojų jų teisėms ir laisvėms, išskyrus konkrečias 34 straipsnio 3 dalies situacijas. Institucijos ir asmenų informavimo slenksčiai skirtingi. Aiškus pranešimas turi padėti žmogui suprasti padėtį ir apsisaugoti.
Kas, jei pažeidimą aptiko išorinis tiekėjas?
Tvarkytojas turi pranešti valdytojui nepagrįstai nedelsdamas. Valdytojas su tiekėju surenka faktus ir vertina savo pranešimo pareigas. Sutartyje iš anksto nustatykite veikiančius kontaktus bei pagalbą, tačiau sutarties laikrodis nekeičia 33 straipsnio reikalavimų.
Ar reikia saugoti nepranešto pažeidimo įrašą?
Taip. 33 straipsnio 5 dalis apima visus asmens duomenų saugumo pažeidimus. Užrašykite faktus, poveikį, priemones ir pagrindą, kodėl VDAI nepranešta. Vien techninio įvykio, kuris asmens duomenų nepaveikė, nelaikykite tokiu pažeidimu vien dėl pavadinimo.
Šaltiniai, peržiūrėti 2026 m. rugsėjo 27 d.: BDAR 4, 33 ir 34 straipsniai, VDAI pranešimo kanalas ir gairės, VDAI 2026 m. pirmojo pusmečio incidentų apžvalga.