72 valandos: kaip reaguoti į duomenų pažeidimą pagal BDAR

Asmens duomenų saugumo pažeidimas pagal BDAR 4 str. 12 p. — saugumo pažeidimas, dėl kurio netyčia arba neteisėtai sunaikinami, prarandami, pakeičiami, atskleidžiami ar tampa prieinami tvarkomi asmens duomenys. Įvykus tokiam pažeidimui, duomenų valdytojas privalo pranešti VDAI per 72 valandas nuo sužinojimo (BDAR 33 str.), o jei pažeidimas kelia didelę riziką — informuoti ir pačius asmenis (34 str.).

Daugumai įmonių duomenų pažeidimas atrodo kaip tolima abstrakcija — kol vieną rytą buhalterė nepamato, kad jos paskyra siunčia laiškus visiems klientams, arba IT skyrius neaptinka nepažįstamo prisijungimo prie klientų bazės iš užsienio IP. Tą akimirką prasideda atskaitos taškas, kuris BDAR kalboje vadinamas „sužinojimu". Nuo jo iki pranešimo VDAI lieka 72 valandos, ir savaitgaliai į jas įskaičiuojami.

Problema ta, kad pirmosios valandos po incidento yra chaotiškos. Niekas tiksliai nežino, kas nutiko, kiek duomenų paveikta ir ar apskritai reikia pranešti. Būtent todėl reikalingas iš anksto paruoštas protokolas — kad sprendimai būtų priimami pagal planą, o ne panikoje. Šis straipsnis ir yra toks protokolas, paremtas BDAR 33–34 straipsniais ir Europos duomenų apsaugos valdybos (EDPB) gairėmis.

Kas laikoma duomenų pažeidimu pagal BDAR?

Pirmas dažnas nesusipratimas — manyti, kad duomenų pažeidimas yra tik įsilaužimas iš išorės. Iš tiesų BDAR apibrėžimas platesnis ir apima tris pažeidimo tipus, kurie gali įvykti ir be jokio piktavalio veiksmo.

• Konfidencialumo pažeidimas — asmens duomenys atskleidžiami arba tampa prieinami neįgaliotiems asmenims. Pavyzdys: laiškas su klientų sąrašu išsiųstas ne tam adresatui, arba pavogta duomenų bazė.
• Vientisumo pažeidimas — duomenys neteisėtai pakeičiami. Pavyzdys: užpuolikas pakeičia banko rekvizitus sąskaitose arba kenkėjiška programa sugadina įrašus.
• Prieinamumo pažeidimas — duomenys prarandami arba laikinai tampa nepasiekiami. Pavyzdys: ransomware užšifruoja serverį, arba sugenda diskas be atsarginės kopijos.

Klasikinis prieinamumo pažeidimo atvejis — ransomware. Šiuolaikinės grupuotės pirma slapta išsiunčia duomenis (data exfiltration), o tik tada juos užšifruoja. Tokiu atveju įvyksta net du pažeidimai vienu metu: ir prieinamumo (duomenys užšifruoti), ir konfidencialumo (duomenys nutekinti). EDPB gairėse ransomware pateikiamas kaip tipinis pranešimo VDAI atvejis.

Ne kiekviena ataka yra pažeidimas

Svarbi skirtis: jei kibernetinė ataka atremta ir asmens duomenys nepaveikti, BDAR pranešimo pareiga neatsiranda. Atremtas brute-force bandymas prisijungti, sustabdytas DDoS — tai saugumo įvykiai, bet ne asmens duomenų pažeidimai BDAR prasme. Vis dėlto, jei jūsų įmonė patenka į NIS2 reguliavimo apimtį, gali galioti atskira pareiga pranešti incidentą NKSC. Detaliau apie NIS2 — straipsnyje apie NIS2 direktyvą Lietuvoje.

Iš kur tos 72 valandos ir nuo kada jos skaičiuojamos?

BDAR 33 str. 1 d. formuluotė tiksli: valdytojas praneša priežiūros institucijai „nepagrįstai nedelsdamas ir, jei įmanoma, ne vėliau kaip per 72 valandas nuo to laiko, kai sužino apie asmens duomenų saugumo pažeidimą". Du dalykai čia esminiai — „nepagrįstai nedelsdamas" ir „sužino".

„Sužinojimo" momentas

72 valandos pradedamos skaičiuoti ne nuo paties pažeidimo, o nuo to momento, kai valdytojas pagrįstai įsitikina, kad pažeidimas įvyko. EDPB gairėse 9/2022 leidžiamas trumpas tyrimo laikotarpis — pavyzdžiui, gavus pranešimą apie įtartiną veiklą, galima skirti kelias valandas patikrinti, ar tai realus pažeidimas. Bet vos tik įsitikinama, kad pažeidimas tikras, laikrodis pradeda tikti, ir delsimas „kol bus aišku viskas" nebepriimtinas.

