Duomenų apsauga

Pritaikytoji duomenų apsauga (BDAR 25 str.): gidas 2026

Pritaikytoji ir standartizuotoji duomenų apsauga pagal BDAR 25 str.: ką reiškia data protection by design and by default, praktinės priemonės ir VDAI praktika 2026.

Also available in:English·Français

Pritaikytoji ir standartizuotoji duomenų apsauga (angl. data protection by design and by default) – tai Bendrojo duomenų apsaugos reglamento (BDAR) 25 straipsnyje įtvirtintas reikalavimas duomenų apsaugą integruoti į sistemas ir procesus nuo pat jų kūrimo pradžios, o ne pridėti vėliau. Pritaikytoji apsauga (by design) reiškia, kad techninės ir organizacinės priemonės – pavyzdžiui, pseudonimizavimas ar duomenų kiekio mažinimas – įdiegiamos jau projektuojant tvarkymą. Standartizuotoji apsauga (by default) reiškia, kad numatytieji nustatymai užtikrina tvarkymą tik tų duomenų, kurie būtini konkrečiam tikslui – be papildomo naudotojo veiksmo.

Šis principas yra praktinė poveikio duomenų apsaugai vertinimo tąsa ir atskaitomybės dalis. Šiame straipsnyje paaiškinu, ką 25 straipsnis reikalauja praktiškai, kokias priemones taikyti ir kokių klaidų vengti.

Ką reiškia „by design" ir „by default"

25 straipsnio 1 dalis (pritaikytoji apsauga) reikalauja, kad valdytojas, atsižvelgdamas į technikos išsivystymo lygį, įgyvendinimo sąnaudas, tvarkymo pobūdį bei riziką, tiek nustatydamas tvarkymo priemones, tiek paties tvarkymo metu įgyvendintų tinkamas technines ir organizacines priemones duomenų apsaugos principams (BDAR 5 str.) veiksmingai įgyvendinti. Kaip pavyzdys tiesiogiai nurodomas pseudonimizavimas ir duomenų kiekio mažinimas.

25 straipsnio 2 dalis (standartizuotoji apsauga) reikalauja, kad numatytaisiais nustatymais būtų tvarkomi tik tie asmens duomenys, kurie būtini konkrečiam tikslui. Tai apima tvarkomų duomenų kiekį, tvarkymo apimtį, saugojimo laikotarpį ir prieinamumą. Konkretus pavyzdys: socialinio tinklo profilis pagal nutylėjimą neturi būti matomas neribotam asmenų skaičiui be naudotojo veiksmo.

Praktinis skirtumas nuo saugumo

Pritaikytoji apsauga nėra tas pats, kas duomenų saugumas (BDAR 32 str.). Saugumas apsaugo nuo neteisėtos prieigos, o pritaikytoji apsauga įgyvendina visus duomenų apsaugos principus – teisėtumą, kiekio mažinimą, saugojimo ribojimą, skaidrumą. Praktikoje jos persidengia, tačiau 25 straipsnis platesnis: jis reikalauja apsaugą projektuoti, o ne tik apsaugoti jau surinktus duomenis.

Praktinės priemonės

Pritaikytąją apsaugą įgyvendina konkrečios priemonės, taikomos projektavimo etape:

  1. Duomenų kiekio mažinimas – renkami tik būtini laukai; neprivalomi laukai pažymimi kaip pasirinktini.
  2. Pseudonimizavimas ir šifravimas – identifikatoriai atskiriami nuo turinio; duomenys šifruojami saugant ir perduodant.
  3. Numatytieji privatumo nustatymai – griežčiausi nustatymai taikomi pagal nutylėjimą; naudotojas gali juos susilpninti sąmoningu veiksmu.
  4. Prieigos ribojimas – prieiga suteikiama tik pagal „būtina žinoti" principą.
  5. Automatinis saugojimo terminų taikymas – duomenys ištrinami ar nuasmeninami pasibaigus terminui.
  6. Skaidrumas kaip numatytoji būsena – naudotojui aišku, kokie duomenys renkami, per privatumo politiką ir sąsają.

Šias priemones geriausia dokumentuoti kartu su tvarkymo veiklos įrašais ir poveikio vertinimu. Platformos, tokios kaip Legiscope, padeda susieti kūrimo etapo sprendimus su registro operacijomis ir vertinimais.

Kodėl principas svarbus praktikoje

