Wstęp

pra­wie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w doku­men­ta­cji wyma­gań. Jakim wyma­ga­niem jest zgod­ność z obo­wią­zu­ją­cym pra­wem? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspek­ty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z pra­wem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?. Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?. (źr.: Prawo a wyma­ga­nia … )

Dzisiaj czy­tam:

To admi­ni­stra­tor odpo­wia­da za zabez­pie­cze­nia sys­te­mów, a więc tak­że za to, że pra­cow­nik zdo­łał sko­pio­wać dane oso­bo­we na zewnętrz­ny nośnik. […] W oce­nie WSA w toku postę­po­wa­nia PUODO pra­wi­dło­wo usta­lił, iż w SGGW dopusz­czo­no się licz­nych uchy­bień, w szcze­gól­no­ści nie prze­pro­wa­dzo­no wła­ści­wej ana­li­zy ryzy­ka i oce­ny zagro­żeń już na eta­pie pro­jek­to­wa­nia sys­te­mów (pri­va­cy by design) oraz nie wdro­żo­no odpo­wied­nich środ­ków zapew­nia­ją­cych bez­pie­czeń­stwo danych, w tym przed moż­li­wo­ścią wyeks­por­to­wa­nia danych z sys­te­mu na zewnątrz.(źr.: Odpowiedzialność admi­ni­stra­to­ra za naru­sze­nie zasa­dy pri­va­cy by design)

Rzecz w tym, że admi­ni­stra­tor, w rozu­mie­niu pra­wa, to tak­że pod­miot zle­ca­ją­cy powsta­nie opro­gra­mo­wa­nia, któ­re go wspie­ra w reali­za­cji jego obo­wiąz­ków, a jed­nym z tych obo­wiąz­ków jest egze­kwo­wa­nie usta­lo­nych zasad. Dzisiaj o tym, że zbie­ra­nie ​„pod­pi­sów pod oświad­cze­nia­mi” to nie jest bezpieczeństwo. 

Łańcuch odpowiedzialności

Wybrane frag­men­ty Uzasadnienia: 

Prezes UODO zarzu­ca­jąc nie­wy­star­cza­ją­cą oce­nę zasto­so­wa­nych środ­ków tech­nicz­nych i orga­ni­za­cyj­nych obej­mu­ją­cych pro­ces prze­twa­rza­nia danych oso­bo­wych kan­dy­da­tów na stu­dia w S[?] kie­ro­wał się zasa­dą wyni­ka­ją­cą z art. 24 ust 1 roz­po­rzą­dze­nia 2016/679 jaką jest kon­tro­la admi­ni­stra­to­ra nad pro­ce­sa­mi prze­twa­rza­nia danych oso­bo­wych.
[?]
Na admi­ni­stra­to­rze cią­ży zaś obo­wią­zek zwe­ry­fi­ko­wa­nia w orga­ni­za­cji obsza­rów prze­twa­rza­nia danych oso­bo­wych i wdro­że­nia odpo­wied­nich środ­ków tech­nicz­nych i orga­ni­za­cyj­nych mają­cych zapew­nić ich bez­pie­czeń­stwo.
[?]
Dowody zgro­ma­dzo­ne w spra­wie pozwa­la­ją stwier­dzić, że Uczelnia mimo świa­do­mo­ści ist­nie­nia w pro­ce­sie prze­twa­rza­nia danych oso­bo­wych kan­dy­da­tów na stu­dia, tech­nicz­nej moż­li­wo­ści prze­twa­rza­nia pole­ga­ją­ce­go na eks­por­to­wa­niu na zewnętrz­ny nośnik danych oso­bo­wych z sys­te­mu infor­ma­tycz­ne­go z uwa­gi na funk­cjo­nal­ność umoż­li­wia­ją­cą nie­kon­tro­lo­wa­ny eks­port sze­ro­kie­go zakre­su danych oso­bo­wych z sys­te­mu SOK i świa­do­mo­ści w tym zakre­sie Biura Spraw Studenckich, zigno­ro­wa­ła to zagro­że­nie
[?]
Według art. 4 pkt 7 roz­po­rzą­dze­nia RODO ​„admi­ni­stra­tor” ozna­cza oso­bę fizycz­ną lub praw­ną, organ publicz­ny, jed­nost­kę lub inny pod­miot, któ­ry samo­dziel­nie lub wspól­nie z inny­mi usta­la cele i spo­so­by prze­twa­rza­nia danych oso­bo­wych; jeże­li cele i spo­so­by takie­go prze­twa­rza­nia są okre­ślo­ne w pra­wie Unii lub w pra­wie pań­stwa człon­kow­skie­go, to rów­nież w pra­wie Unii lub w pra­wie pań­stwa człon­kow­skie­go może zostać wyzna­czo­ny admi­ni­stra­tor lub mogą zostać okre­ślo­ne kon­kret­ne kry­te­ria jego wyzna­cza­nia.
[?]
Nie ule­ga zatem wąt­pli­wo­ści, że w roz­pa­try­wa­nym przy­pad­ku admi­ni­stra­to­rem danych oso­bo­wych była S[?], a nie jej pra­cow­nik, [?] A.G. W kon­se­kwen­cji, wbrew zapa­try­wa­niu skar­żą­cej Uczelni, nie pono­si on odpo­wie­dzial­no­ści admi­ni­stra­cyj­nej za naru­sze­nie prze­pi­sów roz­po­rzą­dze­nia RODO.
[?]
Trzeba pod­kre­ślić, że z tego prze­pi­su wyni­ka domnie­ma­nie odpo­wie­dzial­no­ści admi­ni­stra­to­ra za naru­sze­nie tych zasad, jako że na nim spo­czy­wa cię­żar wyka­za­nia ich prze­strze­ga­nia. Administrator danych powi­nien zatem prze­pro­wa­dzić ana­li­zę ryzy­ka i oce­nić, z jaki­mi zagro­że­nia­mi ma do czynienia.

