Testy zgodności legislacyjnej oprogramowania. Czym są i kto ich potrzebuje?


Z punktu widzenia rozwoju oprogramowania testy zgodności legislacyjnej są niezwykle ważne, ponieważ rzutują na odpowiedzialność podmiotu, który oprogramowanie wytwarza. Tymczasem praktycznie nie sposób znaleźć szerszego artykułu na ten temat. Spróbujmy więc choć w części wypełnić tę informacyjną lukę.

       Jedyne informacje poruszające tematykę testowania legislacyjnego, które są dostępne w sieci, dotyczą certyfikatu ISTQB. Brakuje natomiast informacji o tym, czym dokładnie są testy zgodności legislacyjnej i na czym polegają. Wiadomo jedynie, że dotyczą one zgodności prawnej wytwarzanego oprogramowania. Sam proces zgodności legislacyjnej wielokrotnie spada na barki analityków lub działów prawnych.

       Zacznijmy od początku. Zgodnie z definicją sylabusa do ISTQB (International Software Testing Qualifications Board) „testy zgodności legislacyjnej wykonuje się sprawdzając, czy oprogramowanie jest zgodne z wszystkimi przepisami prawnymi, z którymi musi być zgodne, takimi jak rozporządzenia rządowe, inne akty prawne lub przepisy dotyczące bezpieczeństwa”   

       Z samej definicji dowiadujemy się zatem, że oprogramowanie musi być zgodne ze wszystkimi przepisami prawnymi, które w danym przypadku należy wziąć pod uwagę. Co do zasady w zależności od tego, jakie to oprogramowanie i czego dotyczy, wymagania prawne mogą być bardzo różne i wprost nie da się ich wszystkich wymienić.
Dla przykładu: jeżeli oprogramowanie powstaje dla firmy ubezpieczeniowej, będziemy brali pod uwagę cały szereg przepisów dotyczących nie tylko zgodności prawnej samego oprogramowania, ale również przepisy RODO, IDD oraz wiele innych, ze względu na klientów towarzystwa.

       Doskonałym przykładem testów zgodności legislacyjnej jest weryfikacja, czy privacy by default oraz privacy by design jest zastosowane w oprogramowaniu. Rozporządzenie dotyczące ochrony danych osobowych (RODO) wprowadziło wymagania dotyczące uwzględnienia ochrony danych oraz prywatności na każdym etapie cyklu tworzenia oprogramowania. Przepisy te wymagają, aby zasady dotyczące ochrony prywatności były częścią składową już na etapie projektowania danej technologii, a wiec uwzględniane w początkowej fazie cyklu życia oprogramowania. Przetwarzanie danych w sposób domyślny może być wykorzystywane tylko w obszarach niezbędnych do realizacji umowy albo z mocy ustawy. Wszelkie odstępstwa skutkujące poszerzeniem przetwarzania danych, wymagające podanie dodatkowych ilości danych, powinny być dokonywane wyłącznie przez samego użytkownika końcowego w pełni za jego zgodą.

Podstawa prawna: art. 25 ust 1 i 2 Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE.

       Znajomość prawa i aktualnych ustaw, które dotyczą projektu, nie tylko może pomóc w testowaniu zgodności legislacyjnej, ale również przy tradycyjnym testowaniu manualnym.
Przykład: Jeżeli instytucja finansowa wdraża nową funkcjonalność (przyjmijmy, że jest to możliwość złożenia wniosku dotyczącego programu socjalnego 500+), udział w projekcie i wymogi, jakie ten projekt ma spełniać, warunkować będzie również sama ustawa, rozporządzenie lub inny akt prawny, do którego bezwzględnie należy oprogramowanie dostosować lub stworzyć, jeżeli obecna technologia takich rozwiązań nie przewiduje.

       Już na etapie tworzenia analizy oraz scenariuszy testowych jesteśmy w stanie zweryfikować część zgodności legislacyjnej danej funkcjonalności. W przypadku 500+ możemy na przykład sprawdzić, czy formularz zakłada wszelkie wymogi i nie posiada ograniczeń co do liczby posiadanych dzieci, czy dane nie są przetwarzane szerzej niż wymaga ustawa lub czy są ograniczenia do tego, kto może złożyć taki formularz.

       Podobnie będzie wyglądała sytuacja jeżeli naszym celem jest testowanie zgodności legislacyjnej aplikacji na telefon.
Przykład: Weryfikacja planowanego oprogramowania w kontekście wpływu na inne zewnętrzne, niezależne oprogramowanie, na przykład aplikacja mobilna i skutki jej wpływu na smartfon czy inne aplikacje. Do testów legislacyjnych wówczas neleżeć będzie weryfikacja takich obszarów jak:

– czy aplikacja zbyt szeroko nie będzie ingerowała w prywatność użytkownika smartfonu
Podstawa prawna: art. 25 ust 1 i 2 RODO, art. 47 – Konstytucji RP

– czy jej działanie nie spełnia przesłanek czynu nieuczciwej konkurencji lub doprowadza do wyrządzenia szkód bezpośrednich lub pośrednich innym aplikacjom. Podstawa prawna: art. 3 i następne, Ustawy z dnia 16 kwietnia 1993 roku o zwalczaniu nieuczciwej konkurencji