Lietuvos praktika rodo, kad pritaikytosios apsaugos nebuvimas yra baudžiamas. 2021 m. programėlės „Karantinas" byloje VDAI skyrė 12 000 eurų baudą Nacionaliniam visuomenės sveikatos centrui ir 3 000 eurų programėlę kūrusiai UAB „IT sprendimai sėkmei", be kita ko, už atskaitomybės (BDAR 24 str.) ir tinkamų techninių bei organizacinių priemonių trūkumą tvarkant sveikatos duomenis dideliu mastu. Byloje pritrūko ir poveikio vertinimo, kuris būtų atskleidęs riziką dar projektavimo etape. Atvejis rodo, kad duomenų apsaugą reikia įtraukti nuo pat sistemos kūrimo, o ne diegti po paleidimo.

Dažnos klaidos

  • Apsaugos „pridėjimas" po paleidimo. 25 straipsnis reikalauja projektuoti apsaugą iš anksto, o ne taisyti jau veikiančią sistemą.
  • Numatytųjų nustatymų ignoravimas. Pagal nutylėjimą turi būti tvarkoma kuo mažiau duomenų; „viskas įjungta" pažeidžia 25 str. 2 d.
  • Saugumo painiojimas su pritaikytąja apsauga. Šifravimas yra priemonė, bet ne visas 25 straipsnis, kuris apima visus duomenų apsaugos principus.
  • Sprendimų nedokumentavimas. Projektavimo etapo apsaugos priemonės turi būti užfiksuotos atskaitomybei įrodyti.

Pritaikytoji apsauga kūrimo cikle

Kad 25 straipsnis nebūtų deklaracija, apsaugos reikalavimus reikia įtraukti į kiekvieną naujo produkto ar proceso kūrimo etapą. Reikalavimų etape apibrėžiama, kokie duomenys iš tiesų būtini, ir atmetami „gali prireikti" laukai. Projektavimo etape parenkama architektūra – identifikatorių atskyrimas, šifravimas, prieigos modelis. Kūrimo etape numatytieji nustatymai konfigūruojami griežčiausiai. Testavimo etape tikrinama, ar nenaudojami realūs asmenų duomenys ir ar numatytieji nustatymai veikia. Diegimo etape atliekamas galutinis patikrinimas, o prireikus – poveikio duomenų apsaugai vertinimas.

Konkretus pavyzdys – naujos registracijos formos kūrimas. Pritaikytoji apsauga reiškia: forma prašo tik būtinų laukų (vardas, el. paštas), o ne visko „dėl visa ko"; neprivalomi laukai aiškiai pažymėti; rinkodaros sutikimas yra atskiras, iš anksto nepažymėtas langelis; duomenys šifruojami; saugojimo terminas taikomas automatiškai. Standartizuotoji apsauga reiškia, kad, jei naudotojas nieko nekeičia, jo duomenys tvarkomi tik būtinu mastu.

Viešuosiuose pirkimuose ir renkantis tiekėją pritaikytoji apsauga tampa atrankos kriterijumi: perkant IT sprendimą verta reikalauti, kad tiekėjas parodytų, kokias numatytąsias apsaugos priemones jis įdiegęs, ir tai įtvirtinti duomenų tvarkymo sutartyje. BDAR 25 straipsnis formaliai neįpareigoja gamintojų, tačiau valdytojas atsako už galutinį sprendimą, todėl netinkamo produkto pasirinkimas tampa jo problema. Todėl apsaugos reikalavimus geriau kelti pirkimo, o ne diegimo etape.

Kas atsakingas ir kaip įrodyti

25 straipsnio prievolė tenka duomenų valdytojui, tačiau praktikoje ją įgyvendina produktų ir IT komandos kartu su duomenų apsaugos pareigūnu. Svarbu, kad DAP būtų įtraukiamas nuo pat pradžios, o ne po paleidimo – vėliau taisyti architektūrą brangu ir sudėtinga. Atitiktį įrodo dokumentacija: kokie duomenų apsaugos sprendimai priimti projektuojant, kokie numatytieji nustatymai pasirinkti ir kodėl. Ši dokumentacija siejama su tvarkymo veiklos įrašais ir poveikio vertinimu. Būtent dokumentacijos trūkumas „Karantino" byloje buvo viena priežasčių konstatuoti atskaitomybės pažeidimą – organizacija negalėjo parodyti, kad apsauga buvo įvertinta ir įdiegta iš anksto.

Dažnai užduodami klausimai

Kuo skiriasi pritaikytoji ir standartizuotoji apsauga?