(źr.: https://​orze​cze​nia​.nsa​.gov​.pl/​d​o​c​/​E​2​A​2​8​5​6​241)

Innymi sło­wy tu 

admi­ni­stra­tor (czy­li insty­tu­cja) odpo­wia­da za wady opro­gra­mo­wa­nia, a wadą jest więc to, że pozwa­la ono na postę­po­wa­nie nie­zgod­ne z pra­wem, wewnętrz­nym regu­la­mi­nem czy instruk­cją itp. 

„Privacy by Design”

„Prywatność wbu­do­wa­na na eta­pie pro­jek­to­wa­nia” i ​„Prywatność jako cecha domyśl­na” to czę­sto poru­sza­ne tema­ty zwią­za­ne z ochro­ną danych w sys­te­mach infor­ma­tycz­nych. Zwracano na to uwa­gę już od lat 70-tych, a w latach 90-tych włą­czo­no do dyrek­ty­wy RL 95/46/EC o ochro­nie danych. Zgodnie z nią odpo­wied­nie środ­ki tech­nicz­ne i orga­ni­za­cyj­ne muszą być pod­ję­te już na eta­pie pla­no­wa­nia i pro­jek­to­wa­nia sys­te­mu prze­twa­rza­nia danych w celu ochro­ny ich bez­pie­czeń­stwa. Oznacza to, że restryk­cje (bez­pie­czeń­stwo) muszą być imma­nent­ną cechą systemu:

The term ​„Privacy by Design” means nothing more than ​„data pro­tec­tion thro­ugh tech­no­lo­gy design”. Behind this is the tho­ught that data pro­tec­tion in data pro­ces­sing pro­ce­du­res is best adhe­red to when it is alre­ady inte­gra­ted in the tech­no­lo­gy when cre­ated [Termin ​„Privacy by Design” to nic inne­go jak ​„ochro­na danych poprzez pro­jek­to­wa­nie tech­no­lo­gii”. Kryje się za tym myśl, że ochro­na danych w pro­ce­du­rach prze­twa­rza­nia danych jest naj­le­piej prze­strze­ga­na, gdy jest ona wbu­do­wa­na w mecha­nizm roz­wią­za­nia już na eta­pie jego projektowania] 

().

Popatrzmy teraz na defi­ni­cje klu­czo­we­go poję­cia w inży­nie­rii wymagań:

potrze­ba: funk­cja, któ­rej bra­ku­je do osią­gnię­cia celu lub wyko­na­nia dzia­ła­nia (źr. zale­ce­nia UZP)

Innymi sło­wy to potrze­by Zamawiającego są wyma­ga­niem wobec roz­wią­za­nia. Tak więc zgod­ność opro­gra­mo­wa­nia z obo­wią­zu­ją­cym pra­wem to jego wyma­ga­na cecha (wła­ści­wość), a nie moż­li­wa do uży­cia funk­cjo­nal­ność. Rozporządzenie (RODO) naka­zu­je rów­nież, aby domyśl­nie (?by default?) mecha­ni­zmy ochro­ny danych, imple­men­to­wa­ne już w fazie pro­jek­to­wa­nia, były domyśl­nie włączone.

Jedną z wyma­ga­nych więc funk­cji opro­gra­mo­wa­nia powin­no być egze­kwo­wa­nie pra­wa, a nie tyl­ko moż­li­wość jego respektowania! 

Cytowane wcze­śniej zale­ce­nia KE jak i Orzeczenie jasno wska­zu­je, że Zamawiający, jako przy­szły użyt­kow­nik, jest tą oso­bą (tak­że praw­ną), któ­ra pono­si odpo­wie­dzial­ność za skut­ki uży­wa­nia zamó­wio­ne­go opro­gra­mo­wa­nia. Popatrzmy na poniż­szy schemat:

Generalnie to Zamawiający zatrud­nia (anga­żu­je) Wykonawcę. Powoli, ale coraz czę­ściej, zgod­ne z zale­ce­nia­mi UZP, wydzie­la się tak­że rolę Projektanta, zle­ca­jąc mu opra­co­wa­nie OPZ. Mechanizm zarzą­dza­nia ryzy­kiem poprzez roz­dzie­la­nie ról z kon­flik­tem inte­re­su, doty­czy zresz­tą każ­de­go pod­mio­tu, pry­wat­ne­go tak­że. W Orzeczeniu czy­ta­my wie­lo­krot­nie o ana­li­zie ryzy­ka, sta­no­wią­cej obo­wią­zek Administratora czy­li tak­że Zamawiającego. Więc zle­ca­jąc wyko­na­nie (dostar­cze­nie) opro­gra­mo­wa­nia, nale­ży posta­wić takie wyma­ga­nia, by roz­wią­za­nie to (mecha­nizm jego dzia­ła­nia) zapew­nia­ło tak­że egze­kwo­wa­nie okre­ślo­nych reguł (roz­li­czal­ność), a nie tyl­ko umoż­li­wia­ło ich respek­to­wa­nie (czy­li dawa­ło alter­na­ty­wę). Kto ma tego pil­no­wać? Znakomita więk­szość pra­cow­ni­ków Administratora/Zamawiającego nie ma kom­pe­ten­cji Projektanta, Wykonawca zaś ma tu z zasa­dy kon­flikt inte­re­su. Pozostaje więc wydzie­le­nie roli Projektanta i umiesz­cze­nie jej po stro­nie Zamawiającego. 

Łańcuch odpo­wie­dzial­no­ści koń­czy sie na Administratorze (Orzeczenie) co zna­czy tyle że w jego inte­re­sie jest to, by wyma­ga­nie, o jakim tu pisze­my, było speł­nio­ne i zagwa­ran­to­wa­ne już na eta­pie pro­jek­to­wa­nia. Co cie­ka­we ​„pisa­nie wyma­gań” przez pra­cow­ni­ków nie sta­no­wi tu nie tyl­ko żad­ne­go zabez­pie­cze­nia, sta­no­wi ryzy­ko, że będą budo­wa­li furt­ki pozwa­la­ją­ce im na więk­szą swo­bo­dę (patrz Orzeczenie i postę­po­wa­nie pra­cow­ni­ka, któ­re­mu skra­dzio­no komputer). 

Dlatego spe­cy­fi­ka­cja wyma­gań powin­na być pro­jek­tem, a nie listą potrzeb, bo ta jest dopie­ro mate­ria­łem dla projektanta. 

Podsumowanie

Mamy XXI wiek i ogrom­ny postęp w inży­nie­rii opro­gra­mo­wa­nia i war­to pamię­tać, że 

Programowanie nie pole­ga już wyłącz­nie na pisa­niu kodu, pro­gra­mo­wa­nie pole­ga na projektowaniu.

Orzeczenie to sta­no­wi moim zda­niem pozy­tyw­ny pre­ce­dens. Problem z niską jako­ścią opro­gra­mo­wa­nia w tym obsza­rze, to skut­ki ryn­ko­wej ​„zasa­dy”: Klient nasz Pan. Dostawcy opro­gra­mo­wa­nia, będą­cy w zna­ko­mi­tej więk­szo­ści tak­że jego pro­jek­tan­ta­mi, czu­ją się cał­ko­wi­cie zwol­nie­ni z odpo­wie­dzial­no­ści za skut­ki jego uży­cia. Niedawno jeden dostaw­ca wpi­sał moje­mu klien­to­wi, do wzo­ru umo­wy, zapis o wyłą­cze­niu jego (dostaw­cy) odpo­wie­dzial­no­ści z tytu­łu rękoj­mi (!). Tworzenie opro­gra­mo­wa­nia to umo­wa rezul­ta­tu, a ten powi­nien być pre­cy­zyj­nie opi­sa­ny na eta­pie zawie­ra­nia umo­wy, nie jako deta­licz­na kon­struk­cja, ale jako reali­zo­wa­ny mecha­nizm. Warto tak­że pamię­tać, że odpo­wie­dzial­ność za uzy­ska­ny efekt spo­czy­wa tak­że na pro­jek­tan­cie: pro­jekt to zamó­wio­ny rezul­tat .

Z tre­ści Orzeczenia wyni­ka, że w zasa­dzie nic nie stoi na prze­szko­dzie, by zasa­dę ​„Privacy by Design” roz­cią­gnąć na ​„Law by design”, czy­li imple­men­to­wa­nie w opro­gra­mo­wa­niu wszel­kich restryk­cji wyni­ka­ją­cych z pra­wa i obo­wiąz­ku jego prze­strze­ga­nia. Często jed­nak sły­szę argu­ment: ​„nikt nie kupi takie­go opro­gra­mo­wa­nia”. Jeżeli to praw­da, to o czym to świad­czy? (np. mimo tego, że nie wol­no sprze­dać towa­ru, któ­re­go się nie posia­da, pozwa­la na to więk­szość sys­te­mów ERP). 

Podkreślając tezy Orzeczenia, moż­na wywieść waż­ny wnio­sek: opro­gra­mo­wa­nie wdro­żo­ne w przed­się­bior­stwie (czy ode­bra­ne od dostaw­cy) jest inte­gral­ną czę­ścią tego przed­się­bior­stwa, i bar­dzo trud­no będzie dowieść, że za szko­dy jakie ono wyrzą­dzi odpo­wia­da dostaw­ca opro­gra­mo­wa­nia, jest to z zasa­dy odpo­wie­dzial­ność Zarządu. Dlatego bar­dzo waż­ne jest, by Zamawiający miał po swo­jej stro­nie kom­pe­ten­cje pozwa­la­ją­ce nad­zo­ro­wać dostaw­cę. Całość coraz bar­dziej zbli­ża bran­żę IT do innych inży­nie­rii, gdzie za szko­dy wyrzą­dzo­ne przez urzą­dze­nia odpo­wia­da ich użyt­kow­nik – dysponent. 

Warto tak­że pamię­tać, że podob­nie wyglą­da secu­ri­ty by design , czy­li bez­pie­czeń­stwo jako efekt pro­jek­to­wa­nej archi­tek­tu­ry, a nie ​„pod­pi­sów pod oświadczeniami”. 

Źródła