– czy sama aplikacja nie łamie ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych.

       Istotnym punktem testów zgodności legislacyjnej jest również wątek testów zgodności bezpieczeństwa z perspektywy prawnej. O ile testy bezpieczeństwa to zupełnie inna część testowania oprogramowania o tyle testy zgodności legislacyjnej bezpieczeństwa mogą być ich częścią lub osobną dziedziną w danej organizacji. W takim przypadku weryfikacją zgodności legislacyjnej będzie czy dane oprogramowanie nie wpływa na przepisy prawne związane z bezpieczeństwem.
Przykład: W branży finansowej może być to wymóg SCA (Strong Customer Authenticathion – silne uwierzytelnienie) dotyczący wymogów związanych z PSD2. Silne uwierzytelnienie dotyczy weryfikacji tożsamości użytkownika usług płatniczych, uwzględniając jego indywidualne cechy. Według definicji Dyrektywy PSD2 „silne uwierzytelnianie klienta oznacza uwierzytelnianie w oparciu o zastosowanie co najmniej dwóch elementów należących do kategorii: wiedza (coś, co wie wyłącznie użytkownik), posiadanie (coś, co posiada wyłącznie użytkownik) i cechy klienta (coś, czym jest użytkownik), niezależnych w tym sensie, że naruszenie jednego z nich nie osłabia wiarygodności pozostałych, które to uwierzytelnianie jest zaprojektowane w sposób zapewniający ochronę poufności danych uwierzytelniających.”

       Weryfikacja zgodności legislacyjnej w takim przypadku powinna obejmować nie tylko standardowe czynności, ale również określenie, czy zakres znajduje zastosowanie kiedy użytkownik uzyskuje dostęp do rachunku online, inicjuje płatność drogą mobilną lub kanałem zdalnym. Niedostosowanie takich wymogów może skutkować zwiększeniem ryzyka nadużyć transakcyjnych oraz odpowiedzialnością podmiotu wobec Komisji Nadzoru Finansowego.

       Co ważne, uznaje się, że brak odpowiedniego zastosowania wymogów będzie skutkował ponoszeniem odpowiedzialności między instytucją finansową a użytkownikiem końcowym w przypadku fraudów transakcyjnych. Jeżeli z całego kontekstu sprawy wyniknie, że dostawca oprogramowania nie dochował należytej staranności, może dojść do regresu odpowiedzialności również na dostawcę oprogramowania.

       Analiza czy wewnętrzne ustalenia biznesowe nie zawsze wszystko wykażą, dlatego na etapie pisania scenariuszy testowych jest jeszcze czas, aby doprecyzować pewne szczegóły. Często również sam klient do końca nie jest w stanie sprecyzować dokładnych i jednoznacznych wymagań, ponieważ wymagania biznesowe nawet po konsultacji prawnej to jedno, natomiast trzeba jeszcze je przełożyć na język techniczny. Klient nie musi się znać na oprogramowaniu i relacjach, jakie w nim zachodzą. Obdarzając wykonawcę zaufaniem, oczekuje, że zespoły odpowiedzialne za produkcję oprogramowania same zaproponują odpowiednie techniczne rozwiązanie, które będzie odzwierciedlać również zgodność legislacyjną oprogramowania.

       Oczywiście od testera nie wymaga się doskonałej znajomości przepisów prawnych, bo nie musi on być prawnikiem. Jego celem jest odnalezienie defektów w oprogramowaniu, analizie lub wymaganiach klienta, które mogą być przyczyną ryzyka projektowego czy produktowego. Warto jednak zadbać o własny rozwój i pogłębiać wiedzę, choćby poprzez lekturę prawnych komentarzy do ustaw. W ten sposób można w znacznym stopniu wpłynąć na perspektywę potencjalnych zagrożeń związanych z oprogramowaniem i bezpieczeństwem.

       Coraz częściej firmy zatrudniają odrębnych pracowników na stanowisku dotyczącym zgodności legislacyjnej wytwarzanego oprogramowania, tak zwanych analityków prawnych. Oni to właśnie niczym „wolne elektrony” zajmują się konsultacją zgodności legislacyjnej danego oprogramowania. Z mojego doświadczenia wynika, że doskonała znajomość przepisów na różnych płaszczyznach prawa nie tylko ułatwia testowanie, ale również pokazuje horyzontalne i wertykalne zagrożenia, jakie mogą wystąpić przy wykorzystywaniu danego oprogramowania, a także te, które wpływają na odpowiedzialność wytwarzającego je podmiotu. Nawet pozornie niewielki defekt może mieć dalekosiężne konsekwencje w kontekście odpowiedzialności.


Charlotta Lendzion

O Charlotta Lendzion

Charlotta Lendzion - Certyfikowany Tester Oprogramowania, z wykształcenia magister prawa specjalizujący się w prawie nowych technologii i prawie zobowiązań. Aktualnie prowadzi badania naukowe w ramach pracy doktorskiej dotyczące prawnych aspektów inteligentnych kontraktów (smart contracts) przy wykorzystywaniu technologii blockchain w sektorze finansowym.