Praktinė pasekmė: jeigu darbuotojas penktadienį pastebi įtartiną veiklą, bet apie tai praneša tik pirmadienį, valdytojas vis tiek laikomas „sužinojusiu" nuo to momento, kai darbuotojas pamatė problemą. Todėl vidinis pranešimo kanalas turi veikti nepertraukiamai — incidentas neturi laukti darbo dienos pradžios.

Kas, jei nespėjama per 72 valandas?

Terminas nėra absoliutus. BDAR 33 str. 1 d. tiesiogiai numato, kad jei pranešama vėliau nei per 72 valandas, prie pranešimo pridedamas vėlavimo priežasčių pagrindimas. Tačiau pagrindimas turi būti objektyvus — sudėtingas tyrimas, didelė pažeidimo apimtis. „Nespėjome, nes buvo savaitgalis" pagrindimu nelaikoma. Be to, 33 str. 4 d. leidžia teikti informaciją etapais: pradinis pranešimas laiku, papildymai vėliau.

Reagavimo protokolas — 6 etapai

Veikiantis incidentų valdymas nėra dokumentas stalčiuje — tai išrepetuota seka veiksmų, kuriuos komanda žino atmintinai. Žemiau pateikti šeši etapai sudaro pagrindinį protokolą. Pirmieji trys vyksta lygiagrečiai ir skubiai, ketvirtas–penktas priklauso nuo rizikos vertinimo rezultato, šeštas užbaigia procesą.

1. Aptikimas ir fiksavimas. Užfiksuokite, kada ir kaip pažeidimas pastebėtas. Surinkite pradinius įrodymus — sistemos žurnalus, ekrano nuotraukas, pranešimą iš darbuotojo. Šie įrodymai vėliau bus reikalingi ir tyrimui, ir pranešimui. Šiuo momentu pradeda tikti 72 valandų laikrodis.
2. Izoliavimas ir žalos stabdymas. Atjunkite paveiktas sistemas, atšaukite kompromituotas paskyras ir aktyvias sesijas, pakeiskite slaptažodžius. Tikslas vienas — kad pažeidimas neaugtų, kol vyksta vertinimas. Svarbu nesunaikinti įrodymų: izoliuoti, bet ne formatuoti.
3. Rizikos vertinimas. Įvertinkite, ar pažeidimas kelia riziką asmenų teisėms ir laisvėms — tai lemia, ar reikia pranešti VDAI. Ir ar kelia didelę riziką — tai lemia, ar reikia informuoti subjektus.
4. Pranešimas VDAI. Jei pažeidimas kelia riziką, pateikite pranešimą per 72 valandas elektroniniu būdu.
5. Subjektų informavimas. Jei rizika didelė — informuokite paveiktus asmenis aiškia kalba, nepagrįstai nedelsiant.
6. Dokumentavimas. Įrašykite pažeidimą į vidinį registrą su visomis aplinkybėmis ir priimtais sprendimais — privaloma net jei VDAI nepranešta.

Pirmieji du etapai techniniai — juos vykdo IT komanda. Trečias ir vėlesni reikalauja teisinio vertinimo, todėl DPO arba teisininkas turi būti įtrauktas nuo pat pradžios, o ne kai jau reikia rašyti pranešimą. Praktikoje būtent vėlyvas teisininko įtraukimas suvalgo brangias valandas.

Kaip įvertinti, ar pažeidimas kelia riziką

Rizikos vertinimas yra protokolo širdis — nuo jo priklauso, ar reikia pranešti VDAI, ir ar reikia informuoti žmones. BDAR nepateikia tikslios formulės, bet EDPB gairėse išvardyti kriterijai, į kuriuos reikia atsižvelgti.

• Duomenų pobūdis. Vardas ir el. paštas kelia mažesnę riziką nei asmens kodas, finansiniai, sveikatos ar prisijungimo duomenys. Ypatingų kategorijų duomenys (sveikata, biometriniai, įsitikinimai) beveik visada reiškia didelę riziką.
• Subjektų ir įrašų kiekis. Vienas paveiktas klientas ir 50 000 paveiktų klientų — skirtingo masto incidentai.
• Galimybė identifikuoti asmenis. Jei duomenys buvo užšifruoti ar pseudonimizuoti, faktinė rizika mažesnė.
• Pasekmių sunkumas. Ar pažeidimas gali sukelti tapatybės vagystę, finansinę žalą, diskriminaciją, reputacijos žalą.
• Subjektų pažeidžiamumas. Vaikų, pacientų ar darbuotojų duomenys vertinami atsargiau.