Pritaikytoji apsauga (by design) reiškia apsaugos integravimą į sistemą jos kūrimo metu. Standartizuotoji apsauga (by default) reiškia, kad numatytieji nustatymai užtikrina tvarkymą tik būtinų duomenų. Pirmoji susijusi su projektavimu, antroji – su numatytąja konfigūracija.

Ar 25 straipsnis taikomas mažoms įmonėms?

Taip. Principas taikomas visiems valdytojams, tačiau įgyvendinimo apimtis proporcinga rizikai, sąnaudoms ir technikos lygiui. Maža įmonė gali taikyti paprastesnes priemones, bet privalo į duomenų apsaugą atsižvelgti jau kurdama procesus.

Ar pakanka duomenis šifruoti?

Ne. Šifravimas yra viena priemonė, tačiau 25 straipsnis reikalauja įgyvendinti visus duomenų apsaugos principus – kiekio mažinimą, saugojimo ribojimą, skaidrumą, prieigos ribojimą. Šifravimas jų nepakeičia.

Kaip įrodyti, kad laikausi 25 straipsnio?

Dokumentuojant projektavimo etapo sprendimus: kokios priemonės pasirinktos ir kodėl, kokie numatytieji nustatymai. Šie įrašai siejami su tvarkymo veiklos įrašais ir poveikio vertinimu.

Ar 25 straipsnis įpareigoja programinės įrangos gamintojus?

Formaliai prievolė tenka duomenų valdytojui, ne gamintojui. Tačiau BDAR 78 konstatuojamoji dalis skatina gamintojus atsižvelgti į duomenų apsaugą kuriant produktus, o valdytojas atsako už galutinį pasirinkimą – todėl praktikoje apsaugos reikalavimai keliami tiekėjui per pirkimą ir duomenų tvarkymo sutartį. Netinkamo produkto pasirinkimas tampa valdytojo problema.

Kuo pritaikytoji apsauga skiriasi nuo poveikio vertinimo?

Poveikio vertinimas yra procesas rizikai įvertinti, o pritaikytoji apsauga – rezultatas: konkrečios priemonės, integruotos į sistemą. Vertinimas dažnai nustato, kokių pritaikytosios apsaugos priemonių reikia, todėl abu veikia kartu. Vertinimas atsako į klausimą „kokia rizika", o pritaikytoji apsauga – „ką dėl jos padarysime".

Nuo ko pradėti diegti 25 straipsnį mažoje įmonėje?

Pradėkite nuo numatytųjų nustatymų ir renkamų duomenų peržiūros: ar formos neprašo perteklinių laukų, ar prieiga ribojama pagal poreikį, ar taikomi saugojimo terminai. Šie paprasti sprendimai jau įgyvendina didelę dalį 25 straipsnio be didelių sąnaudų. Sudėtingesnes priemones – šifravimą, pseudonimizavimą – diekite proporcingai rizikai ir turimoms galimybėms.

Išvada

Pritaikytoji ir standartizuotoji duomenų apsauga reikalauja duomenų apsaugą integruoti į sistemas nuo jų kūrimo pradžios ir užtikrinti, kad numatytieji nustatymai apimtų tik būtinus duomenis. Tai platesnė nei saugumas prievolė, apimanti visus BDAR principus. „Karantino" byla parodė, kad apsaugos neįtraukimas projektavimo etape baudžiamas. Taikykite konkrečias priemones – kiekio mažinimą, pseudonimizavimą, griežtus numatytuosius nustatymus – ir jas dokumentuokite kartu su registru bei poveikio vertinimu.

Teisinė informacija: BDAR 25 straipsnis (EUR-Lex) · Asmens duomenų teisinės apsaugos įstatymas (e-seimas) · VDAI.

Šis straipsnis yra bendro pobūdžio informacija ir nėra teisinė konsultacija.

Legiscope automates this for you

Stop doing compliance manually. Legiscope's AI handles ROPA creation, DPA audits, and gap analysis — in minutes, not weeks.

Start free trial
TD
Written by
Fondateur de Legiscope et expert RGPD

Docteur en droit de l'Université Panthéon-Assas (Paris II), 23 ans d'expérience en droit du numérique et conformité RGPD. Ancien conseiller de l'administration du Premier ministre sur la mise en œuvre du RGPD. Thiébaut est le fondateur de Legiscope, plateforme de conformité RGPD automatisée par l'IA.

View full author profile →