Praktinis pavyzdys: pavogtas nešiojamas kompiuteris su pilnai užšifruotu disku, kurio raktą turi tik savininkas, paprastai nekelia rizikos — duomenys neprieinami. Toks pažeidimas registruojamas, bet VDAI pranešti gali nereikėti. Priešingas atvejis — nutekėjusi klientų bazė su slaptažodžiais ir mokėjimo duomenimis — beveik garantuotai reiškia ir pranešimą VDAI, ir subjektų informavimą.

Pranešimas VDAI — kas turi būti nurodyta

Pranešimas Valstybinei duomenų apsaugos inspekcijai teikiamas elektroniniu būdu. BDAR 33 str. 3 d. nustato minimalų turinį, kurį pranešimas privalo apimti — net jei dalies informacijos dar nežinote, ją galima papildyti vėliau.

• Pažeidimo pobūdis — kas nutiko, kada, kokio tipo pažeidimas (konfidencialumo, vientisumo, prieinamumo), ir, jei įmanoma, paveiktų subjektų bei įrašų kategorijos ir apytikslis skaičius.
• DPO arba kontaktinio asmens duomenys — kas institucijoje atsakys į papildomus klausimus.
• Tikėtinos pasekmės — kokią žalą pažeidimas gali sukelti paveiktiems asmenims.
• Priemonės — kokių veiksmų jau imtasi pažeidimui pašalinti ir padariniams sumažinti, ir kokių planuojama imtis.

Pastebėjimas iš praktikos: VDAI vertina ne tik patį pažeidimą, bet ir tai, kaip įmonė į jį reagavo. Aiškiai aprašytos priemonės — slaptažodžių keitimas, MFA įjungimas, subjektų informavimas — rodo, kad organizacija valdo situaciją. Tuščias, vėluojantis ar painus pranešimas, priešingai, signalizuoja, kad atitikties sistemos nėra, ir tai gali padidinti baudą.

Kada ir kaip informuoti duomenų subjektus

Pranešimas VDAI ir informavimas subjektams — du atskiri reikalavimai su skirtingomis ribomis. VDAI pranešama, kai pažeidimas kelia riziką. Subjektai informuojami tik tada, kai rizika DIDELĖ (BDAR 34 str.). Tai aukštesnė kartelė — ne kiekvienas pažeidimas, apie kurį pranešta VDAI, reikalauja kreiptis į žmones.

Kada informuoti privaloma

Informuoti reikia, kai pažeidimas gali sukelti realią žalą — nutekėjo slaptažodžiai, mokėjimo kortelių duomenys, asmens kodai, sveikatos informacija. Informavimas turi būti aiškus ir tiesioginis: aprašomas pažeidimo pobūdis, nurodomi DPO kontaktai, galimos pasekmės ir konkrečios rekomendacijos — pavyzdžiui, nedelsiant pakeisti slaptažodžius arba stebėti banko sąskaitą.

Kada informuoti nereikia

BDAR 34 str. 3 d. numato tris išimtis. Informuoti subjektų nereikia, jei: duomenys buvo užšifruoti taip, kad neprieinami pašaliniams; po pažeidimo imtasi priemonių, dėl kurių didelė rizika nebeaktuali; arba individualus informavimas pareikalautų neproporcingų pastangų — tada skelbiamas viešas pranešimas, pasiekiantis subjektus lygiavertiškai. Pastaroji išimtis aktuali, pavyzdžiui, kai paveikti šimtai tūkstančių asmenų ir tiesioginis kontaktas neįmanomas.

Pažeidimų registras — privalomas net be pranešimo

Vienas dažniausiai pamirštamų reikalavimų — vidinis pažeidimų registras. BDAR 33 str. 5 d. įpareigoja valdytoją dokumentuoti VISUS pažeidimus, įskaitant tuos, apie kuriuos VDAI nepranešta. Tai atskaitomybės principo (5 str. 2 d.) dalis.

Registras nebūtinai turi būti sudėtinga sistema — pakanka struktūruotos lentelės su privalomais laukais: pažeidimo data ir sužinojimo data, pažeidimo aprašymas ir tipas, paveiktų duomenų ir subjektų kategorijos, rizikos vertinimo išvada, sprendimas (ar pranešta VDAI, ar informuoti subjektai, jei ne — pagrindimas), priimtos priemonės. Per VDAI patikrinimą šis registras yra pirmas dokumentas, kurio paprašoma, ir jo nebuvimas pats savaime laikomas pažeidimu.

Praktinė taisyklė: jei pažeidimą nusprendėte nepranešti VDAI, šis sprendimas turi būti registre pagrįstas taip pat kruopščiai, kaip ir pats pranešimas. „Nusprendėme, kad nereikia" be argumentų — atskaitomybės spraga.

Tvarkytojo vaidmuo ir sutarties spąstai

Daugelis pažeidimų įvyksta ne pas patį valdytoją, o pas jo paslaugų tiekėjus — debesijos paslaugas, IT priežiūros įmones, marketingo platformas. Tai duomenų tvarkytojai (processors), ir jų vaidmuo incidente kritiškas, nes būtent jie dažnai pirmieji pastebi pažeidimą.

BDAR 33 str. 2 d. nustato, kad tvarkytojas, sužinojęs apie pažeidimą, „nepagrįstai nedelsdamas" praneša valdytojui. Bet 72 valandų laikrodis priklauso valdytojui — todėl jeigu tvarkytojas vilkina pranešimą jums kelias dienas, jūsų terminas jau bėga. Apsauga viena: duomenų tvarkymo sutartyse aiškiai nustatyti tvarkytojo pranešimo terminą (pvz., per 24 valandas) ir konkretų kanalą bei kontaktinį asmenį.

5 dažniausios klaidos pirmąsias 72 valandas

Per metus apžiūrėjus dešimtis incidentų, klaidos kartojasi. Štai penkios, kurios brangiausiai kainuoja.

1. Laukimas, „kol bus aišku viskas". Komandos delsia pranešti, nes nori pilno tyrimo rezultatų. Bet 33 str. 4 d. leidžia teikti dalinį pranešimą — geriau pranešti laiku su žinoma informacija nei praleisti terminą.
2. Įrodymų sunaikinimas. Skubant „sutvarkyti" sistemą, perinstaliuojami serveriai ar ištrinami žurnalai. Tai apsunkina tyrimą ir gali būti vertinama kaip pažeidimo slėpimas.
3. DPO įtraukimas per vėlai. Teisininkas pakviečiamas, kai jau reikia rašyti pranešimą — tada nebelieka laiko tinkamam rizikos vertinimui.
4. Vertinimo nedokumentavimas. Net jei nusprendžiama nepranešti, sprendimas turi būti pagrįstas registre. Vertinimo nebuvimas dažnai kainuoja brangiau nei pats incidentas.
5. Subjektų informavimo painiojimas su VDAI pranešimu. Vienas reikalavimas (VDAI) nepanaikina kito (subjektai), ir atvirkščiai — tai du atskiri vertinimai su skirtingomis ribomis.

Penktadienio vakarą pastebėjome įtartiną prieigą prie klientų duomenų bazės. Be aiškaus plano būtume praradę brangias valandas. Veriva incidentų valdymo komanda per kelias valandas padėjo izoliuoti pažeidimą, įvertinti riziką ir paruošti pranešimą VDAI laiku. Terminas išlaikytas, subjektai informuoti tvarkingai, baudos išvengta.

Ką paruošti dabar, kol incidento dar nėra

Incidentų valdymo paradoksas — beveik viskas, kas lemia sėkmingą reagavimą, padaroma prieš incidentą. Štai konkretūs žingsniai, kuriuos verta sutvarkyti, kol laikrodis dar netiksi:

1. Paruoškite incidentų valdymo procedūrą. Kas ką daro, kokia tvarka, kas priima sprendimą pranešti. Ne dešimties puslapių dokumentas, o aiškus veiksmų sąrašas su atsakingais asmenimis.
2. Sukurkite pažeidimų registrą. Struktūruota lentelė su privalomais laukais — kad incidento metu tik užpildytumėte, o ne kurtumėte iš naujo.
3. Paruoškite pranešimo VDAI šabloną. Su visais 33 str. 3 d. laukais — incidento metu lieka tik įrašyti faktus.
4. Patikrinkite sutartis su tvarkytojais. Ar jose yra punktas dėl pranešimo per konkretų terminą.
5. Užtikrinkite nepertraukiamą vidinį pranešimo kanalą. Darbuotojas turi žinoti, kur pranešti įtartiną veiklą bet kuriuo paros metu.

Šie penki elementai sudaro pagrindą, kurio reikalauja ir BDAR 32 str. (organizacinės priemonės), ir atskaitomybės principas. Veriva paruošia visą incidentų valdymo paketą — procedūrą, registrą, pranešimo šablonus ir darbuotojų instruktažą — pritaikytą jūsų įmonės dydžiui ir veiklai. Kadangi mūsų komandoje dirba ir teisininkai, ir IT specialistai, pažeidimo metu gausite vieną kontaktą abiems pusėms: ir techninei izoliacijai, ir teisiniam vertinimui. Pirmoji konsultacija dažniausiai būna nemokama — galima įvertinti, ko trūksta, prieš sprendimą.

---

Šaltiniai: Valstybinė duomenų apsaugos inspekcija (VDAI) · BDAR (Reglamentas 2016/679) 33–34 straipsniai · Europos duomenų apsaugos valdyba (EDPB) — gairės dėl pranešimų apie pažeidimus